On 09/01/2024 03:38, chrisq wrote:
> On 1/8/24 08:03, Gary R. Schmidt wrote:
>> On 08/01/2024 00:29, chrisq wrote:
>>> On 1/7/24 00:19, Dan Cross wrote:
>>>> In article <uncqas$pust$1@dont-email.me>,
>>>> Lawrence D'Oliveiro  <ldo@nz.invalid> wrote:
>>>>> On Sat, 6 Jan 2024 23:42:26 -0000 (UTC), Dan Cross wrote:
>>>>>
>>>>>> I remember pretty specifically maximum user limits on versions of
>>>>>> commercial Unix.
>>>>>
>>>>> How would such limits be enforced? Presumably they only applied to
>>>>> some
>>>>> extra-cost "layered product", not to the core OS.
>>>>
>>>> No, they applied to the OS as a while.
>>>
>>> Don't remember that at all. Not on SGI, Sun or HPUX, nor Ultrix, fwir.
>>>
>>> Examples ?...
>>>
>> HP-UX came with a two-login license by default, one for the console
>> and one to allow remote administration.  :-)
>>
>> Well, 7, 8, 9, and 10 did, I don't recall ever installing 11.x from
>> scratch.
>>
>> You had to order more if you wanted them, and it would occasionally
>> throw the monkeys at HP, at least here in OZ: "Why do you need more
>> user logins to run Oracle??"  "Because we don't just run Oracle, you
>> luser."
>>
>>      Cheers,
>>          Gary    B-)
>
>
> LOL Always thought HP-UX was a bit weird, but it's the result of buying
> another unix ws vendor, whose name forget. Like some i-other unix ws
> vendors in the early days, the overall structure and shell commands
> hadn't settled down to a common core...
>
Well, HP-UX 7 was just SYSV, with some additional Hewlett-Packard bumf
sed'ed into it, recompiled for the Spectrum (later PA-RISC)
architecture, I never saw it on anything else. (This was when they were
going from the HP3000 MPE 16-bit stack machines to the 32-bit Spectrum
RISC machines, wot ran either UNIX or MPE if you swapped a CMOS chip. :-) )

If you're thinking of Apollo and their Domain/OS thingie, that's a
completely different barrel of monkeys.

Cheers,
Gary B-)

On Mon, 8 Jan 2024 23:55:59 -0500, Dave Froble wrote:

> Did they have any clue about what VMS was, or how to sell it?

It had multi-letter device names, versus single letters in Windows NT, so
that alone meant it was some kind of voodoo black magic.

On Mon, 2024-01-08 at 12:20 +0000, Dan Cross wrote:
> > > I think there's a pretty big difference between what you run on
> > > your personal machine and a distro supported over thousands of
> > > seats.  I'm pretty sure you're not a maintainer of either Gentoo
> > > or Slackware.
> >
> > You'd be surprised. I once was a maintainer on Gentoo.
>
> Isn't anyone who submits a patch considered a Gentoo maintainer?
> Kind of like being a "Debian Developer"?

No, that's not how you create Gentoo maintainers. They are the ones who
builds and look after the packages available. I got a job and had to
give up the Gentoo maintaining thing.
--
Tactical Nuclear Kittens

On Mon, 2024-01-08 at 15:30 -0500, Arne Vajhøj wrote:
>
> No idea how accurate it is - I have never seen an Apollo computer.

I have once, my Dad was a draughtsman and was looking at CAD on these
computers at the time. He said they were ahead of their time. He ended
up using a 386 with AutoCAD for his work in the 90s.

Very nice displays.
--
Tactical Nuclear Kittens

In article <unia4a$1o881$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Mon, 8 Jan 2024 12:13:37 +0000, chrisq wrote:
>
>> On 1/8/24 02:36, Lawrence D'Oliveiro wrote:
>>
>>> On Mon, 8 Jan 2024 00:31:33 +0000, chrisq wrote:
>>>
>>>> No systemd either.
>>>
>>> Shame. With all their smarts, they never thought to implement something
>>> as clever as that.
>>
>> Clever ?, debatable. More like an impenetrable trainwreck.
>
>Remember, it became popular across a whole bunch of distros entirely
>through its own merits, not because there was some dominant, faceless
>MegaCorp pushing it on everybody.

