On 10/11/2021 8:08 PM, Lawrence D’Oliveiro wrote:
> On Monday, October 11, 2021 at 9:54:19 PM UTC+13, John Wallace
> wrote:
>> DLM a standard part of Linux? But *which* DLM, *which* Linux?
>
> Turns out it’s a standard package in Debian
> <https://packages.debian.org/bullseye/libdlm3>, and therefore in most
> Linux distros.

libdlm is the user mode code to access the DLM. And should be available
in practically all distros.

The DLM itself is in the kernel.

Arne

On 10/11/2021 8:14 PM, Lawrence D’Oliveiro wrote:
> Which brings us to a point I’ve made before: the Linux kernel already
> runs on every architecture that VMS users and developers might care
> about, now and into the future. It already has a range of drivers for
> common (and not-so-common) hardware, including that in enterprise
> use. It includes a robust, high-performance TCP/IP stack.
>
> Wouldn’t it be easier to just keep the parts of VMS that users and
> developers need, and implement them as a compatibility layer on top
> of a Linux kernel? And just scrap the rest. Wouldn’t that save a lot
> of effort?

Probably not.

Getting VMS compilers, VMS language RTL, VMS RTL,
RMS, VMS system services and DCL working on Linux
in a fully compatible manner would be very tricky.

Getting something sort of VMSish up and running
may be easier. In fact I believe there are companies
selling such products already. But they have not
taken away the VMS market.

Arne

On Tuesday, October 12, 2021 at 1:34:47 PM UTC+13, Arne Vajhøj wrote:
> Getting VMS compilers, VMS language RTL, VMS RTL,
> RMS, VMS system services and DCL working on Linux
> in a fully compatible manner would be very tricky.

Still less than the ongoing costs of porting the whole of VMS onto new hardware. Like revamping an antiquated driver model with no support for hotplugging, PCI-E, USB, iSCSI, Fibre Channel, 10G+ Ethernet, NUMA, GPGPU, scalability to thousands of processors ... all of which you would get for free.

On 10/12/2021 9:46 AM, Lawrence D’Oliveiro wrote:
> On Tuesday, October 12, 2021 at 1:34:47 PM UTC+13, Arne Vajhøj
> wrote:
>> Getting VMS compilers, VMS language RTL, VMS RTL, RMS, VMS system
>> services and DCL working on Linux in a fully compatible manner
>> would be very tricky.
>
> Still less than the ongoing costs of porting the whole of VMS onto
> new hardware.

I doubt that.

There is really not that much ISA specific in an OS. VMS needs
Macro-32, Bliss, C VMS extensions etc. but they are needed by
customers anyway.

> Like revamping an antiquated driver model with no
> support for hotplugging, PCI-E, USB, iSCSI, Fibre Channel, 10G+
> Ethernet, NUMA, GPGPU, scalability to thousands of processors ... all
> of which you would get for free.

VMS already supports USB, iSCSI, FC, 10G ethernet etc..

CPU's may be limited to 64, but I don't think anyone will
want more (VMS is not for HPC).

Arne

On 10/11/2021 2:25 PM, Simon Clubley wrote:
> On 2021-10-09, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 10/9/2021 4:55 PM, Stephen Hoffman wrote:
>>> And here I was trying to explicitly not slag on RMS and its
>>> capabilities, as that'd solely serve provoke a torrent of folks quite
>>> reasonably pointing out that RMS is perfect for {app}.
>
> Actually to those people I would say that RMS is pretty much perfect - for
> applications written in Macro-32 that require record-level access.
>
> The RMS APIs perfectly match the huge level of work required in writing
> a full application in Macro-32 (that would be far easily written in a
> higher-level language) and perfectly matches Macro-32's utter inability
> to provide any meaningful abstraction layers in Macro-32 source code
> when compared to abstractions available in those same higher-level languages.
>
> The RMS APIs are what you would have designed in the 1970s. They are not
> what you would design in this century.

The RMS API is centered around FAB and RAB blocks.

But that concept is not Macro-32 centric at all. They are just
records/structs. That is common in all procedural languages
including Pascal, C, Cobol etc..

