[Info-vax] VAX VMS going forward

[Mark Berryman]

On 7/30/20 8:26 AM, Stephen Hoffman wrote:
> On 2020-07-30 00:45:18 +0000, John Reagan said:
> 
>> On Wednesday, July 29, 2020 at 12:12:49 PM UTC-4, Stephen Hoffman wrote:
>> .
>>>
>>> Again, go write a 64-bit app on OpenVMS.
>>>
>>
>> I'm still not sure what you mean....
>>
>> The Itanium linker is 1/2 BLISS-64 and 1/2 C.  For BLISS, it is pure 
>> BLISS-64 and doesn't use any of those crutches like 
>> /ASSUME=SIGNED_LONG.  For C, it is built with /POINTER=LONG.  The only 
>> "fall back to 32-bit" is using SYS$FILESCAN (and they really didn't 
>> need to) and some FAB/RAB/NAM/XAB pointers (we've already admitted 
>> that RMS only partially 64-bit tolerant).
> 
> There's rather more than the RMS structures that is either 32-bit only, 
> or 64-bit only. Though those are. Some system services are sys$mumble 
> and sys$mumble64, some sniff the arguments, etc. ODS-2 and ODS-5 are 
> 32-bit, too.
> 
> For the full experience, write up a non-trivial 64-bit app with file I/O 
> and network I/O and with network connection and encrypted-file security 
> and secure certificate and key storage, and with everything used by the 
> app—code and data—all of it—in 64-bit P2 space, and then write up some 
> documentation for it, and tell me how easy that experience was.  And 
> then load that new app in SYS$EXAMPLES, of course.
> 
> I'm here not referring to a 32-bit app with 64-bit data, but to trying 
> to create an app that's 64-bit throughout.
> 
> It's switches and knobs and variant API calls and fun like writing my 
> own parsing for itemlists, and the usual piles of OpenVMS glue code.
> 
> To get this 64-bit app working, it's not cc {sources} and link {objects} 
> and off I go with a 64-bit app. Nope. Gotta go read up on linker 
> switches and compiler switches and the rest, and wade through the APIs 
> looking for 32- and 64-bit calling details.

I have written 64-bit apps on VMS.  One that comes to mind was an AFP 
fileserver.  It was an AST-driven, threaded, 64-bit app.  The code was 
written in C.  I got it to the point where I was successfully serving 
files from my VMS system to my Mac, with filenames in any language. 
Sadly, I stopped working on it when Apple decided to abandon AFP in 
favor of SMB.

The only special compiler switch was /pointer_size
The only special linker switch was /threads_enable

My understanding of a 64-bit app is an app that can address data 
anywhere within the available 64-bit address space but doesn't 
particularly care where within that address space the data actually 
resides.  For my case:

All network data was in P2 space.

Very few CRTL functions were used, and none that interfaced with OS. 
For those, SYS$, LIB$, and STR$, calls were used.  Of those, the STR$ 
routines needed to specify 64-bit variants, the LIB$TREE functions and 
LIB$VM functions used 64-bit variants, and the only SYS$ function I can 
recall using that needed to specify a 64-bit variant was SYS$FAOL.

The application has a lot of dynamic string and binary data.  These were 
all allocated and freed by the system using STR$ calls and dynamic 
64-bit descriptors.  The app didn't care where the memory was allocated 
and neither did any of the routines that used that data.

The app used item lists.  These were all defined using the ILEB_64 macro.

Network I/O and ACP I/O is all done using QIOs.  QIOs are 64-bit.

In fact, the only place I can remember where I needed to explicitly use 
addresses that would fit in a 32-bit pointer were related to RMS.  The 
FAB and its data are 32-bit.  However, there was no buffer copying. 
Everything being fed to the FAB was via a parse routine that read data 
from a network buffer and put the result in a FAB buffer.  The parse 
routine was all 64-bit and it neither knew nor cared that some of data 
it was referencing lived in P0 space.

So, as far as I can remember when writing a 64-bit app, RMS needed 
special attention.  I don't remember that anything else did.  If there 
was anything else, it was only in a few places and clearly spelled out 
in the documentation.

Speaking only for myself, I happen to like the fact that 64-bit variants 
of various library and system calls were created where those calls 
originally only support 32-bit.  As has been mentioned previously, it 
allows for co-existance of code, even in the same program.  In fact, if 
VSI does decide to move from descriptor/item-list based APIs to Object 
oriented APIs, my hope is that they leave the current system and library 
calls alone and create new ones for the new API - something like SYSO$ 
or LIBO$.  This would make migrating to the new APIs, and eventually 
deprecating the old APIs, much easier.  Just a thought.

In conclusion, while there is certainly still some work to be done, I 
don't think it is that onerous to write a 64-bit app in current VMS.

Mark Berryman