On Wednesday, October 13, 2021 at 6:57:05 AM UTC+13, Simon Clubley wrote:
> No other operating system needs
> to support assembly language as an application programming language.

I don’t think support for assembly language is the issue -- assembly language can still be useful and relevant in app code today, for example in video encoding. Here’s what I think the issue is about: “control blocks”.

RMS (and VMS) dates from the time when control blocks were a common way of communicating with OS services. A control block was a block of memory whose layout was defined by the OS, but lived in user space, so responsibility for its allocation and management was left to userland code. This way, it neatly avoided being counted against OS overhead. ;)

Then came Unix (and possibly also MULTICS and TENEX), where when you opened a file, all you got back was a small whole number*, a “file descriptor”. All the state that was part of that file descriptor lived in kernel space, and was managed by the kernel. All access by userland code to that state had to be done through system service calls.

You may have heard of the saying “in Unix, everything is a file”. Actually, things go a bit further nowadays: in *nix systems, every service (just about) becomes accessible through a file descriptor.

*I avoid saying “small integer” because remember, integers are signed, and negative integers are smaller than any positive integer.

On Wednesday, October 13, 2021 at 11:03:35 AM UTC+13, Arne Vajhøj wrote:
> But not all GPL people consider it a valid model.

The Linux kernel developers have said, more than once, that userland code that interfaces to the Linux kernel through userland APIs, can be published under any copyright licence that the copyright owner wishes, whether Free or non-Free.

On 2021-10-12 21:39:17 +0000, Lawrence D’Oliveiro said:

> 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.

Mach is an old microkernel, and techniques have improved markedly (q.v.
L4 family, etc)

Whether the performance limits from Mach message-passing from ~25 years
ago with those designs are even still applicable to modern hardware is
a discussion.

>> 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).

I'm aware of how Linux is structured and packaged.

Whatever alternative kernel might be chosen, VSI would still need to
comply with the software licenses.

As for scale, most or all of the major BSDs each have massively larger
deployments than does OpenVMS.

>> 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.

I am not so foolish as to fork without cause.

From my time in the OpenVMS kernel, I don't believe that a clean
re-hosting of the kernel onto the Linux kernel is possible without
Linux kernel modifications or a whole lot of work in the rest of
OpenVMS and the apps.

> Also remember that the VMS apps are legacy apps; you are trying to
> maintain existing functionality, rather than take them in new
> directions.

If you got that impression, you utterly misread the reply. If the
effort to re-host is underway, why re-host to Linux and not to a more
modern kernel design?

Also see previous discussions of and documentation for DEC MICA for
what once could have been, and for what became possible else-platform.

> Major new development would be better off being Linux/POSIX-native.

That work can happen over on Linux, or seL4, or BSD, or whatever
platforms the developers might choose among those that the vendors
might offer.

>> 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?

Apps that work with memory page protections, user-written system
services, logical names and the various modes, RMS file access and
channel modes, and various apps that use $cmexec or $cmkrnl calls,
among others. This ignores user-written device drivers and execlets,
which are also in use on a number of OpenVMS systems. As for VSI code,
the OpenVMS debugger has been dependent on page protection shenanigans
for breakpoint support, for instance—how that now works on x86-64, I've
not checked.

Many of the apps presently hosted on OpenVMS do tend to be tied to the
platform in various less-than-entirely-portable ways.

>> 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.

That's not at all what I am referring to with that.

--
Pure Personal Opinion | HoffmanLabs LLC

On 10/12/2021 6:14 PM, Lawrence D’Oliveiro wrote:
> On Wednesday, October 13, 2021 at 11:03:35 AM UTC+13, Arne Vajhøj
> wrote:

#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.
>
> The Linux kernel developers have said, more than once, that userland
> code that interfaces to the Linux kernel through userland APIs, can
> be published under any copyright licence that the copyright owner
> wishes, whether Free or non-Free.

Amazing what one can see if one actually read what
one is replying to.

Arne

On 2021-10-12 22:57:43 +0000, Stephen Hoffman said:
>
> That's not at all what I am referring to with that.

ps: The OpenVMS x86-64 kernel is available and those of us with V9.1-A
have it, which means re-hosting the kernel else-platform is not going
to happen any time soon.

