[Info-vax] CRTL and RMS vs SSIO

[Arne Vajhøj]

On 10/12/2021 1:57 PM, Simon Clubley wrote:
> On 2021-10-12, Arne Vajhøj <arne at vajhoej.dk> wrote:
>> On 10/11/2021 2:25 PM, Simon Clubley wrote:
>>> Actually to those people I would say that RMS is pretty much perfect - for
>>> applications written in Macro-32 that require record-level access.
>>>
>>> The RMS APIs perfectly match the huge level of work required in writing
>>> a full application in Macro-32 (that would be far easily written in a
>>> higher-level language) and perfectly matches Macro-32's utter inability
>>> to provide any meaningful abstraction layers in Macro-32 source code
>>> when compared to abstractions available in those same higher-level languages.
>>>
>>> The RMS APIs are what you would have designed in the 1970s. They are not
>>> what you would design in this century.
>>
>> The RMS API is centered around FAB and RAB blocks.
>>
>> But that concept is not Macro-32 centric at all. They are just
>> records/structs. That is common in all procedural languages
>> including Pascal, C, Cobol etc..
>>
> 
> There's a slight difference in the available level of abstractions
> in those languages compared to Macro-32. :-)

3GL languages are definite a higher abstraction level
than assembler.

But that does not change that passing records is not an assembler
thing.

In fact I suspect that is more common in 3GL than in assembler.

>> I suspect that you are again talking about the fact
>> that address fields did not increase from 32 to 64 bit
>> when moving from VAX to Alpha.
>>
>> But that is independent of the FAB/RAB block concept.
> 
> But not of how they are implemented. No other operating system needs
> to support assembly language as an application programming language.
> In those operating systems, assembly language is only used for some
> rare special cases in an application normally written in a higher-level
> language.

Now you are talking business not technology.

It is not required to write applications in Macro-32 on VMS
or Linux or Windows or traditional Unix.

For various reasons (mostly around having relative many older
applications running in production) VMS unlike most other
OS got a significant number of applications relying on at least
some pieces in Macro-32.

So DEC/CPQ/HP(E)/VSI prioritize Macro-32 higher than
Microsoft and various Unix/Linux vendors.

Not because they like Macro-32 or for technical reasons
but simply because it is good business.

>> FAB/RAB blocks could have been changed back then. But DEC
>> decided not to.
> 
> And now we are paying the technical debt for that decision.

Yes.

But there is no guarantee that VMS would exist today if DEC had decided
that for VMS Alpha compatibility did not matter.

> BTW, I wonder, with the required changes for the new filesystems
> for disks >2TB, if VSI will still support Macro-32 with the new
> filesystems or if we are moving to data structures with abstracted
> pointer sizes (and subroutine interfaces) just as in Unix and elsewhere.

I think your view of *nix is a bit too rosy.

Try read about lseek vs llseek vs lseek64, off_t vs off64_t vs loff_t
and how they behave depending on whether #define _FILE_OFFSET_BITS 64
is used or not.

Arne