Are you sure about that? Are you absolutely sure it wasn't a matter of "We
have to do this because Red Hat is doing it and we don't want our distro to
be too different?"
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Dave Froble <davef@tsoft-inc.com> wrote:
>On 1/8/2024 3:16 PM, Scott Dorsey wrote:
>> Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>>>
>>>> LOL Always thought HP-UX was a bit weird, but it's the result of buying
>>>> another unix ws vendor, whose name forget. Like some i-other unix ws
>>>> vendors in the early days, the overall structure and shell commands
>>>> hadn't settled down to a common core...
>>>
>>> I believe that you're thinking of Apollo, which had an operating
>>> system called "Domain/OS" (originally "AEGIS") which was not
>>> really Unix, though had a Unix "environment". It was done from
>>> scratch and more closely resembled Multics in internal
>>> sturcture.
>>
>> It wasn't even a little bit Unix, but it was very cool, and it offered a
>> real distributed environment on workstations years before anyone else even
>> thought about it.
>>
>>> Over time, HP ditched the underlying OS and went with their
>>> System V derivative instead.
>>
>> It wasn't so much over time, it was kind of abrupt. There were a few years
>> where you could buy an 700 with either HP-UX or Domain, but they really started
>> pushing HP-UX from the beginning. I don't think anyone at HP had any clue
>> what Domain really was or how to sell it.
>
>Did they have any clue about what VMS was, or how to sell it?

No, but that disaster came years later. Don't forget about Tandem NonStop either.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 2024-01-06 20:08:02 +0000, Lawrence D'Oliveiro said:

> On Sat, 6 Jan 2024 13:36:59 -0500, Stephen Hoffman wrote:
>
>> On 2024-01-06 02:48:42 +0000, Lawrence D'Oliveiro said:
>>
>>> That can be blamed on the limitations of Mach. People still seem to
>>> think microkernels are somehow a good idea, but they really don’t help
>>> much, do they?
>>
>> With current hardware including cores and performance and with newer
>> message-passing designs such as OKL4 and ilk, some things are looking
>> rather better.
>
> Hope springs eternal in the microkernel aficionado’s breast. ;)
>
>>>> As another example, it was not possible to emulate VMS’ strong
>>>> isolation of kernel resource usage by different users.
>>>
>>> Would the Linux cgroups functionality (as commonly used in the various
>>> container schemes) help with this?
>>
>> No.
>>
>> Designers of VAX/VMS chose a memory management model closer to that of
>> Multics, where much of the rest of hardware and software in the
>> industry diverged from that lotsa-rings memory management design.
>
> Seems you are confusing two different things here. I am aware of the
> user/supervisor/exec/kernel privilege-level business, but you did say
> “resource usage by different *users*”. cgroups are indeed designed to
> manage that.

Not that the implementation detail I'm referring to.

> Remember that my proposal for adopting the Linux kernel would get rid
> of every part of VMS that currently runs at higher than user mode. It’s
> only their own user-mode code that customers would care about.

That's a massive effort toward ring compression if not a wholesale
rewrite of userland, and for negligible savings in staff, for no
savings in initial schedule, and maybe for a faster next port of
OpenVMS to AArch64 or RISC V or whatever in a decade or two.

And given LLVM and compiler support has been a gating factor this time
'round, that hypothetical future port is already in much better shape
for any hypothetical future platform already supported by LLVM.

>
>> Containers are arguably fundamentally about product-licensing arbitrage, too.
>
> I don’t use them that way. I use them as a cheap way to run up multiple
> test installations of things I am working on, instead of resorting to
> full VMs. Typically it only takes a few gigabytes to create a new
> userland for a container. E.g. on this machine I am using now:
>
> root@theon:~ # du -ks /var/lib/lxc/*/rootfs/
> 1700060 /var/lib/lxc/debian10/rootfs/
> 7654028 /var/lib/lxc/debian11/rootfs/
> 876568 /var/lib/lxc/debian12/rootfs/

Good on you.