In the last 30 years they would have been made classes with
private fields and public accessor methods (C++, Java, C# etc.).
But still basically the same concept.

I suspect that you are again talking about the fact
that address fields did not increase from 32 to 64 bit
when moving from VAX to Alpha.

But that is independent of the FAB/RAB block concept.

FAB/RAB blocks could have been changed back then. But DEC
decided not to.

Arne

On 2021-10-12, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 10/11/2021 2:25 PM, Simon Clubley wrote:
>>
>> Actually to those people I would say that RMS is pretty much perfect - for
>> applications written in Macro-32 that require record-level access.
>>
>> The RMS APIs perfectly match the huge level of work required in writing
>> a full application in Macro-32 (that would be far easily written in a
>> higher-level language) and perfectly matches Macro-32's utter inability
>> to provide any meaningful abstraction layers in Macro-32 source code
>> when compared to abstractions available in those same higher-level languages.
>>
>> The RMS APIs are what you would have designed in the 1970s. They are not
>> what you would design in this century.
>
> The RMS API is centered around FAB and RAB blocks.
>
> But that concept is not Macro-32 centric at all. They are just
> records/structs. That is common in all procedural languages
> including Pascal, C, Cobol etc..
>

There's a slight difference in the available level of abstractions
in those languages compared to Macro-32. :-)

> In the last 30 years they would have been made classes with
> private fields and public accessor methods (C++, Java, C# etc.).
> But still basically the same concept.
>

Concept and implementation are two different things.

> I suspect that you are again talking about the fact
> that address fields did not increase from 32 to 64 bit
> when moving from VAX to Alpha.
>
> But that is independent of the FAB/RAB block concept.
>

But not of how they are implemented. No other operating system needs
to support assembly language as an application programming language.
In those operating systems, assembly language is only used for some
rare special cases in an application normally written in a higher-level
language.

> FAB/RAB blocks could have been changed back then. But DEC
> decided not to.
>

And now we are paying the technical debt for that decision.

BTW, I wonder, with the required changes for the new filesystems
for disks >2TB, if VSI will still support Macro-32 with the new
filesystems or if we are moving to data structures with abstracted
pointer sizes (and subroutine interfaces) just as in Unix and elsewhere.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 10/12/21 1:29 PM, Arne Vajhøj wrote:
> On 10/11/2021 2:25 PM, Simon Clubley wrote:
>> On 2021-10-09, Dave Froble <davef@tsoft-inc.com> wrote:
>>> On 10/9/2021 4:55 PM, Stephen Hoffman wrote:
>>>> And here I was trying to explicitly not slag on RMS and its
>>>> capabilities, as that'd solely serve provoke a torrent of folks quite
>>>> reasonably pointing out that RMS is perfect for {app}.
>>
>> Actually to those people I would say that RMS is pretty much perfect -
>> for
>> applications written in Macro-32 that require record-level access.
>>
>> The RMS APIs perfectly match the huge level of work required in writing
>> a full application in Macro-32 (that would be far easily written in a
>> higher-level language) and perfectly matches Macro-32's utter inability
>> to provide any meaningful abstraction layers in Macro-32 source code
>> when compared to abstractions available in those same higher-level
>> languages.
>>
>> The RMS APIs are what you would have designed in the 1970s. They are not
>> what you would design in this century.
>
> The RMS API is centered around FAB and RAB blocks.
>
> But that concept is not Macro-32 centric at all. They are just
> records/structs. That is common in all procedural languages
> including Pascal, C, Cobol etc..
>
> In the last 30 years they would have been made classes with
> private fields and public accessor methods (C++, Java, C# etc.).
> But still basically the same concept.
>
> I suspect that you are again talking about the fact
> that address fields did not increase from 32 to 64 bit
> when moving from VAX to Alpha.
>
> But that is independent of the FAB/RAB block concept.
>
> FAB/RAB blocks could have been changed back then. But DEC
> decided not to.
>

Yea, why would anyone ever need more than 32bits of addressable
data. :-)

bill

On 10/12/2021 1:57 PM, Simon Clubley wrote:
> On 2021-10-12, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 10/11/2021 2:25 PM, Simon Clubley wrote:
>>> Actually to those people I would say that RMS is pretty much perfect - for
>>> applications written in Macro-32 that require record-level access.
>>>
>>> The RMS APIs perfectly match the huge level of work required in writing
>>> a full application in Macro-32 (that would be far easily written in a
>>> higher-level language) and perfectly matches Macro-32's utter inability
>>> to provide any meaningful abstraction layers in Macro-32 source code
>>> when compared to abstractions available in those same higher-level languages.
>>>
>>> The RMS APIs are what you would have designed in the 1970s. They are not
>>> what you would design in this century.
>>
>> The RMS API is centered around FAB and RAB blocks.
>>
>> But that concept is not Macro-32 centric at all. They are just
>> records/structs. That is common in all procedural languages
>> including Pascal, C, Cobol etc..
>>
>
> There's a slight difference in the available level of abstractions
> in those languages compared to Macro-32. :-)

