[Info-vax] $sndopr() and dsc64$descriptor

[Stephen Hoffman]

On 2021-03-11 18:41:06 +0000, Jim said:

> I've been having trouble find much in the way of doc or examples of 
> programming in 64 bit space...

I don't know that there are any 64-bit app examples published. VSI 
might have some in their support database. Beyond that?  That would be 
an interesting addition to SYS$EXAMPLES: on the OpenVMS x86-64 port, 
though; 64-bit code, 64-bit data, 64-bit LBNs, etc.

The OpenVMS V7.0 64-bit addressing is a marvelous design for requiring 
minimal and often no changes to existing apps and for maintaining app 
compatibility, with small and incremental adoption of 64-bit features 
within the app, and all of which was the design target for this 64-bit 
support work. And a design target well met.

When creating new 64-bit apps, this same 32-/64-bit hybrid design is 
unfortunately one of the more complex and developer-hostile designs.

Some existing APIs accept both 32-bit and 64-bit arguments 
transparently, some existing APIs are 32-bit including $sndopr and its 
inosculate parts, and while other APIs use added and parallel APIs and 
usually but not always with 64 appended to the existing API name.

And getting a 64-bit app built is a fun trip through compiler settings 
and linker settings too, for those compilers that do support 64-bit.  
While it's now possible to create these apps with code and data all in 
64-bit, I'd wager that only a negligible number of fully 64-bit OpenVMS 
apps actually exist. Lots of hybrid 32-/64-bit apps, yes. Fully 64-bit 
apps are really rare.

As one of various alternatives to the hybrid 32-/64-bit addressing 
design used, a parallel design with 32-bit apps staying 32-bit, and 
64-bit apps and APIs and tooling in parallel. With a decade or two to 
migrate apps fully to 64-bit. This also provides the opportunity to 
replace and finally retire some of the more problematic existing APIs, 
too.  DCL and the image activator would both have to support activating 
either 32- or 64-bit executables, though—modulo some minor 
modifications—those parts already do. It's the rest of the APIs...

Downside of this wholly-parallel addressing environments approach is a 
big one: apps with existing 32-bit app dependencies can and will 
increase the 64-bit migration costs, or can cost-prevent the migration 
entirely. This list includes app dependencies on deprecated or 
maintenance-only apps, as well as apps written in languages such as 
BASIC; anything that won't get ported to 64-bit. These dependencies 
include 32-bit parts of OpenVMS itself, $sndopr and OPCOM and operator 
logging are not the only hunks of 32-bit code within OpenVMS.

New apps were not the design target for the OpenVMS 32-/64-bit 
addressing work, nor was API simplicity. Nor are new apps and new 
development work a design target for OpenVMS more generally, and VSI 
has stated as much in a recent presentation. For what it was built for, 
the existing 32-/64-bit design works impressively very well, though.

It's trade-offs and compromises, all the way down.


-- 
Pure Personal Opinion | HoffmanLabs LLC