[Info-vax] VMS x86 performance ?

[Bill Gunshannon]

On 11/3/20 11:10 AM, Dave Froble wrote:
> On 11/3/2020 10:32 AM, Bill Gunshannon wrote:
>> On 11/3/20 9:16 AM, Henry Crun wrote:
>>> On 03/11/2020 9:00, Phillip Helbig (undress to reply) wrote:
>>>> In article <rnp19d$al7$1 at dont-email.me>, Simon Clubley
>>>> <clubley at remove_me.eisner.decus.org-Earth.UFP> writes:
>>>>
>>>>> On 2020-10-31, Dave Froble <davef at tsoft-inc.com> wrote:
>>>>>> About 2 months after I started on VMS, RSTS was forgotten ....
>>>>>
>>>>> This times a million. The only thing I missed from RSTS/E was the
>>>>> ability to detach an interactive job and there were ways around
>>>>> that problem.
>>>>
>>>> That and command completion are the only two things on unix which I
>>>> don't have on VMS, though there are various workarounds.  Having said
>>>> that, these two things aren't as important on VMS as on unix.
>>>>
>>>
>>> Things I miss on VMS that I remember from RSTS/E
>>>
>>> 1. The SYSTAT cusp, which showed details of running jobs
>>> (Took a while, but I have a VMS equivalent. Linux has top and htop)
>>> 2. The UTILTY program which had an option to force input to another
>>> process
>>> (Useful for saving stuck users, or changing batch jobs mid-stream)
>>> 3.An undocumented, unsupported SYS call (IIRC SYS(chr(10...) ) which
>>> allowed
>>> a suitably privileged System Manager to see anaother process' or
>>> user's input buffers.
>>> (Not used often, but an occasional lifesaver!)
>>>
>>> OTOH what I don't miss:
>>> ACCT.SYS -- all the passwords readable, and using the KED editor
>>> (pre-EDT) left it readable on disk.
>>
>> A lot of systems (maybe most or all?) if they even had passwords
>> stored them unencrypted in those days.
>>
>>> Having to jump through hoops to use the equivalent of a batch queue
>>
>> Guess I don't know what "hoops" there were.  Running batch jobs on RSTS
>> was pretty much the same as on other OSes.  Some even required operator
>> intervention to run a batch job at all.
> 
> I've totally forgotten the RSTS batch capabilities.
> 
> I do seem to recall writing a line based text editor and printing stuff.

It was.  Like JCL on the IBM mainframes and ECL on the Unisys
Mainframes and Primos and pretty much everything else.  Unix
didn't have batch queues like the others but shell scripts and
the "at" command pretty much did the same.

> 
>>> TKB runs taking hours (The first time I ran LINK on VMS it completed
>>> so fast I was sure something was wrong!)
>>
>> That probably had more to do with the power of the system than the
>> commands used.  How long do you think TKB would take if RSTS still
>> ran today and the CPU's were all clocked in Ghz.
> 
> I like modular programming.  Perhaps it is because TKB so warped my 
> mind.  To this day I really don't like huge programs.  Always liked KISS.

Two different things entirely.   Good modular programming makes
building overlayed Programs easier but it isn't always necessary.
But good modular programming is just a good practice.


>  
>> It seems anytime people compare "the good ole days" they compare
>> 1970's systems to 2020 systems without allowing for differences like
>> changes in hardware technology.  If RSTS had been handled like VMS
>> it would be running on X86-64, using GB's of memory and modified to
>> take advantage of the new hardware without abandoning the underlying
>> philosophy of the OS.
> 
> Only if it had expanded the addressing ....

Every OS I have ever worked with that moved forward to a hardware
platform with larger address space took advantage of it.  Didn't
VMS when it went from VAX to Alpha and Itanium?  BSD certainly did.
And Linux.  And OS-9.

bill