3GL languages are definite a higher abstraction level
than assembler.

But that does not change that passing records is not an assembler
thing.

In fact I suspect that is more common in 3GL than in assembler.

>> I suspect that you are again talking about the fact
>> that address fields did not increase from 32 to 64 bit
>> when moving from VAX to Alpha.
>>
>> But that is independent of the FAB/RAB block concept.
>
> But not of how they are implemented. No other operating system needs
> to support assembly language as an application programming language.
> In those operating systems, assembly language is only used for some
> rare special cases in an application normally written in a higher-level
> language.

Now you are talking business not technology.

It is not required to write applications in Macro-32 on VMS
or Linux or Windows or traditional Unix.

For various reasons (mostly around having relative many older
applications running in production) VMS unlike most other
OS got a significant number of applications relying on at least
some pieces in Macro-32.

So DEC/CPQ/HP(E)/VSI prioritize Macro-32 higher than
Microsoft and various Unix/Linux vendors.

Not because they like Macro-32 or for technical reasons
but simply because it is good business.

>> FAB/RAB blocks could have been changed back then. But DEC
>> decided not to.
>
> And now we are paying the technical debt for that decision.

Yes.

But there is no guarantee that VMS would exist today if DEC had decided
that for VMS Alpha compatibility did not matter.

> BTW, I wonder, with the required changes for the new filesystems
> for disks >2TB, if VSI will still support Macro-32 with the new
> filesystems or if we are moving to data structures with abstracted
> pointer sizes (and subroutine interfaces) just as in Unix and elsewhere.

I think your view of *nix is a bit too rosy.

Try read about lseek vs llseek vs lseek64, off_t vs off64_t vs loff_t
and how they behave depending on whether #define _FILE_OFFSET_BITS 64
is used or not.

Arne

On 10/11/2021 2:25 PM, Simon Clubley wrote:
> On 2021-10-09, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 10/9/2021 4:55 PM, Stephen Hoffman wrote:
>>>
>>> And here I was trying to explicitly not slag on RMS and its
>>> capabilities, as that'd solely serve provoke a torrent of folks quite
>>> reasonably pointing out that RMS is perfect for {app}.
>>>
>
> Actually to those people I would say that RMS is pretty much perfect - for
> applications written in Macro-32 that require record-level access.
>
> The RMS APIs perfectly match the huge level of work required in writing
> a full application in Macro-32 (that would be far easily written in a
> higher-level language) and perfectly matches Macro-32's utter inability
> to provide any meaningful abstraction layers in Macro-32 source code
> when compared to abstractions available in those same higher-level languages.

RMS is implemented at a particular level, and is available to all
languages. No problem there. The VMS languages use RMS to provide
services, and the usage from the languages is nowhere what you're
attempting to claim. The RMS API also allows direct calls when a
particular capability is not implemented in a language. Perhaps
something such as flush one or more I/O buffers to disk.

RMS is what it is, no more and no less. Your attack on RMS just isn't
called for.

Are there other methods for access to storage, yes, and an app designed
can select from the menu of available options.

While a bit aged, RMS still does what it always did. If that works,
then work it.

> The RMS APIs are what you would have designed in the 1970s. They are not
> what you would design in this century.

I would not be so sure of that statement. If RMS is a good fit for a
task, what's wrong with that?

When were you designed/implemented Simon? Perhaps you're too old for
this century?

> In this case, you would want the fields to be directly accessible
> from source code via a field-level API instead of a record-level API
> (as RMS is).

One can have both. Any RDBMS systems I've seen have both. I've got a
database product (aged) that has both.