And with the ability to run Linux, BSD, Windows or other guests within
a hypervisor on the same box, the effort of turning OpenVMS into a
Linux WSL or MICA-like or Sector7-like seems unlikely to draw much if
any interest.

Longer term, I don't see the point of re-hosting onto the Linux
kernel—the Linux kernel is fine and works well, it's just an older
design—for wholly rehosting a platform for future work.

If somebody is going to do that work, Linux isn't as big a step forward
as might otherwise be available.

For the near-term, adding paravirtualization picks up some hardware
support by using the drivers available within the hypervisor.

OpenVMS native driver support for x86-64 hardware will continue to
evolve over time too, both as VSI makes hardware plans and as customers
make hardware support requests to VSI.

Which in aggregate means next time that this kernel-rehosting
discussion might arise in earnest will probably be as a prelude to
porting to Arm, RISC-V, or some other architecture.

And I am still be skeptical of picking Linux as the target for
kernel-rehosting, maybe pending the addition of a Linux analog to WSL
or MICA.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2021-10-12 23:36:21 +0000, Arne Vajhj said:

> Amazing what one can see if one actually read what one is replying to.

Linux is the answer. What was the question again?

--
Pure Personal Opinion | HoffmanLabs LLC

On 10/12/2021 4:52 PM, Dave Froble wrote:

> Linux is basically free, the developers are not counting on their work to pay
> the mortgage.
Tell that to the many ex-DECcies (and others) who are quite happy
making a nice living at Redhat.

--
-- Rob

On 10/12/2021 6:13 PM, Lawrence D’Oliveiro wrote:
> RMS (and VMS) dates from the time when control blocks were a common
> way of communicating with OS services. A control block was a block of
> memory whose layout was defined by the OS, but lived in user space,
> so responsibility for its allocation and management was left to
> userland code. This way, it neatly avoided being counted against OS
> overhead. ;)
>
> Then came Unix (and possibly also MULTICS and TENEX), where when you
> opened a file, all you got back was a small whole number*, a “file
> descriptor”. All the state that was part of that file descriptor
> lived in kernel space, and was managed by the kernel. All access by
> userland code to that state had to be done through system service
> calls.

Multics and Unix are actually older than VMS.

But newer OS also has various blocks. Not the same
as VMS but other.

