On 7 Oct 2013, at 23:27, "Brian Schenkenberger, VAXman-" <system at TMESIS.COM> wrote:
Sampsa Laine <sampsa at mac.com> writes:
Brian,
Any news / progress on the EISNER project?
No news. Hopefully, that trasnlates to good news.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
Cool. Pretty excited about the prospect myself.
Sampsa
On Mon, 7 Oct 2013, Brian Schenkenberger, VAXman- wrote:
Weird. Despite the error UUCP seems to be working correctly.
What error are you getting and where?
%SYS-Abort. It seems it might just be when there's no data to send either way as UUCP transfers work.
Fighting with having no compilers as valid commands despite having them installed is the only problem now.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
Cory Smelosky <b4 at gewt.net> writes:
On Mon, 7 Oct 2013, Cory Smelosky wrote:
On Mon, 7 Oct 2013, Cory Smelosky wrote:
On Mon, 7 Oct 2013, Brian Schenkenberger, VAXman- wrote:
Cory Smelosky <b4 at gewt.net> writes:
On Mon, 7 Oct 2013, Cory Smelosky wrote:
Let's assume you have no need for your prior accounting information...
$ SET ACCOUNTING/NEW_FILE/ENABLE=IMAGE
Execute the UUCP command(s) which fail.
$ ACCOUNTING/SINCE=TODAY
Post that output and let's see if there's anything revealing in there.
Also, you can $ SET ACCOUNTING/DISABLE=IMAGE because /ENABLE=IMAGE can
become a resource hog.
Doing so now.
I disabled TERM/INQ on login in SYLOGIN and the abort went away
(ACCOUNTING didn't have anything useful to say). I know I can disable it
per-line/per-use but this was the quickest test.
Now we're getting somewhere.
Try putting:
$ IF "''F$mode()'".EQS."NETWORK" THEN $ EXIT
at the beginning of your SYLOGIN.COM and LOGIN.COM files.
You can not SET TERM/INQUIRE if there's no terminal. ;)
It's coming in on a serial line, actually. Apparently that's not the
problem though as it's SYSTEM-ABORTing again...
Don't get why it works sometimes and sometimes not. I need Mark P's help for
this.
Weird. Despite the error UUCP seems to be working correctly.
What error are you getting and where?
--
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, 7 Oct 2013, Cory Smelosky wrote:
On Mon, 7 Oct 2013, Cory Smelosky wrote:
On Mon, 7 Oct 2013, Brian Schenkenberger, VAXman- wrote:
Cory Smelosky <b4 at gewt.net> writes:
On Mon, 7 Oct 2013, Cory Smelosky wrote:
Let's assume you have no need for your prior accounting information...
$ SET ACCOUNTING/NEW_FILE/ENABLE=IMAGE
Execute the UUCP command(s) which fail.
$ ACCOUNTING/SINCE=TODAY
Post that output and let's see if there's anything revealing in there.
Also, you can $ SET ACCOUNTING/DISABLE=IMAGE because /ENABLE=IMAGE can
become a resource hog.
Doing so now.
I disabled TERM/INQ on login in SYLOGIN and the abort went away
(ACCOUNTING didn't have anything useful to say). I know I can disable it
per-line/per-use but this was the quickest test.
Now we're getting somewhere.
Try putting:
$ IF "''F$mode()'".EQS."NETWORK" THEN $ EXIT
at the beginning of your SYLOGIN.COM and LOGIN.COM files.
You can not SET TERM/INQUIRE if there's no terminal. ;)
It's coming in on a serial line, actually. Apparently that's not the problem though as it's SYSTEM-ABORTing again...
Don't get why it works sometimes and sometimes not. I need Mark P's help for this.
Weird. Despite the error UUCP seems to be working correctly.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On Mon, 7 Oct 2013, Cory Smelosky wrote:
On Mon, 7 Oct 2013, Brian Schenkenberger, VAXman- wrote:
Cory Smelosky <b4 at gewt.net> writes:
On Mon, 7 Oct 2013, Cory Smelosky wrote:
Let's assume you have no need for your prior accounting information...
$ SET ACCOUNTING/NEW_FILE/ENABLE=IMAGE
Execute the UUCP command(s) which fail.
$ ACCOUNTING/SINCE=TODAY
Post that output and let's see if there's anything revealing in there.
Also, you can $ SET ACCOUNTING/DISABLE=IMAGE because /ENABLE=IMAGE can
become a resource hog.
Doing so now.
I disabled TERM/INQ on login in SYLOGIN and the abort went away
(ACCOUNTING didn't have anything useful to say). I know I can disable it
per-line/per-use but this was the quickest test.
Now we're getting somewhere.
Try putting:
$ IF "''F$mode()'".EQS."NETWORK" THEN $ EXIT
at the beginning of your SYLOGIN.COM and LOGIN.COM files.
You can not SET TERM/INQUIRE if there's no terminal. ;)
It's coming in on a serial line, actually. Apparently that's not the problem though as it's SYSTEM-ABORTing again...
Don't get why it works sometimes and sometimes not. I need Mark P's help for this.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On Mon, 7 Oct 2013, Brian Schenkenberger, VAXman- wrote:
Cory Smelosky <b4 at gewt.net> writes:
On Mon, 7 Oct 2013, Cory Smelosky wrote:
Let's assume you have no need for your prior accounting information...
$ SET ACCOUNTING/NEW_FILE/ENABLE=IMAGE
Execute the UUCP command(s) which fail.
$ ACCOUNTING/SINCE=TODAY
Post that output and let's see if there's anything revealing in there.
Also, you can $ SET ACCOUNTING/DISABLE=IMAGE because /ENABLE=IMAGE can
become a resource hog.
Doing so now.
I disabled TERM/INQ on login in SYLOGIN and the abort went away
(ACCOUNTING didn't have anything useful to say). I know I can disable it
per-line/per-use but this was the quickest test.
Now we're getting somewhere.
Try putting:
$ IF "''F$mode()'".EQS."NETWORK" THEN $ EXIT
at the beginning of your SYLOGIN.COM and LOGIN.COM files.
You can not SET TERM/INQUIRE if there's no terminal. ;)
It's coming in on a serial line, actually. Apparently that's not the problem though as it's SYSTEM-ABORTing again...
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
yOn Mon, 7 Oct 2013, Tim Sneddon wrote:
On Mon, Oct 7, 2013 at 11:31 PM, Cory Smelosky <b4 at gewt.net> wrote:
On Mon, 7 Oct 2013, Cory Smelosky wrote:
Let's assume you have no need for your prior accounting information...
$ SET ACCOUNTING/NEW_FILE/ENABLE=**IMAGE
Execute the UUCP command(s) which fail.
$ ACCOUNTING/SINCE=TODAY
Post that output and let's see if there's anything revealing in there.
Also, you can $ SET ACCOUNTING/DISABLE=IMAGE because /ENABLE=IMAGE can
become a resource hog.
Doing so now.
I disabled TERM/INQ on login in SYLOGIN and the abort went away
(ACCOUNTING didn't have anything useful to say). I know I can disable it
per-line/per-use but this was the quickest test.
I've seen this screw lots of stuff. I have stuff in my personal
LOGIN.COMthat configures the terminal they way I like it. I just wrap
it in the
following:
$ interactive = (f$mode() .eqs. "INTERACTIVE")
$ network = (f$mode() .eqs. "NETWORK")
$ batch = (f$mode() .eqs. "BATCH")
...
$ if (interactive)
$ then
$ set terminal ...
$ endif
Regards, Tim.
WTF. And now UUCP isn't working again?
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
Cory Smelosky <b4 at gewt.net> writes:
On Mon, 7 Oct 2013, Cory Smelosky wrote:
Let's assume you have no need for your prior accounting information...
$ SET ACCOUNTING/NEW_FILE/ENABLE=IMAGE
Execute the UUCP command(s) which fail.
$ ACCOUNTING/SINCE=TODAY
Post that output and let's see if there's anything revealing in there.
Also, you can $ SET ACCOUNTING/DISABLE=IMAGE because /ENABLE=IMAGE can
become a resource hog.
Doing so now.
I disabled TERM/INQ on login in SYLOGIN and the abort went away
(ACCOUNTING didn't have anything useful to say). I know I can disable it
per-line/per-use but this was the quickest test.
Now we're getting somewhere.
Try putting:
$ IF "''F$mode()'".EQS."NETWORK" THEN $ EXIT
at the beginning of your SYLOGIN.COM and LOGIN.COM files.
You can not SET TERM/INQUIRE if there's no terminal. ;)
--
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, Oct 7, 2013 at 11:31 PM, Cory Smelosky <b4 at gewt.net> wrote:
On Mon, 7 Oct 2013, Cory Smelosky wrote:
Let's assume you have no need for your prior accounting information...
$ SET ACCOUNTING/NEW_FILE/ENABLE=IMAGE
Execute the UUCP command(s) which fail.
$ ACCOUNTING/SINCE=TODAY
Post that output and let's see if there's anything revealing in there.
Also, you can $ SET ACCOUNTING/DISABLE=IMAGE because /ENABLE=IMAGE can
become a resource hog.
Doing so now.
I disabled TERM/INQ on login in SYLOGIN and the abort went away (ACCOUNTING didn't have anything useful to say). I know I can disable it per-line/per-use but this was the quickest test.
I've seen this screw lots of stuff. I have stuff in my personal LOGIN.COM that configures the terminal they way I like it. I just wrap it in the following:
$ interactive = (f$mode() .eqs. "INTERACTIVE")
$ network = (f$mode() .eqs. "NETWORK")
$ batch = (f$mode() .eqs. "BATCH")
...
$ if (interactive)
$ then
$ set terminal ...
$ endif
Regards, Tim.
On Mon, 7 Oct 2013, Brian Schenkenberger, VAXman- wrote:
Cory Smelosky <b4 at gewt.net> writes:
On Mon, 7 Oct 2013, Brian Schenkenberger, VAXman- wrote:
Cory Smelosky <b4 at gewt.net> writes:
On Mon, 7 Oct 2013, Jordi Guillaumes i Pons wrote:
Any chance you have got two different DCLTABLES in SYS$COMMON and SYS$SPECIFIC?
I'd answer if I could find where in sys$common and sys$specific they
are...
DCLTABLES is an executable. It's a mapped image section. It's name is
DCLTABLES.EXE and it should be in the common root of SYS$LIBRARY. Thus,
you should be looking in SYS$COMMON:[SYSLIB]. If you have DCLTABLES.EXE
in SYS$SPECIFIC:[SYSLIB], strange things (ie. unpredictable results) can
occur when products add their command definitions to DCLTABLES.EXE.
Looks like I don't have a DCLTABLES.EXE in SYS$SPECIFIC.
The question then begs to be asked, why do you think your command
definitions are changing or being deleted.
Well, after the install, or random subsequent logins CC, COBOL, FORTRAN, or PASCAL all were valid commands. Now after subsequent reboots/logins they are not.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
Cory Smelosky <b4 at gewt.net> writes:
On Mon, 7 Oct 2013, Brian Schenkenberger, VAXman- wrote:
Cory Smelosky <b4 at gewt.net> writes:
On Mon, 7 Oct 2013, Jordi Guillaumes i Pons wrote:
Any chance you have got two different DCLTABLES in SYS$COMMON and SYS$SPECIFIC?
I'd answer if I could find where in sys$common and sys$specific they
are...
DCLTABLES is an executable. It's a mapped image section. It's name is
DCLTABLES.EXE and it should be in the common root of SYS$LIBRARY. Thus,
you should be looking in SYS$COMMON:[SYSLIB]. If you have DCLTABLES.EXE
in SYS$SPECIFIC:[SYSLIB], strange things (ie. unpredictable results) can
occur when products add their command definitions to DCLTABLES.EXE.
Looks like I don't have a DCLTABLES.EXE in SYS$SPECIFIC.
The question then begs to be asked, why do you think your command
definitions are changing or being deleted.
--
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, 7 Oct 2013, Cory Smelosky wrote:
Let's assume you have no need for your prior accounting information...
$ SET ACCOUNTING/NEW_FILE/ENABLE=IMAGE
Execute the UUCP command(s) which fail.
$ ACCOUNTING/SINCE=TODAY
Post that output and let's see if there's anything revealing in there.
Also, you can $ SET ACCOUNTING/DISABLE=IMAGE because /ENABLE=IMAGE can
become a resource hog.
Doing so now.
I disabled TERM/INQ on login in SYLOGIN and the abort went away (ACCOUNTING didn't have anything useful to say). I know I can disable it per-line/per-use but this was the quickest test.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On Mon, 7 Oct 2013, Brian Schenkenberger, VAXman- wrote:
Cory Smelosky <b4 at gewt.net> writes:
On Mon, 7 Oct 2013, Jordi Guillaumes i Pons wrote:
Any chance you have got two different DCLTABLES in SYS$COMMON and SYS$SPECIFIC?
I'd answer if I could find where in sys$common and sys$specific they
are...
DCLTABLES is an executable. It's a mapped image section. It's name is
DCLTABLES.EXE and it should be in the common root of SYS$LIBRARY. Thus,
you should be looking in SYS$COMMON:[SYSLIB]. If you have DCLTABLES.EXE
in SYS$SPECIFIC:[SYSLIB], strange things (ie. unpredictable results) can
occur when products add their command definitions to DCLTABLES.EXE.
Looks like I don't have a DCLTABLES.EXE in SYS$SPECIFIC.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
Cory Smelosky <b4 at gewt.net> writes:
On Mon, 7 Oct 2013, Jordi Guillaumes i Pons wrote:
Any chance you have got two different DCLTABLES in SYS$COMMON and SYS$SPECIFIC?
I'd answer if I could find where in sys$common and sys$specific they
are...
DCLTABLES is an executable. It's a mapped image section. It's name is
DCLTABLES.EXE and it should be in the common root of SYS$LIBRARY. Thus,
you should be looking in SYS$COMMON:[SYSLIB]. If you have DCLTABLES.EXE
in SYS$SPECIFIC:[SYSLIB], strange things (ie. unpredictable results) can
occur when products add their command definitions to DCLTABLES.EXE.
--
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, 7 Oct 2013, Brian Schenkenberger, VAXman- wrote:
Cory Smelosky <b4 at gewt.net> writes:
On Mon, 7 Oct 2013, Cory Smelosky wrote:
Hello,
After the reinstall to 7.3 I've made progress! UUCP no longer gives quota
exceeded errors...it just gives a message about it having aborted.
Nothing else is in the debug logs.
Enable image accounting and see what is left in there after UUCP aborts.
Doing so now. Should have an answer in 9 minutes.
CC, Pascal, COBOL, and FORTRAN also
seem to be in DCLTABLES for awhile...but after I log out they're no longer
listed. WTF?
How are you "listing" CC, Pascal and Fortran verbs in DCLTABLES? Where
is DCLTABLES.EXE on your system? It should reside in SYS$COMMON[SYSLIB].
I may be mistaken as to if it's getting shoved in to DCLTABLES...as running the startup script isn't defining any symbols for CC or similar, I assume they were being tossed in to DCLTABLES.
I've run their requisite startup scripts! How the hell did
I break DCLTABLES?
What makes you think that you did?
The error seems impossible to happen spontaneously.
(I've increased the page table limits in case they
were getting full. I'm also getting no debug info related to this,
either)
At least the quota issues disappeared. ;)
Let's assume you have no need for your prior accounting information...
$ SET ACCOUNTING/NEW_FILE/ENABLE=IMAGE
Execute the UUCP command(s) which fail.
$ ACCOUNTING/SINCE=TODAY
Post that output and let's see if there's anything revealing in there.
Also, you can $ SET ACCOUNTING/DISABLE=IMAGE because /ENABLE=IMAGE can
become a resource hog.
Doing so now.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On 07/10/2013 14:41, Brian Schenkenberger, VAXman- wrote:
Mark Wickens <mark at wickensonline.co.uk> writes:
On 07/10/2013 14:04, Daniel Soderstrom wrote:
Only has 13 views so I was thinking you might not have seen this video.
http://m.youtube.com/watch?v=UfBMyvIBYAw
There are so few videos. Have any of you seen the doco that was released by PBS in the US? Its not available from anywhere except the PBS online strore and they wont ship overseas.
Regards,
Daniel.
Wow, thanks for sharing that, what an amazing data centre.
It'll make the folks on this list drool for sure!
I saw your comment there too. I finally got to see what you look like.
Yeah, and unlike most peoples online photos, that one is fairly recent! It's actually a passport photo. No smiling allowed. I do smile occasionally, when my extended family isn't making my life hell ;)
I was thinking a page with photos of hecnetters might be a good idea. I could easily be persuaded otherwise however!
Mark.
--
http://www.wickensonline.co.ukhttp://hecnet.euhttp://declegacy.org.ukhttp://retrochallenge.nethttps://twitter.com/#!/%40urbancamo
On Mon, 7 Oct 2013, Jordi Guillaumes i Pons wrote:
Any chance you have got two different DCLTABLES in SYS$COMMON and SYS$SPECIFIC?
I'd answer if I could find where in sys$common and sys$specific they are...
Jordi Guillaumes i Pons
Barcelona - Catalunya - Europa
El 07/10/2013, a les 5:15, Cory Smelosky <b4 at gewt.net> va escriure:
On Mon, 7 Oct 2013, Cory Smelosky wrote:
Hello,
After the reinstall to 7.3 I've made progress! UUCP no longer gives quota exceeded errors...it just gives a message about it having aborted. Nothing else is in the debug logs. CC, Pascal, COBOL, and FORTRAN also seem to be in DCLTABLES for awhile...but after I log out they're no longer listed. WTF? I've run their requisite startup scripts! How the hell did I break DCLTABLES? (I've increased the page table limits in case they were getting full. I'm also getting no debug info related to this, either)
At least the quota issues disappeared. ;)
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
Mark Wickens <mark at wickensonline.co.uk> writes:
On 07/10/2013 14:04, Daniel Soderstrom wrote:
Only has 13 views so I was thinking you might not have seen this video.
http://m.youtube.com/watch?v=UfBMyvIBYAw
There are so few videos. Have any of you seen the doco that was released by PBS in the US? Its not available from anywhere except the PBS online strore and they wont ship overseas.
Regards,
Daniel.
Wow, thanks for sharing that, what an amazing data centre.
It'll make the folks on this list drool for sure!
I saw your comment there too. I finally got to see what you look like.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
Only has 13 views so I was thinking you might not have seen this video.
http://m.youtube.com/watch?v=UfBMyvIBYAw
There are so few videos. Have any of you seen the doco that was released by PBS in the US? Its not available from anywhere except the PBS online strore and they wont ship overseas.
Regards,
Daniel.
Brian Hechinger <wonko at 4amlunch.net> writes:
On Mon, Oct 07, 2013 at 11:48:10AM +0800, Tim Sneddon wrote:
Alpha I'd go with V8.3 and Itanium, V8.3-1H1. As Brian pointed out V8,4
was the first release post off-shoring. The work done for this release was
initiated when ZKO was being shutdown and moved to MRO, which too was
promptly shutdown and moved to India. As someone who has used and observed
some serious issues with this release (which I believe Brian is too) I
would not recommend it at all. It is my belief that that the goings on at
HP greatly affected the quality.
I have a friend who is a full time VMS admin and boy let me tell you
about the bitching he did when he did his first 8.4 upgrade. He was not
happy at all. :)
I was part of FT for V8.4. THis, however, was during the time of the off-
shoring transition and, for the most part, there were few issue that I had
found. Once the final V8.4 hit the street, hoever, it was chock full with
bugs and issues. The first issue to concerned me most was broken X11 tun-
neling in ssh. That pretty much made the general release version of V8.4
usless AFAIWC. It took many many emails to the new kids on the block until
they were able to understand that ssh X11 tunneling was not the same as a
telnet from a PeeCee WEENDOZE terminal emulator. Fortunately, there were
still a few, former, ZKOans and MROans retained who evidently helped them
to see the light.
There were several other issues which, eventually, have been address and
V8.4 is now rather stable. You'll need to get one of the remastered V8.4
distributions which has several patch updates applied to it to use V8.4.
FWIW, not all of the present problems can be attributed to the off-shore
group. They actually have fixed some bugs that were there for some time.
I uncovered a day-one bug in the INSQ*I and REMQ*I primitives on Itanium
back in May or 2102. (Described here: http://tmesis.org/?e=43 ) First,
CDC was informed and I provided them with some simple reproducers as well
as my analysis of the Itanium code (detailed in the cited URL). This was
then forwarded to the India development group. Clair Grant was still on
the job at that time, however, and I believe he governed over the changes
to fix the problem.
I've met with and spoken with (face to face) a number of the members of
the India group. They're all very bright people but I believe they lack
a discipline that can only be had with decades of experience.
--
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, Oct 07, 2013 at 11:48:10AM +0800, Tim Sneddon wrote:
Alpha I'd go with V8.3 and Itanium, V8.3-1H1. As Brian pointed out V8,4
was the first release post off-shoring. The work done for this release was
initiated when ZKO was being shutdown and moved to MRO, which too was
promptly shutdown and moved to India. As someone who has used and observed
some serious issues with this release (which I believe Brian is too) I
would not recommend it at all. It is my belief that that the goings on at
HP greatly affected the quality.
I have a friend who is a full time VMS admin and boy let me tell you
about the bitching he did when he did his first 8.4 upgrade. He was not
happy at all. :)
-brian
Cory Smelosky <b4 at gewt.net> writes:
On Mon, 7 Oct 2013, Cory Smelosky wrote:
Hello,
After the reinstall to 7.3 I've made progress! UUCP no longer gives quota
exceeded errors...it just gives a message about it having aborted.
Nothing else is in the debug logs.
Enable image accounting and see what is left in there after UUCP aborts.
CC, Pascal, COBOL, and FORTRAN also
seem to be in DCLTABLES for awhile...but after I log out they're no longer
listed. WTF?
How are you "listing" CC, Pascal and Fortran verbs in DCLTABLES? Where
is DCLTABLES.EXE on your system? It should reside in SYS$COMMON[SYSLIB].
I've run their requisite startup scripts! How the hell did
I break DCLTABLES?
What makes you think that you did?
(I've increased the page table limits in case they
were getting full. I'm also getting no debug info related to this,
either)
At least the quota issues disappeared. ;)
Let's assume you have no need for your prior accounting information...
$ SET ACCOUNTING/NEW_FILE/ENABLE=IMAGE
Execute the UUCP command(s) which fail.
$ ACCOUNTING/SINCE=TODAY
Post that output and let's see if there's anything revealing in there.
Also, you can $ SET ACCOUNTING/DISABLE=IMAGE because /ENABLE=IMAGE can
become a resource hog.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
He may be ROTFL because of the 6.3 reference :)
Van: Cory Smelosky
Verzonden: maandag 7 oktober 2013 01:19
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] OpenVMS on VAXstation 4000/60
yOn Sun, 6 Oct 2013, Brian Schenkenberger, VAXman- wrote:
> Daniel Soderstrom <snaggs at mac.com> writes:
>
>>
>>> =20
>>> Lighter???
>>> =20
>>> FWIW, you'd be much better off running the latest and greatest on your VAX=
>>
>>> hardware to take advantage of the performance features contained within=20=
>>
>>
>> VMS 3
>> 0.9 million lines of code
>>
>> VMS 5.4
>> 6.5 million lines of code
>>
>> VMS 7.1
>> 25 million lines of code
>>
>> I'd like to go back to 5.5H4 and avoid the bloat from OO programming. I was g=
>> iven advice previously that 6.3 is best for old VAX's.=20
>
> OO! ROTFLMFA0!
>
>
OpenVMS may be written in about 8 different languages but I'm fairly sure
none are OO...except MAYBE the few C++ bits according to Wikipedia.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