Perhaps one of the greatest things about data field definitions as part
of the product is the ease with which general utility programs can be
designed and implemented.

--
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 10/12/2021 2:14 PM, Bill Gunshannon wrote:
> On 10/12/21 1:29 PM, Arne Vajhøj wrote:
>> I suspect that you are again talking about the fact
>> that address fields did not increase from 32 to 64 bit
>> when moving from VAX to Alpha.

>> FAB/RAB blocks could have been changed back then. But DEC
>> decided not to.
>
> Yea, why would anyone ever need more than 32bits of addressable
> data.  :-)

Well this was when they switched from 32 bit addresses
to 64 bit addresses (well at least architecturally - actual
support arrived later over time), so ...

But allowing VAX code to build on Alpha with minimum changes
was obviously a top priority.

Was that a good or bad decision?

I don't know.

But even if everybody agrees that it was a bad decision, then
it does not change that it was the decision back then.

Arne

On 10/12/2021 10:54 AM, Arne Vajhøj wrote:
> On 10/12/2021 9:46 AM, Lawrence D’Oliveiro wrote:
>> On Tuesday, October 12, 2021 at 1:34:47 PM UTC+13, Arne Vajhøj
>> wrote:
>>> Getting VMS compilers, VMS language RTL, VMS RTL, RMS, VMS system
>>> services and DCL working on Linux in a fully compatible manner
>>> would be very tricky.
>>
>> Still less than the ongoing costs of porting the whole of VMS onto
>> new hardware.
>
> I doubt that.
>
> There is really not that much ISA specific in an OS. VMS needs
> Macro-32, Bliss, C VMS extensions etc. but they are needed by
> customers anyway.
>
>> Like revamping an antiquated driver model with no
>> support for hotplugging, PCI-E, USB, iSCSI, Fibre Channel, 10G+
>> Ethernet, NUMA, GPGPU, scalability to thousands of processors ... all
>> of which you would get for free.
>
> VMS already supports USB, iSCSI, FC, 10G ethernet etc..
>
> CPU's may be limited to 64, but I don't think anyone will
> want more (VMS is not for HPC).
>
> Arne

You're wasting your time Arne. Lawrence is apparently a Linux fanboy,
who is speaking and not listening.

I'm guessing there are applications, and not an insignificant number,
which would suffer from doing away with Macro-32. Must be real easy to
dismiss other's concerns and needs.

You know, I'll bet there would be those who thinks his suggests have
merit. Hope none of them are in charge of anything.