For the folks with massive bills for third-party dependencies,
containers are interesting for an entirely different reason.

>> Microkernels are in use all over the place nowadays, seL4-, L4-, and
>> OKL4-derived.
>
> Really?? Can you name some deployments? How would performance compare
> with Linux? Because, let’s face it, Linux is the standard for
> high-performance computing.

Off hand, only a billion or so devices in widespread usage for L4 with
one vendor. Probably more, given other usage at other vendors.

HPC is a different market. Not where OpenVMS was or is.

VAX/VMS was focused on commercial computing since the VAX era, and well
before Y2K. UNIX and then Linux got most of technical computing from
VAX/VMS as VAX and VMS prices increased and VAX performance decreased.

Yes, VAX/VMS was sorta kinda in high-performance computing decades ago
with VAX, but—outside of existing installs—not in decades.

As for OpenVMS in high performance, OpenVMS hasn't been particularly
supported on the vendor's own top-end hardware platforms; on
AlphaServer SC series, and on upper-end Superdome and Superdome 2
models. Superdome support was as a guest.

>> For a small development team—and VSI is tiny—kernel transplantation
>> doesn't gain much from a technical basis, once the platform port is
>> completed. It might help with future ports, sure.
>
> Which was my point all along: if they’d done this for the AMD64 port
> from the beginning, they would have shaved *years* off the development
> time. And likely ended up with a somewhat larger (remaining) customer
> base than they have now.

Not unless you mean way back at the juncture that mis-branched to
Itanium. Sledgehammer (and Yamhill) hadn't been officially announced
then.

The kernel transplant is larger than a port, for the first time around.
Much larger. After that, the effort is smaller when the host kernel
supports the target platform. And adding platforms is a form of
dilution for an operating system vendor, and for third-party
vendors. More work. More testing.

And again, what you are interested here in has been available for many
years via Sector 7. Sector 7 provides an incremental off-ramp from
OpenVMS for those that want or need that. But probably not a good
long-term model for any OS vendor.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2024-01-06 15:30:00 +0000, John Dallman said:

> First, complete the 64-bit API, after all these years. It's a fairly
> well-defined task, but I don't know how big it is.

There's no way to do that without breaking source-level compatibility,
and probably not without also doing a migration to a parallel set of
64-bit APIs.

Basically, the image activator examines the image and decides which
implementation to activate within; the existing 32- and 64-bit
implementation, or 64-bit new.

This implementation and this migration would also provide an
opportunity to toss out the most problematic parts of the existing
APIs. *stares at password hash APIs* *glances at thicket of C API
definitions* *rolls eyes at itemlists* *sighs and drags BASIC forward
to 64-bit and OO*

Some work in the linker and in the image activator here, and a whole
lot of work in the various user and kernel APIs, and work in app code
ranging from build procedures to an app overhaul. And work in the docs
too, of course.

--
Pure Personal Opinion | HoffmanLabs LLC

On Tue, 9 Jan 2024 14:43:06 -0500, Stephen Hoffman wrote:

> *glances at thicket of C API definitions*

The design of VMS system calls, with lots of arguments, most of them
optional, is really bad for a language that don’t allow argument passing
by keyword. But I would say that’s the fault of the language.

> *rolls eyes at itemlists*

I always thought they were kind of neat. What’s a better alternative for
exensibility?

> *sighs and drags BASIC forward to 64-bit and OO*

BASIC ... you got to be kidding, right?

If kids wanted to learn programming these days, I would point them at
Python.

On 9 Jan 2024 14:55:37 -0000, Scott Dorsey wrote:

> In article <unia4a$1o881$1@dont-email.me>,
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> Remember, [systemd] became popular across a whole bunch of distros
>> entirely through its own merits, not because there was some dominant,
>> faceless MegaCorp pushing it on everybody.
>
> Are you sure about that? Are you absolutely sure it wasn't a matter of
> "We have to do this because Red Hat is doing it and we don't want our
> distro to be too different?"

I’m talking about distros, like Debian, that never cared about Red Hat to
begin with.