On your Linux system look in /usr/include/sys/*.h,
/usr/include/bits/*.h and /usr/include/linux/*.h.

Some of them VMS even inherited due to C and POSIX
(struct tm, struct stat etc.).

On Windows lots of structs are defined in
windows.h and what it includes

To mention a few random: CONSOLE_SCREEN_BUFFER_INFO,
NTFS_VOLUME_DATA_BUFFER, MEMORYSTATUS and
IP_OPTION_INFORMATION.

So RMS got FAB, RAB, NAM and XAB* and QIO got
FIB and FAT. Different types of blocks but
still blocks.

Arne

On Wednesday, October 13, 2021 at 11:57:45 AM UTC+13, Stephen Hoffman wrote:
> If the effort to re-host is underway, why re-host to Linux and not to a more
> modern kernel design?

What choice do you have?

On Wednesday, October 13, 2021 at 11:57:45 AM UTC+13, Stephen Hoffman wrote:
> the OpenVMS debugger has been dependent on page protection shenanigans
> for breakpoint support, for instance—how that now works on x86-64, I've
> not checked.

GNU GDB seems to manage OK.

Have a look here <https://manpages.debian.org/bullseye/manpages-dev/ptrace.2.en.html> and point out what you think is missing.

On 10/12/2021 5:10 PM, Arne Vajhøj wrote:
> 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
>

Excuse me, I'm just a dummy, come down out of the hills. But:

1) Open file
2) Access data
3) Do some work
4) Write/Update data
5) Done

and

1) Access database
2) Access data
3) Do some work
4) Write/Update data
5) Done

Guess I don't see much difference.

--
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 7:57 PM, Robert A. Brooks wrote:
> On 10/12/2021 4:52 PM, Dave Froble wrote:
>
>> Linux is basically free, the developers are not counting on their work
>> to pay the mortgage.
> Tell that to the many ex-DECcies (and others) who are quite happy
> making a nice living at Redhat.
>

So Robert, you're denying that you can download a free Linux
distribution and use it without paying?

Yes, I'm aware that there are people getting paid to work on Linux, both
in development, and at user sites.

An entity such as RedHat has figured out how to get people to pay them
for support.

I'm hoping that VSI figures out the same thing.

But DEC had a large number of employees, and it was from sales that they
got the money to run the company.

The topic was/is VAX to Alpha. How would VMS, and DEC, have faired, if
VAX users could not easily moved their applications to Alpha? Might
have been the end of DEC right then. DEC had to make the migration as
painless as possible, and they did a decent job of it. Many did a
re-compile, link, and go.

When Linux got started, there was no RedHat, and such. If people were
slow to use it, there was no company to go tits up. Only later did
companies embrace the OS, and pay people to work on it.

--
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 7:39 PM, Stephen Hoffman wrote:
> On 2021-10-12 23:36:21 +0000, Arne Vajhj said:
>
>> Amazing what one can see if one actually read what one is replying to.
>
> Linux is the answer. What was the question again?
>
>

What problem is the Linux solution searching for?

--
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 8:31 PM, Lawrence D’Oliveiro wrote:
> On Wednesday, October 13, 2021 at 11:57:45 AM UTC+13, Stephen Hoffman wrote:
>> If the effort to re-host is underway, why re-host to Linux and not to a more
>> modern kernel design?
>
> What choice do you have?
>

Are you claiming that Linux is the be-all and end-all of OS kernels?

The choices are many. Including entirely new designs.

You're sounding like the guy at the patent office way back declared that
everything to be invented has already been invented.

--
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 Wednesday, October 13, 2021 at 2:52:52 PM UTC+13, Dave Froble wrote:
> Excuse me, I'm just a dummy, come down out of the hills. But:
>
> 1) Open file
> 2) Access data
> 3) Do some work
> 4) Write/Update data
> 5) Done
>
> and
>
> 1) Access database
> 2) Access data
> 3) Do some work
> 4) Write/Update data
> 5) Done
>
> Guess I don't see much difference.

Why so complicated? Why not just:

1) Turn on computer
2) Compute.
3) When finished, turn off computer

Done.

On Wednesday, October 13, 2021 at 3:24:12 PM UTC+13, Dave Froble wrote:
>
> On 10/12/2021 8:31 PM, Lawrence D’Oliveiro wrote:
>>
>> On Wednesday, October 13, 2021 at 11:57:45 AM UTC+13, Stephen Hoffman wrote:
>>>
>>> If the effort to re-host is underway, why re-host to Linux and not to a more
>>> modern kernel design?
> >
> > What choice do you have?
>>
> The choices are many. Including entirely new designs.

How many of them offer as good as, or better, hardware support than you already have with VMS?

On Wednesday, October 13, 2021 at 3:07:13 PM UTC+13, Dave Froble wrote:
> An entity such as RedHat has figured out how to get people to pay them
> for support.

Not the only one. An entity such as myself has also figured out how to get people to pay me for support.

The good old car analogy comes to the fore again: sure, you can figure out how to service and fix your own car, but life is too short, so why not pay someone who has better skills than you will ever be able to acquire on that score, to do it for you? Then you have more time to do things that you find more interesting than fiddle with spanners and get covered in grease.

On Wednesday, October 13, 2021 at 3:07:13 PM UTC+13, Dave Froble wrote:
> When Linux got started, there was no RedHat, and such. If people were
> slow to use it, there was no company to go tits up. Only later did
> companies embrace the OS, and pay people to work on it.

Before the world had heard of Red Hat, DEC itself was responsible for a rather crucial multi-thousand-dollar investment in Linux. Back in about 1995, one of its staff, a certain Jon “Maddog” Hall, was able to persuade his employer to ship a brand-new, expensive, cutting-edge Alpha machine all the way to a young Comp Sci student out in Helsinki, whom precious few people had heard of at that time.

By 1996, Linux for Alpha was stable enough to ship. That was only the second architecture on which Linus Torvalds had implemented his brainchild at that time; so Linux went portable at the same time as it went 64-bit.

Meanwhile, Microsoft’s grandiose plans for its all-singing, all-dancing, next-generation “portable” OS, Windows NT, were only able to squeeze out a 32-bit Alpha port. Which didn’t last very long.

On 10/13/21 03:23, Dave Froble wrote:
> On 10/12/2021 8:31 PM, Lawrence D’Oliveiro wrote:
>> On Wednesday, October 13, 2021 at 11:57:45 AM UTC+13, Stephen Hoffman
>> wrote:
>>> If the effort to re-host is underway, why re-host to Linux and not to
>>> a more
>>> modern kernel design?
>>
>> What choice do you have?
>>
>
> Are you claiming that Linux is the be-all and end-all of OS kernels?
>
> The choices are many. Including entirely new designs.
>
> You're sounding like the guy at the patent office way back declared that
> everything to be invented has already been invented.
>

To each his own, but the reason why I dumped Linux forever was over the
systemd disaster. A seemingly modern replacement for the init startup
system. Tt now looks more like a mini kernel with the kernel, with
it's tentacles into every part of the system. Looked to me like a power
grab by Redhat, to control the future direction of Linux, but call me
paranoid if you must. Sun's Solaris also has layered system control
overlay, as does FreeBSD, but leaves all the original files intact, so
for example, you can still read the log file in text format. Linux is
far too bloated and all things to all men these days, rather than a
technically efficient OS. Been running FreeBSD for a few years now
and like breath of fresh air in software engineering terms. So, you
stick with VMS, even with limitations. I'm sure they will be addressed
in due course...

Chris

On 10/13/21 08:06, Lawrence D’Oliveiro wrote:
> On Wednesday, October 13, 2021 at 3:07:13 PM UTC+13, Dave Froble wrote:
>> When Linux got started, there was no RedHat, and such. If people were
>> slow to use it, there was no company to go tits up. Only later did
>> companies embrace the OS, and pay people to work on it.
>
> Before the world had heard of Red Hat, DEC itself was responsible for a rather crucial multi-thousand-dollar investment in Linux. Back in about 1995, one of its staff, a certain Jon “Maddog” Hall, was able to persuade his employer to ship a brand-new, expensive, cutting-edge Alpha machine all the way to a young Comp Sci student out in Helsinki, whom precious few people had heard of at that time.
>
> By 1996, Linux for Alpha was stable enough to ship. That was only the second architecture on which Linus Torvalds had implemented his brainchild at that time; so Linux went portable at the same time as it went 64-bit.
>
> Meanwhile, Microsoft’s grandiose plans for its all-singing, all-dancing, next-generation “portable” OS, Windows NT, were only able to squeeze out a 32-bit Alpha port. Which didn’t last very long.

Yes, it was stable enough to ship and still have a copy of Suse Linux
for Alpha on the shelf, but it was still fairly primitive at the time
X windows setup and framebuffer support was a hard work. In
the mid term, Linux was pretty good, but then came systemd, desktop
with dali style visual effects out of the box and it's just got
worse and bloated as time went on. No longer a serious technical, nor
elegant os anymore and would not recommend to anyone now...

Chris

On 10/12/2021 9:52 PM, Dave Froble wrote:
> On 10/12/2021 5:10 PM, Arne Vajhøj wrote:
>> On 10/12/2021 4:42 PM, Dave Froble wrote:
>>> On 10/12/2021 3:55 PM, Arne Vajhøj wrote:
>>>> 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.
>
> Excuse me, I'm just a dummy, come down out of the hills.  But:
>
> 1) Open file
> 2) Access data
> 3) Do some work
> 4) Write/Update data
> 5) Done
>
> and
>
> 1) Access database
> 2) Access data
> 3) Do some work
> 4) Write/Update data
> 5) Done
>
> Guess I don't see much difference.

That is because you describe *what* is being done not *how* it is done.

In general you can expect:

data maintenance - replacing a lot of application code with few lines of SQL

applications with simple queries - slightly less code

application code with complex queries - a lot less code

adhoc just get some numbers - replacing a lot of application code with
few lines of SQL

Arne

On 10/13/2021 2:50 AM, Lawrence D’Oliveiro wrote:
> On Wednesday, October 13, 2021 at 2:52:52 PM UTC+13, Dave Froble wrote:
>> Excuse me, I'm just a dummy, come down out of the hills. But:
>>
>> 1) Open file
>> 2) Access data
>> 3) Do some work
>> 4) Write/Update data
>> 5) Done
>>
>> and
>>
>> 1) Access database
>> 2) Access data
>> 3) Do some work
>> 4) Write/Update data
>> 5) Done
>>
>> Guess I don't see much difference.
>
> Why so complicated? Why not just:
>
> 1) Turn on computer
> 2) Compute.
> 3) When finished, turn off computer
>
> Done.
>

Even simpler, since my computers run 24 x 365.25

--
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/13/2021 10:04 AM, Arne Vajhøj wrote:
> On 10/12/2021 9:52 PM, Dave Froble wrote:
>> On 10/12/2021 5:10 PM, Arne Vajhøj wrote:
>>> On 10/12/2021 4:42 PM, Dave Froble wrote:
>>>> On 10/12/2021 3:55 PM, Arne Vajhøj wrote:
>>>>> 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.
>>
>> Excuse me, I'm just a dummy, come down out of the hills. But:
>>
>> 1) Open file
>> 2) Access data
>> 3) Do some work
>> 4) Write/Update data
>> 5) Done
>>
>> and
>>
>> 1) Access database
>> 2) Access data
>> 3) Do some work
>> 4) Write/Update data
>> 5) Done
>>
>> Guess I don't see much difference.
>
> That is because you describe *what* is being done not *how* it is done.
>
> In general you can expect:
>
> data maintenance - replacing a lot of application code with few lines of
> SQL

You claim that, but I just don't see it.

> applications with simple queries - slightly less code
>
> application code with complex queries - a lot less code
>
> adhoc just get some numbers - replacing a lot of application code with
> few lines of SQL

Don't see that.

Also, I've noticed that doing some things with SQL can be much more complex.

--
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

Den 2021-10-13 kl. 17:09, skrev Dave Froble:
> On 10/13/2021 10:04 AM, Arne Vajhøj wrote:
>> On 10/12/2021 9:52 PM, Dave Froble wrote:
>>> On 10/12/2021 5:10 PM, Arne Vajhøj wrote:
>>>> On 10/12/2021 4:42 PM, Dave Froble wrote:
>>>>> On 10/12/2021 3:55 PM, Arne Vajhøj wrote:
>>>>>> 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.
>>>
>>> Excuse me, I'm just a dummy, come down out of the hills.  But:
>>>
>>> 1) Open file
>>> 2) Access data
>>> 3) Do some work
>>> 4) Write/Update data
>>> 5) Done
>>>
>>> and
>>>
>>> 1) Access database
>>> 2) Access data
>>> 3) Do some work
>>> 4) Write/Update data
>>> 5) Done
>>>
>>> Guess I don't see much difference.
>>
>> That is because you describe *what* is being done not *how* it is done.
>>
>> In general you can expect:
>>
>> data maintenance - replacing a lot of application code with few lines of
>> SQL
>
> You claim that, but I just don't see it.
>
>> applications with simple queries - slightly less code
>>
>> application code with complex queries - a lot less code
>>
>> adhoc just get some numbers - replacing a lot of application code with
>> few lines of SQL
>
> Don't see that.
>
> Also, I've noticed that doing some things with SQL can be much more complex.
>
>

It is not clear what you have or haven't seen, but your conclusions
are a bit weird. It is so much easier to do data maintanance and
adhoq queries aginst a typical SQL database (such as Rdb) than to
try that against RMS data files. You are just completely wrong.

On 2021-10-12, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 10/12/2021 1:57 PM, Simon Clubley wrote:
>> 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.
>

Not really. Those are all about maximum supported file sizes.

VMS has a major additional problem that no other operating systems do
in that the size of an address is directly visible in program-visible
system call structures instead of being abstracted away by the compiler.

This is because the lowest supported application language on VMS is
Macro-32 but the lowest supported application language on those
other operating systems is C which has a pointer data type that
programs don't generally care about the size of.

About the only place I can immediately think it where does matter
elsewhere is in bounce buffers and there are supported interfaces
for those.

VMS is still a really good operating system for some things (such as
clustering) but design decisions make it much harder to port than with
other operating systems.

Simon.

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