--
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 Tuesday, October 12, 2021 at 1:29:57 PM UTC-4, Arne Vajhøj wrote:
> The RMS API is centered around FAB and RAB blocks.
>
> But that concept is not Macro-32 centric at all. They are just
> records/structs. That is common in all procedural languages
> including Pascal, C, Cobol etc..
>
> In the last 30 years they would have been made classes with
> private fields and public accessor methods (C++, Java, C# etc.).
> But still basically the same concept.
>

The RMS system services take 3 arguments, 2 of them are optional AST routines.
You'd want to re-evaluate whether you stick with ASTs, provide some other
synchronization object (e.g. completion queues), or do away with asynchronous
operation altogether.

On 10/12/2021 2:52 PM, David Jones wrote:
> On Tuesday, October 12, 2021 at 1:29:57 PM UTC-4, Arne Vajhøj wrote:
>> The RMS API is centered around FAB and RAB blocks.
>>
>> But that concept is not Macro-32 centric at all. They are just
>> records/structs. That is common in all procedural languages
>> including Pascal, C, Cobol etc..
>>
>> In the last 30 years they would have been made classes with
>> private fields and public accessor methods (C++, Java, C# etc.).
>> But still basically the same concept.
>
> The RMS system services take 3 arguments, 2 of them are optional AST routines.
> You'd want to re-evaluate whether you stick with ASTs, provide some other
> synchronization object (e.g. completion queues), or do away with asynchronous
> operation altogether.

The world has moved on a little bit the last 30-40 years.

The FAB/RAB block would be an instance of a FAB/RAB class
today.

The AST routines would likely be replaced by a slightly different
way to do asynchronous - maybe the async/await concept that
C# made popular.

But I think asynchronous would be kept. It is considered
in fashion today.

Arne

On 10/7/2021 1:25 PM, Dave Froble wrote:
> On 10/7/2021 11:50 AM, Arne Vajhøj wrote:
>> On 10/6/2021 10:00 PM, Lawrence D’Oliveiro wrote:
>>> Given that nowadays an SQL-based RDBMS like SQLite can offer full
>>> support for transactions, joins and subqueries (missing only more
>>> multi-user-type features like locking and replication), and yet still
>>> be resource-light enough to fit in your mobile phone, I would say the
>>> time for application developers to be grubbing about in ISAM files is
>>> past.
>>
>> There are still cases where it make sense. RMS index-sequential files
>> are really a NoSQL Key Value Store in modern terminology and
>> they are still used and new ones even being developed (like
>> RocksDB).
>>
>> But the default should change.
>>
>> "use index-sequential file unless good reason to use relational database"
>>
>> =>
>>
>> "use relational database unless good reason to use
>> index-sequential file"
>
> I'd suggest there should not be a "default".  Rather, make good
> thoughtful decisions.  Have valid reasons for any decisions or choices.

Fair enough.

But the money math has changed.

I would say that over the last 30 years:

RDBMS license cost changed from expensive to free options available

RDBMS hardware resource cost changed from expensive to insignificant

writing and maintaining code to manage IDX file cost is more or less
constant

Arne

On 10/12/2021 3:55 PM, Arne Vajhøj wrote:
> On 10/7/2021 1:25 PM, Dave Froble wrote:
>> On 10/7/2021 11:50 AM, Arne Vajhøj wrote:
>>> On 10/6/2021 10:00 PM, Lawrence D’Oliveiro wrote:
>>>> Given that nowadays an SQL-based RDBMS like SQLite can offer full
>>>> support for transactions, joins and subqueries (missing only more
>>>> multi-user-type features like locking and replication), and yet still
>>>> be resource-light enough to fit in your mobile phone, I would say the
>>>> time for application developers to be grubbing about in ISAM files is
>>>> past.
>>>
>>> There are still cases where it make sense. RMS index-sequential files
>>> are really a NoSQL Key Value Store in modern terminology and
>>> they are still used and new ones even being developed (like
>>> RocksDB).
>>>
>>> But the default should change.
>>>
>>> "use index-sequential file unless good reason to use relational
>>> database"
>>>
>>> =>
>>>
>>> "use relational database unless good reason to use
>>> index-sequential file"
>>
>> I'd suggest there should not be a "default". Rather, make good
>> thoughtful decisions. Have valid reasons for any decisions or choices.
>
> Fair enough.
>
> But the money math has changed.
>
> I would say that over the last 30 years:
>
> RDBMS license cost changed from expensive to free options available
>
> RDBMS hardware resource cost changed from expensive to insignificant
>
> writing and maintaining code to manage IDX file cost is more or less
> constant

Are you suggesting writing and maintaining code for RDBMS is any different?

--
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 10/12/2021 2:26 PM, Arne Vajhøj wrote:
> On 10/12/2021 2:14 PM, Bill Gunshannon wrote:
>> On 10/12/21 1:29 PM, Arne Vajhøj wrote:
>>> I suspect that you are again talking about the fact
>>> that address fields did not increase from 32 to 64 bit
>>> when moving from VAX to Alpha.
>
>>> FAB/RAB blocks could have been changed back then. But DEC
>>> decided not to.
>>
>> Yea, why would anyone ever need more than 32bits of addressable
>> data. :-)
>
> Well this was when they switched from 32 bit addresses
> to 64 bit addresses (well at least architecturally - actual
> support arrived later over time), so ...
>
> But allowing VAX code to build on Alpha with minimum changes
> was obviously a top priority.
>
> Was that a good or bad decision?
>
> I don't know.

How about this perspective?

I'd suggest that for DEC, keeping their existing customers was rather
important.

Are there volunteers working on Linux capabilities who just might not
give a damn whether anyone ever used Linux? Some might do it just for
fun. Some for ego, and didn't care if others considered their work usable.

Yes, I'm aware of all those developers who work for companies doing
Linux development, so don't go there.

Regardless, I think comparing Linux and VMS just isn't reasonable.

Linux is basically free, the developers are not counting on their work
to pay the mortgage.

DEC depended on revenue from VMS. Though that begs the question, why
were people at DEC trying to kill off VMS?

--
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 2021-10-12 00:14:15 +0000, Lawrence D’Oliveiro said:

> On Monday, October 11, 2021 at 1:30:36 AM UTC+13, chris wrote:
>>
>> On 10/10/21 01:12, Lawrence D’Oliveiro wrote:>>
>>> The key point is that VMS shied away from a radical idea that Unix
>>> embraced: that the filesystem itself should abstract away the need for
>>> blocking and deblocking, and offer up a file as just a stream of n
>>> bytes, with no requirement on n being a multiple of any integer greater
>>> than 1.
>>>
>> Yes, and at the lowest level, it's completely transparent to data and
>> it's format. Filesystems, structure and format should be layered in top
>> of that. Obvious really...

Swapping in a kernel file system API and a FUSE layer is a smaller and
more focused effort than would be re-hosting OpenVMS onto a different
kernel.

> Which brings us to a point I’ve made before: the Linux kernel already
> runs on every architecture that VMS users and developers might care
> about, now and into the future. It already has a range of drivers for
> common (and not-so-common) hardware, including that in enterprise use.
> It includes a robust, high-performance TCP/IP stack.

And Linux with longstanding features you are decidedly unfamiliar with, too.

> Wouldn’t it be easier to just keep the parts of VMS that users and
> developers need, and implement them as a compatibility layer on top of
> a Linux kernel? And just scrap the rest. Wouldn’t that save a lot of
> effort?

In aggregate, likely no.

Your suggestion is akin to Sector7 provides—an ever-growing but still
partial implementation of the OpenVMS APIs—for their customers.

A compatibility layer will involve substantial programming efforts
elsewhere within the platform; outside the now-swapped kernel.

This approach has been discussed before and has been prototyped before, too.

The DEC OpenVMS advanced development group did do a prototype of
OpenVMS on Mach a ~quarter-century ago.

https://www.semanticscholar.org/paper/A-Model-and-Prototype-of-VMS-Using-the-Mach-3.0-Wiecek/01810cffbddc949ff73a66b38de63f963d659db3?p2df

More recently, a similar starting point might be from seL4 or DragonflyBSD.

If you're going to invest the effort and swap the kernel, might as well
swap the existing kernel for a newer design.

Downside of any kernel-swappage is that you pretty quickly then own the
kernel you're working with; just as soon as you have to start modifying
the kernel to better fit OpenVMS and OpenVMS app expectations.

Which means you end up forking and then maintaining the kernel, and
maybe submitting pull requests upstream. And fetching and merging
updates and fixes from upstream. Whether that's all then a net benefit
or a net loss?

Possible areas where kernel modifications might necessary? Linux memory
management is thoroughly two-ring, and OpenVMS expectations are
four-ring. Do you drop those areas from OpenVMS, and force app source
code changes?

Other considerations awaiting VSI developers: any hypothetical chunks
of OpenVMS linked against Linux, seL4, or some of the other kernels
necessarily involves working within GPL2, which means VSI must write
all of that source code themselves, and must then release it.

The DragonflyBSD kernel started out with a focus on clustering, and
also has a license more compatible with commercial closed-source use.
Various other BSD kernels are similarly licensed.

VSI might (and likely only then very briefly) consider a kernel-swap
during the (hypothetical) OpenVMS port to Arm and (hypothetical) ARMv10
architecture servers later this decade or next (if enough of us are
hypothetically still around), but kernel swappage is still doubtful.

--
Pure Personal Opinion | HoffmanLabs LLC

On 10/12/2021 4:42 PM, Dave Froble wrote:
> On 10/12/2021 3:55 PM, Arne Vajhøj wrote:
>> On 10/7/2021 1:25 PM, Dave Froble wrote:
>>> On 10/7/2021 11:50 AM, Arne Vajhøj wrote:
>>>> On 10/6/2021 10:00 PM, Lawrence D’Oliveiro wrote:
>>>>> Given that nowadays an SQL-based RDBMS like SQLite can offer full
>>>>> support for transactions, joins and subqueries (missing only more
>>>>> multi-user-type features like locking and replication), and yet still
>>>>> be resource-light enough to fit in your mobile phone, I would say the
>>>>> time for application developers to be grubbing about in ISAM files is
>>>>> past.
>>>>
>>>> There are still cases where it make sense. RMS index-sequential files
>>>> are really a NoSQL Key Value Store in modern terminology and
>>>> they are still used and new ones even being developed (like
>>>> RocksDB).
>>>>
>>>> But the default should change.
>>>>
>>>> "use index-sequential file unless good reason to use relational
>>>> database"
>>>>
>>>> =>
>>>>
>>>> "use relational database unless good reason to use
>>>> index-sequential file"
>>>
>>> I'd suggest there should not be a "default".  Rather, make good
>>> thoughtful decisions.  Have valid reasons for any decisions or choices.
>>
>> Fair enough.
>>
>> But the money math has changed.
>>
>> I would say that over the last 30 years:
>>
>> RDBMS license cost changed from expensive to free options available
>>
>> RDBMS hardware resource cost changed from expensive to insignificant
>>
>> writing and maintaining code to manage IDX file cost is more or less
>> constant
>
> Are you suggesting writing and maintaining code for RDBMS is any different?

You need much less code because the database software does
so much.

It is a tradeoff - you write much less code but the generic code
in the RDBMS use more CPU and memory.

Arne

On 2021-10-12 14:54:37 +0000, Arne Vajhj said:

> On 10/12/2021 9:46 AM, Lawrence D’Oliveiro wrote:
>> On Tuesday, October 12, 2021 at 1:34:47 PM UTC+13, Arne Vajhøj
>> wrote:
>>> Getting VMS compilers, VMS language RTL, VMS RTL, RMS, VMS system
>>> services and DCL working on Linux in a fully compatible manner would be
>>> very tricky.
>>
>> Still less than the ongoing costs of porting the whole of VMS onto new
>> hardware.
>
> I doubt that.

I also doubt that any kernel-swap will be less work. See my previous
reply on that.

> There is really not that much ISA specific in an OS. VMS needs
> Macro-32, Bliss, C VMS extensions etc. but they are needed by customers
> anyway.

OpenVMS has had a whole lot of ISA dependencies over the years, but has
been incrementally moving those dependencies from hardware or firmware
into the kernel.

SWIS is where a whole lot of those VAX ISA dependencies now reside
within OpenVMS.

>> Like revamping an antiquated driver model with no support for
>> hotplugging, PCI-E, USB, iSCSI, Fibre Channel, 10G+ Ethernet, NUMA,
>> GPGPU, scalability to thousands of processors ... all of which you
>> would get for free.
>
> VMS already supports USB, iSCSI, FC, 10G ethernet etc..

PCIe: supported on Itanium rx2660 and newer.

Thunderbolt: OpenVMS is just getting to hardware with that support.

USB: USB 2.0. Support for USB 3.0, 3.1, 3.2, and USB4 will likely need
some work within OpenVMS.

iSCSI: not supported on OpenVMS past a now-abandoned software initiator
prototype. Might eventually see an iSCSI hardware initiator HBA. Adding
software (as was prototyped on OpenVMS) seems rather less likely.

FC: supported since Alpha, with yet-faster FC support added by VSI.

10GbE: supported. Support dates back a while, too.

40GbE: VSI is probably going to have to take a pretty good look at I/O
latency for this, as has been discussed here in comp.os.vms in
association with Linux I/O.

NUMA: supported on Alpha and newer. ~All of the big boxes booting
OpenVMS are NUMA.

GPGPU / NPU / TPU / etc: not available with OpenVMS. whether Vulkan,
CUDA, or ML acceleration or other such is interesting to OpenVMS folks?

Hot-plugging depends greatly on which devices or components are
involved. There has been some support for hot-plugging and hot-adding
some devices over the years, though that usually with hardware assists.

> CPU's may be limited to 64, but I don't think anyone will want more
> (VMS is not for HPC).

Current-generation x86-64 processors (Milan) offer 64 cores and 128
threads per socket.

--
Pure Personal Opinion | HoffmanLabs LLC

On Wednesday, October 13, 2021 at 7:19:04 AM UTC+13, Arne Vajhøj wrote:
> Try read about lseek vs llseek vs lseek64, off_t vs off64_t vs loff_t
> and how they behave depending on whether #define _FILE_OFFSET_BITS 64
> is used or not.

They were defined by POSIX to ease the transition between 32-bit and 64-bit systems, and they worked admirably for that purpose.

Compare the difficulties this issue has caused proprietary OSes like VMS and Windows ...

On Wednesday, October 13, 2021 at 7:19:39 AM UTC+13, Dave Froble wrote:
> RMS is what it is, no more and no less. Your attack on RMS just isn't
> called for.

Technology isn’t an end in itself, it is a means to an end. We create it to help us solve problems. When a piece of technology stops being part of the solution and starts being part of the problem, it is time to get rid of it.

On Wednesday, October 13, 2021 at 9:52:21 AM UTC+13, Dave Froble wrote:
> Linux is basically free, the developers are not counting on their work
> to pay the mortgage.

Actually, a lot of them are.

There continues to be this misconception that “free/libre” as in “free of restrictions” must mean “free/gratis” as in “you can’t make money from it”.

On Wednesday, October 13, 2021 at 9:52:21 AM UTC+13, Dave Froble wrote:
> Regardless, I think comparing Linux and VMS just isn't reasonable.

Some people see this kind of excuse as a way to neutralize the argument, when all it really does is concede it.

On Wednesday, October 13, 2021 at 9:54:14 AM UTC+13, Stephen Hoffman wrote:
> The DEC OpenVMS advanced development group did do a prototype of
> OpenVMS on Mach a ~quarter-century ago.

Yeah, but Mach is a microkernel, with all the downsides that microkernels have.

> More recently, a similar starting point might be from seL4 or DragonflyBSD.
>
> If you're going to invest the effort and swap the kernel, might as well
> swap the existing kernel for a newer design.

The trouble with the BSDs is that they do not have compatible kernels. So even though there are only a handful of BSD variants, it is difficult to port kernel-level enhancements between them. While there are something like 350 Linux distros and counting, they do share the same common kernel codebase (and nearly all of the userland too, just dressed up differently).

> Downside of any kernel-swappage is that you pretty quickly then own the
> kernel you're working with; just as soon as you have to start modifying
> the kernel to better fit OpenVMS and OpenVMS app expectations.

Try to avoid that. Also remember that the VMS apps are legacy apps; you are trying to maintain existing functionality, rather than take them in new directions. Major new development would be better off being Linux/POSIX-native.

> Possible areas where kernel modifications might necessary? Linux memory
> management is thoroughly two-ring, and OpenVMS expectations are
> four-ring. Do you drop those areas from OpenVMS, and force app source
> code changes?

Where is there app code that cares about this?

> Other considerations awaiting VSI developers: any hypothetical chunks
> of OpenVMS linked against Linux, seL4, or some of the other kernels
> necessarily involves working within GPL2, which means VSI must write
> all of that source code themselves, and must then release it.

Oracle vs Google notwithstanding, it has long been the position in most of the open-source community that APIs are not copyrightable.

On 10/12/2021 5:39 PM, Lawrence D’Oliveiro wrote:
> On Wednesday, October 13, 2021 at 9:54:14 AM UTC+13, Stephen Hoffman wrote:
>> Possible areas where kernel modifications might necessary? Linux memory
>> management is thoroughly two-ring, and OpenVMS expectations are
>> four-ring. Do you drop those areas from OpenVMS, and force app source
>> code changes?
>
> Where is there app code that cares about this?

Some.

Even though it may sound like totally irrelevant, then
there are implications.

The model with DCL in P1 space and loading and unloading
EXE in P0 space sort of rely on being able to blow the U stack
while keeping DCL in the S stack. And many programs depend
on process context.

>
>> Other considerations awaiting VSI developers: any hypothetical chunks
>> of OpenVMS linked against Linux, seL4, or some of the other kernels
>> necessarily involves working within GPL2, which means VSI must write
>> all of that source code themselves, and must then release it.
>
> Oracle vs Google notwithstanding, it has long been the position in most of the open-source community that APIs are not copyrightable.

Yes. But I am not sure that it is so relevant.

It is not a problem to keep user mode stuff under proprietary
license with a GPL kernel.

But keeping other kernel stuff under proprietary
license with an otherwise GPL kernel is potentially tricky.

The argument to use is well known:
proprietary kernel code---(non kernel specific API)---GPL kernel code

It has been used in the past.

But not all GPL people consider it a valid model.

Arne