On 1/9/2024 4:06 PM, John Dallman wrote:
> In article <unk7ka$24i3c$1@dont-email.me>, seaohveh@hoffmanlabs.invalid
> (Stephen Hoffman) wrote:
>
>> On 2024-01-06 15:30:00 +0000, John Dallman said:
>>> First, complete the 64-bit API, after all these years. It's a
>>> fairly well-defined task, but I don't know how big it is.
>> There's no way to do that without breaking source-level
>> compatibility, and probably not without also doing a migration to a
>> parallel set of 64-bit APIs.
>>
>> Basically, the image activator examines the image and decides which
>> implementation to activate within; the existing 32- and 64-bit
>> implementation, or 64-bit new.
>
> I was presuming that the 64-bit VMS APIs would have 64-bit specific names,
> as the 64-bit versions that already do, as best I know. That would means
> there were a full set of APIs, both 32-bit and 64-bit, at OS level, in
> the same implementation.

I think that is the only safe option.

> Cross-compiled MACRO-32 code could then gradually transition between them,
> by source adaptation. Higher-level languages could offer compiler options
> for selecting APIs.
>
> Or does this not make sense?

I suspect that all direct calls to LIB$ and SYS$ no matter if it is
Macro-32 or Fortran or C would have to be manually edited to use
new 64 bit capable version, but that the various language RTL
could switch to 64 bit capable versions transparently.

Arne

On Tue, 9 Jan 2024 21:06 +0000 (GMT Standard Time), John Dallman wrote:

> I was presuming that the 64-bit VMS APIs would have 64-bit specific
> names ...

Or use the same names, and just link against different versions of the
libraries, located in suitable architecture-specific directories, as
selected by the build script.

On 1/9/2024 3:19 PM, Lawrence D'Oliveiro wrote:
> On Tue, 9 Jan 2024 14:43:06 -0500, Stephen Hoffman wrote:
>> *sighs and drags BASIC forward to 64-bit and OO*
>
> BASIC ... you got to be kidding, right?
>
> If kids wanted to learn programming these days, I would point them at
> Python.

Education in elementary programming is probably out of
scope for VMS these days. And Basic was not the language
used back when VMS was used for that. There are other
reasons for enhancing Basic.

There is every reason to believe that a large part of
future business application development on VMS will
use non-native languages (Java, Groovy, Python, PHP,
JavaScript etc.), because that is what we see on
other platforms.

But some of those future business application development
will need to be native. It will need to link with old
native code or it will need need to use various
LIB$/SYS$ functions or for whatever reasons.

Fortran, Cobol and C should be deemed out of that race.

C++ is an obvious candidate, but not everyone likes C++.

Pascal and Basic have potential to evolve into strong
candidates as well if extended properly.

Arne

On Tue, 9 Jan 2024 14:32:48 -0500, Stephen Hoffman wrote:

> And again, what you are interested here in has been available for many
> years via Sector 7.

I’m not sure they did a comprehensive enough job. For instance, I remember
the previous time this came up, reading between the lines in one of their
case studies, the original customer scenario mentioned using DECnet, but
that was missiong from the description of the solution.

In article <unkdkr$25et9$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Tue, 9 Jan 2024 21:06 +0000 (GMT Standard Time), John Dallman wrote:
>
>> I was presuming that the 64-bit VMS APIs would have 64-bit specific
>> names ...
>
>Or use the same names, and just link against different versions of the
>libraries, located in suitable architecture-specific directories, as
>selected by the build script.

Linux did it with different versions in different directories with the
same name. Solaris did it with different names. In the end the Solaris
route was much less frustrating to debug.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 9 Jan 2024 22:56:47 -0000, Scott Dorsey wrote:

> In article <unkdkr$25et9$1@dont-email.me>,
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>On Tue, 9 Jan 2024 21:06 +0000 (GMT Standard Time), John Dallman wrote:
>>
>>> I was presuming that the 64-bit VMS APIs would have 64-bit specific
>>> names ...
>>
>>Or use the same names, and just link against different versions of the
>>libraries, located in suitable architecture-specific directories, as
>>selected by the build script.
>
> Linux did it with different versions in different directories with the
> same name. Solaris did it with different names. In the end the Solaris
> route was much less frustrating to debug.

