[Info-vax] Creating an open source version of VMS, was: Re: OpenVMS Hobbyist Notification

[Arne Vajhøj]

On 3/12/2020 10:59 AM, Tim Lovern wrote:
> On Wednesday, March 11, 2020 at 7:12:58 PM UTC-7, Simon Clubley wrote:
>> A really good example is RMS and the control blocks and what happened
>> during the move to 64-bit processes.
>>
>> In Unix land, an address variable looks like this:
>>
>> 	{some data type or struct} *ptr;
>> 	ptr = data_structure->flink;
>>
>> The Unix land compiler, regardless of language, handles all the conversions
>> from 32-bit pointers to 64-bit pointers when you rebuild this code for
>> 64-bit mode without you having to change this code.
>>
>> In VMS land, thanks to the need to support Macro-32, an address
>> looks something like this:
>>
>> 	uint32 ptr;
>> 	ptr = (uint32) source_address;	/* YUCK YUCK YUCK ! :-) */
>>
>> with total loss of any address attribute information.
>>
>> If all these raw longwords were not user-visible in the way they are
>> in VMS thanks to Macro-32, and you only needed to support higher level
>> languages, then the move to 64-bit VMS might have been as simple as
>> compiling and linking your code for 64-bit mode instead of 32-bit mode.
>>
>> Without the need to support Macro-32, the RMS control blocks would
>> have been written for higher level languages with proper pointer
>> and other abstracted variable types which automatically change size
>> during compilation and linking as required.
>>
>> RMS would know it was dealing with a 64-bit process (from the process
>> attribute information) and would know what the offsets it needed
>> for 64-bit mode instead of 32-bit mode without you having to change
>> your source code.
>>
>> Instead you get the user-visible RAB64 structure and all the 32-bit
>> limitations which are applied to RMS. :-(
>>
>> This is one area in which Unix style code is _way_ cleaner than
>> VMS style code due to C being the lowest supported level of language
>> in the Unix world, instead of assembly language as in the VMS world.

> It would be cleaner to use an OOL, where you used a factory model to
> return things like a RAB object, then used setters and getters to
> manipulate the values.
> 
> The factory would return an object with all the pointer details
> hidden - they'd be of the correct size and type. The setters and
> getters would handle any boxing and unboxing of values.
> 
> Reflection could be used if you needed to know any of the
> implementation details.
> 
> your code wouldn't care (shouldn't care?)  what size pointers were,
> and shouldn't care about word vs longword vs octaword, etc.
> 
> just throwing out a thought, however disjointed and ill conceived.
Of course it could be done better today.

But the design chosen back in the 1970's worked fine
with the available languages at the time (Macro-32,
Fortran, Basic, Cobol, Pascal, C).

OO was not an option.

They basically had two options:
- procedural with large data structures being processed in single call
- procedural with single data items resulting in lots of calls

They chose the first.

Given how heavy CALLS and CALLG were then it was probably the
correct choice.

I saw the same type of blocks on CDC NOS.

Arne