[Info-vax] VMS documentation, was: Re: Special deals on Tape Drives

[Arne Vajhøj]

On 3/14/2022 2:48 PM, Simon Clubley wrote:
> On 2022-03-12, Arne Vajhøj <arne at vajhoej.dk> wrote:
>> On 3/12/2022 1:53 PM, Simon Clubley wrote:
>>>                      as well as the fact the documentation needs to be
>>> written at a lower level than with the Unix documentation to deal with
>>> all the exposed structures that in Unix are hidden behind call interfaces,
>>> C structs, etc.
>>
>> There is nothing low level in sending over complex structures instead
>> of simple data types. Almost all modern API's does that (it is just
>> called an object!).
> 
> RMS, Arne, RMS. In any sane environment, that's how it would be implemented
> behind the scenes in a OO language or behind a subroutine interface in C
> instead of being something that the user would have to directly manipulate.

Block, record, struct, object are really the same.

An object can provide a little extra encapsulation by having private
fields and public accessors and mutators, but that is just icing on
the cake.

RMS blocks is really the modern way.

> Also itemlists and having to specify every bit of information you want
> along with where to store it, instead of just returning an object (or a
> struct) containing all available fields and your program just referencing
> what it needs.

Item lists are a relative low level construct, but also only used
in low level calls SYS$ not LIB$.

It is easy to do better with a language supporting
maps/dictionaries/associative arrays and garbage collection.

But doing it memory and CPU efficient, non memory leaking and
binary upgradeable way is not easy in C or similar languages.

I believe something like the following is rather common:

typedef void *CTX;
...
CTX ctx;
foobar_init(&ctx);
foobar_something(&ctx);
foobar_cleanup(&ctx);

It may end up being easier to split the one function in a hundred
functions.

Which would have had a performance impact 40 years ago.

> Also, in Unix (thanks to C being the lowest supported language), pointers
> are an abstraction that the compiler deals with behind the scenes for you
> when it comes time to store them away and pass them around. In VMS,
> traditional pointers are an unabstracted and direcly exposed longword
> field that cannot just be automatically resized by passing "-m64" or
> similar on the compiler command line.

That is a not really a block problem.

If DEC had decided to go only 64 bit pointers on Alpha 30 years ago,
then the block definitions could have had 64 bit address fields
in blocks on Alpha and Itanium.

But they did not. For many reasons.

Arne