Solaris never ran on 2 dozen different architectures though, did it?

On 1/9/2024 2:43 PM, Stephen Hoffman wrote:
> On 2024-01-06 15:30:00 +0000, John Dallman said:
>
>> First, complete the 64-bit API, after all these years. It's a fairly
>> well-defined task, but I don't know how big it is.
>
> There's no way to do that without breaking source-level compatibility, and
> probably not without also doing a migration to a parallel set of 64-bit APIs.
>
> Basically, the image activator examines the image and decides which
> implementation to activate within; the existing 32- and 64-bit implementation,
> or 64-bit new.
>
> This implementation and this migration would also provide an opportunity to toss
> out the most problematic parts of the existing APIs. *stares at password hash
> APIs* *glances at thicket of C API definitions* *rolls eyes at itemlists* *sighs
> and drags BASIC forward to 64-bit and OO*
>
> Some work in the linker and in the image activator here, and a whole lot of work
> in the various user and kernel APIs, and work in app code ranging from build
> procedures to an app overhaul. And work in the docs too, of course.
>
>

Ok, correct me if I'm wrong.

As far as I know, totally 64 bit apps can be implemented on VMS. So, what's the
problem. The fact that there is also that 32 bit capability hanging around
should not be a detriment, right?

I seriously doubt that any Basic users would take advantage of a conversion to
64 bit addresses. So why bother?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/9/2024 3:19 PM, Lawrence D'Oliveiro wrote:
> On Tue, 9 Jan 2024 14:43:06 -0500, Stephen Hoffman wrote:
>
>> *glances at thicket of C API definitions*
>
> The design of VMS system calls, with lots of arguments, most of them
> optional, is really bad for a language that don’t allow argument passing
> by keyword. But I would say that’s the fault of the language.
>
>> *rolls eyes at itemlists*
>
> I always thought they were kind of neat. What’s a better alternative for
> exensibility?
>
>> *sighs and drags BASIC forward to 64-bit and OO*
>
> BASIC ... you got to be kidding, right?
>
> If kids wanted to learn programming these days, I would point them at
> Python.
>

Bigot alert ....

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/9/2024 6:33 PM, Dave Froble wrote:
> Ok, correct me if I'm wrong.
>
> As far as I know, totally 64 bit apps can be implemented on VMS.  So,
> what's the problem.  The fact that there is also that 32 bit capability
> hanging around should not be a detriment, right?

I don't have a problem with API's expecting 32 bit pointers being present.

I have a problem with the situations where there is a function
expecting 32 bit pointers but no function expecting 64 bit pointers.
When one for whatever reason have a pointer to something
up in P2 space. Allocating memory in P0 space, copy from
P2 to P0, call function, copy back if necessary and
deallocate it not elegant.

> I seriously doubt that any Basic users would take advantage of a
> conversion to 64 bit addresses.  So why bother?

Depends on what VSI's long term plan for Basic is.

"build legacy source code, but do new development in other
languages" => probably no need for 64 bit support

"evolve language and encourage new development in it" => it
will need 64 bit support.

And as I stated in another post, then Pascal and Basic
are the two most interesting languages for evolution among
the traditional VMS languages.

Arne

On 1/9/2024 4:35 PM, John Dallman wrote:
> In article <unkd47$25cg2$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
> wrote:
>> I suspect that all direct calls to LIB$ and SYS$ no matter if it is
>> Macro-32 or Fortran or C would have to be manually edited to use
>> new 64 bit capable version, but that the various language RTL
>> could switch to 64 bit capable versions transparently.
>
> With a sufficiently regular naming scheme, a compiler could make
> substitutions, but I don't know if the current scheme will cope.

If the arguments are simple buffer addresses, then maybe the
compiler could do something.

But what with more complex data structures like item lists?

A Fortran compiler could add a 64 to the function name called and
could pass a 64 bit descriptor instead of a 32 bit descriptor for
a string. But I can't imagine it changing all the addresses
in an item list from INTEGER*4 to INTEGER*8.

Arne

On Tue, 9 Jan 2024 18:34:27 -0500, Dave Froble wrote:

