Dave, I have no problem running TITAAN as long as it serves a purpose. It's a small wonder the VMS image made it your way, given the distance.
Tuesday at around 1800 (UTC+1) I'll power it up again.
------Origineel bericht------
Van: Dave McGuire
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] TITAAN shutdown
Verzonden: 14 januari 2013 23:39
On 01/14/2013 05:37 PM, hvlems at zonnet.nl wrote:
TITAAN (44.35) was shutdown just now. If there still is interest for
VMS kits or layered products : just tell me and I"l boot it again.
I was unable to copy the LP images due to timeouts; did anyone grab
them, and can make them available? I don't want to make Hans power
TITAAN up again..
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Just FYI, RHESUS:: has a bunch of stuff including a full SDL kit in RHESUS::[.MEDIALIB]
It's also web accessible (and mirrored on a way faster uplink) - see
http://rhesus.sampsa.com/medialib.start.html for details.
sampsa
On 15 Jan 2013, at 00:37, hvlems at zonnet.nl wrote:
TITAAN (44.35) was shutdown just now. If there still is interest for VMS kits or layered products : just tell me and I"l boot it again.
Hans
On 01/14/2013 05:37 PM, hvlems at zonnet.nl wrote:
TITAAN (44.35) was shutdown just now. If there still is interest for
VMS kits or layered products : just tell me and I"l boot it again.
I was unable to copy the LP images due to timeouts; did anyone grab
them, and can make them available? I don't want to make Hans power
TITAAN up again..
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
I agree. It's an interesting topic!
------Origineel bericht------
Van: sampsa at mac.com
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] SCSISE adapter -> listings
Verzonden: 14 januari 2013 23:28
I would suggest moving this conversation (which I personally find very interesting) to the DECtec mailing list, which can be found at http://dectec.info
sampsa
On 15 Jan 2013, at 00:25, Clem Cole <clemc at ccc.com> wrote:
On Mon, Jan 14, 2013 at 5:08 PM, Brian Schenkenberger, VAXman- <system at tmesis.com> wrote:
DEC C I/O is just a wrapper around RMS
Please take this off list if you want to continue to discuss it.
I would suggest moving this conversation (which I personally find very interesting) to the DECtec mailing list, which can be found at http://dectec.info
sampsa
On 15 Jan 2013, at 00:25, Clem Cole <clemc at ccc.com> wrote:
On Mon, Jan 14, 2013 at 5:08 PM, Brian Schenkenberger, VAXman- <system at tmesis.com> wrote:
DEC C I/O is just a wrapper around RMS
Please take this off list if you want to continue to discuss it.
On Mon, Jan 14, 2013 at 5:08 PM, Brian Schenkenberger, VAXman- <system at tmesis.com> wrote:
DEC C I/O is just a wrapper around RMS
Please take this off list if you want to continue to discuss it.
Clem Cole <clemc at ccc.com> writes:
On Mon, Jan 14, 2013 at 4:02 PM, Brian Schenkenberger, VAXman- <
system at tmesis.com> wrote:
BLISS has no I/O, and if you want to be pedantic, nor does C. I/O is
all via support libraries which provide I/O. Neither language has any
inherent I/O syntax. A BLISS coder would call some VMS RTL or delve >
into $QIO to do I/O. >
Absolutely correct. Sorry to confuse >>in practice<< it was two
different models, but you are right, the languages did not force an I/O
model in the language semantics. So the the issue degenerates to VMS
RMS (record I/O - from the IBM mainframe) vs stream I/O - the C/Multics
(byte stream) style.
When VAX was first envisioned GB et al, wanted a machine to go after the
360/370 family. An efficient RMS was considered a requirement and the
crew did an amazing job. It was small, fast and worked extremely well.
I t was complicated but lots of people and it sounds like you are/were
in that camp, loved it.
But after VAX-11C was released and stream I/O installed, engineering
discovered that stream I/O was preferred by more people, and in
particular us OS types discovered we preferred it. FYI: Dave added
stream I/O to VMS for VAX-11/C (urban legend is in an weekend - but I
really do not think that was true - I was not on the VMS team, although
a number of my friends were).
My memory is hazy here, but I think there was a point where the compiler
team rewrote the FTN runtime support from RMS into stream code soon
their after and "their was much rejoicing." They are likely to have
done it in BLISS, but again, I'd have to ask one the old compiler guys
that actually did the work and few are left.
As I said in a previous message I still see Grove socially every so
often, but since he retired a few years ago; he's not as accessible. If
you have a specific question, that I do not know the answer, I >>might<<
be able to find some one that can. But I'd prefer this off-list, please
send it to me directly, with a working return email address.
WRT VAX C, I'd have to pull out an old V5.n release and install it to be
certain but DEC C I/O is just a wrapper around RMS, et al. It HAS to be
or RMS CDC simply would not function... and it most certainly does!
WRT the Fortran RTL rewrite: I haven't looked; however, the COBOL RTL has
certainly been rewritten in recent times in C. It caused me many too many
a headache trying to deal with Pthreads in the midsts of RMS's own unique
threading to implement CDC. There weren't real Pthread threads but due to
resourcing the COBOL RTL in C, the excess baggage of the TEB came along in
every I/O.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
On Mon, Jan 14, 2013 at 4:02 PM, Brian Schenkenberger, VAXman- <system at tmesis.com> wrote:
BLISS has no I/O, and if you want to be pedantic, nor does C. I/O is
all via support libraries which provide I/O. Neither language has any
inherent I/O syntax. A BLISS coder would call some VMS RTL or delve
into $QIO to do I/O.
Absolutely correct. Sorry to confuse >>in practice<< it was two different models, but you are right, the languages did not force an I/O model in the language semantics. So the the issue degenerates to VMS RMS (record I/O - from the IBM mainframe) vs stream I/O - the C/Multics (byte stream) style.
When VAX was first envisioned GB et al, wanted a machine to go after the 360/370 family. An efficient RMS was considered a requirement and the crew did an amazing job. It was small, fast and worked extremely well. I t was complicated but lots of people and it sounds like you are/were in that camp, loved it.
But after VAX-11C was released and stream I/O installed, engineering discovered that stream I/O was preferred by more people, and in particular us OS types discovered we preferred it. FYI: Dave added stream I/O to VMS for VAX-11/C (urban legend is in an weekend - but I really do not think that was true - I was not on the VMS team, although a number of my friends were).
My memory is hazy here, but I think there was a point where the compiler team rewrote the FTN runtime support from RMS into stream code soon their after and "their was much rejoicing." They are likely to have done it in BLISS, but again, I'd have to ask one the old compiler guys that actually did the work and few are left.
As I said in a previous message I still see Grove socially every so often, but since he retired a few years ago; he's not as accessible. If you have a specific question, that I do not know the answer, I >>might<< be able to find some one that can. But I'd prefer this off-list, please send it to me directly, with a working return email address.
Clem
On 14 Jan 2013, at 16:07, "Brian Schenkenberger, VAXman-" <system at TMESIS.COM> wrote:
Cory Smelosky <b4 at gewt.net> writes:
No matter the version top/htop always shows 100% CPU. What distro are =
you using?
Ubuntu is on my laptops.
I must have misconfigured something hmmmmm.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