> On 1/9/2024 3:19 PM, Lawrence D'Oliveiro wrote:
>
>> BASIC ... you got to be kidding, right?
>>
>> If kids wanted to learn programming these days, I would point them at
>> Python.
>>
> Bigot alert ....

Did I step on somebody’s BASIC-loving toes?

On Tue, 9 Jan 2024 18:33:13 -0500, Dave Froble wrote:

> I seriously doubt that any [noddy] users would take advantage of a
> conversion to 64 bit addresses. So why bother?

In the x86-32/x86-64 situation in particular, the 32-bit architecture is
known for being register-poor. This is alleviated somewhat in the 64-bit
extensions. This means a compiler can generate more efficient code using
the 64-bit instructions.

In article <unkjij$26ao8$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On 9 Jan 2024 22:56:47 -0000, Scott Dorsey wrote:
>
>> In article <unkdkr$25et9$1@dont-email.me>,
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>
>>>On Tue, 9 Jan 2024 21:06 +0000 (GMT Standard Time), John Dallman wrote:
>>>
>>>> I was presuming that the 64-bit VMS APIs would have 64-bit specific
>>>> names ...
>>>
>>>Or use the same names, and just link against different versions of the
>>>libraries, located in suitable architecture-specific directories, as
>>>selected by the build script.
>>
>> Linux did it with different versions in different directories with the
>> same name. Solaris did it with different names. In the end the Solaris
>> route was much less frustrating to debug.
>
>Solaris never ran on 2 dozen different architectures though, did it?

Not at the same time. Only two at the same time.

Same with VMS, which did have a 16-bit compatibility mode to run code of
two different architectures at the same time early on.

The Pr1me fifty-series, now THOSE had dozens of different architectures in
the same box, seemingly. Because you can never have enough mode bits.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 10 Jan 2024 00:15:59 -0000, Scott Dorsey wrote:

> In article <unkjij$26ao8$1@dont-email.me>,
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>On 9 Jan 2024 22:56:47 -0000, Scott Dorsey wrote:
>>
>>> In article <unkdkr$25et9$1@dont-email.me>,
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>>
>>>>On Tue, 9 Jan 2024 21:06 +0000 (GMT Standard Time), John Dallman
>>>>wrote:
>>>>
>>>>> I was presuming that the 64-bit VMS APIs would have 64-bit specific
>>>>> names ...
>>>>
>>>>Or use the same names, and just link against different versions of the
>>>>libraries, located in suitable architecture-specific directories, as
>>>>selected by the build script.
>>>
>>> Linux did it with different versions in different directories with the
>>> same name. Solaris did it with different names. In the end the
>>> Solaris route was much less frustrating to debug.
>>
>>Solaris never ran on 2 dozen different architectures though, did it?
>
> Not at the same time. Only two at the same time.

Note how a distro like Debian does it, with its “multiarch” concept. This
allows multiple installations of the same distro version, for different
architectures, to share large (at least readonly) parts of their root
filesystems. Debian supports something close to a dozen different
architectures, last I checked.

What alternative to architecture-specific library directories would there
be, that would scale to such a setup?

On 1/9/2024 7:14 PM, Lawrence D'Oliveiro wrote:
> On Tue, 9 Jan 2024 18:33:13 -0500, Dave Froble wrote:
>> I seriously doubt that any [noddy] users would take advantage of a
>> conversion to 64 bit addresses. So why bother?
>
> In the x86-32/x86-64 situation in particular, the 32-bit architecture is
> known for being register-poor. This is alleviated somewhat in the 64-bit
> extensions. This means a compiler can generate more efficient code using
> the 64-bit instructions.

And?

The VMS 32 vs 64 bit discussion has nothing to do with traditional
32 bit vs 64 bit.

There has never been and never will be a VMS Basic for x86 (IA-32).

VMS Basic is expected to become available for VMS x86-64 any day.

And we expect it to store 32 bit pointers because that is
what it does on Alpha and Itanium.

It will use x86-64 instructions and x86-64 registers and x86-64
address space and so on.

And we are discussing whether it some day in the future should
switch to use 64 bit pointers.

Arne