On 2021-10-13, Dave Froble <davef@tsoft-inc.com> wrote:
>
> Even simpler, since my computers run 24 x 365.25
>

So you shut them down over a leap second ? :-)

Simon.

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

On 2021-10-13, Lawrence D?Oliveiro <lawrencedo99@gmail.com> wrote:
> 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?

NetBSD ? :-)

Simon.

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

On 10/13/2021 11:09 AM, Dave Froble wrote:
> 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.

Here is an example of some (Python) code using SQL to
join, select, aggregate, sort and limit some data.

import sqlite3

con = sqlite3.connect('test.db')
c = con.cursor()
c.execute('''SELECT customers.name,SUM(orderlines.price) AS totalsales
FROM customers
LEFT JOIN orders ON customers.customer_id = orders.customer_id
LEFT JOIN orderlines ON orders.order_id = orderlines.order_id
WHERE orders.status = 'Delivered'
GROUP BY customers.name
HAVING totalsales > 10
ORDER BY totalsales DESC
LIMIT 3''')
for row in c.fetchall():
print('%s : %d' % (row[0], row[1]))
con.commit()
con.close()

I believe that it would take a lot more code to
retrieve data from index-sequential files and
do the work on the data.

Arne

On 2021-10-12, Lawrence D?Oliveiro <lawrencedo99@gmail.com> wrote:
> 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?.
>

The difference is the other operating systems don't need to support
calling system services (for example) from assembly language and if you
try it you are on your own. On VMS it does and it's supported as such.

Unfortunately.

(And yes, it's a product of the time VMS was designed in along with
the heritage that VMS inherited.)

Simon.

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

On 2021-10-13, chris <chris-nospam@tridac.net> wrote:
>
> 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.

You mean you didn't like editing and creating modelines ? :-)

That's a skill I once had that I don't miss losing to history...

(It was the same on x86 BTW. That wasn't Alpha specific.)

Simon.

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

On 2021-10-12, Lawrence D?Oliveiro <lawrencedo99@gmail.com> wrote:
> 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.
>

Microkernels have moved on and microkernels have massive security advantages.

BTW, QNX, which is a RTOS with a massive user base, is microkernel based.

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

Any program that interacts with DCL for one simple example.

In the current VMS design, you can't move DCL into user mode, or allow
user-controlled code to execute in DCL's supervisor mode, without ending
up with an operating system that has all the security of MS-DOS.

Other examples have already been posted.

Simon.

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

On 10/13/21 19:06, Simon Clubley wrote:
> On 2021-10-13, chris<chris-nospam@tridac.net> wrote:
>>
>> 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.
>
> You mean you didn't like editing and creating modelines ? :-)
>
> That's a skill I once had that I don't miss losing to history...
>
> (It was the same on x86 BTW. That wasn't Alpha specific.)
>
> Simon.
>

Seriously hard work, make sure it was documented once working,
because you would never remember the sequence of runes :-). Now,
we have luxury and on FreeBSD for instance, just include
"kld)_list=radeonkms" and on boot, the system interrogates
the monitor to optimise the resolution and even works through
the better kvm switches. Resolution issues were difficult to
keep in sync in the past over several machines and only one or
two monitors...

Chris

On 2021-10-13 18:01:54 +0000, Simon Clubley said:

> On 2021-10-12, Lawrence D?Oliveiro <lawrencedo99@gmail.com> wrote:
>> 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'.
>>
>
> The difference is the other operating systems don't need to support
> calling system services (for example) from assembly language and if you
> try it you are on your own. On VMS it does and it's supported as such.
>
> Unfortunately.
>
> (And yes, it's a product of the time VMS was designed in along with the
> heritage that VMS inherited.)

Macro32 isn't particularly limited in what it can call. Particularly as
compared with BASIC and other 32-bit apps and 32-bit APIs/ABIs present
on OpenVMS.

Macro32 has long had some 64-bit capabilities: $PUSH_ARG64, $CALL64,
..ENABLE QUADWORD, .CALL_ENTRY QUAD_ARGS=TRUE, etc.

Underneath your references to Macro32 too, the 1970s-style structure
definitions inherently mean any API or ABI changes will require changes
to app source code, across languages.

Any incompatible changes that will then effect Macro32 apps, and all
other apps calling system services and RMS services.

In C, that's going to entail changes to anything using char, short,
int, long long, int32_t, uint64_t, etc. with changed APIs.

These changes can absolutely happen—though not compatibly—and it'll
take a dozen years and probably more to migrate even the
actively-maintained apps across VSI and ISV and end-user apps.

I'd tend to aim for object APIs as the replacement here too, as that
trades off some run-time performance—not that itemlists were ever known
for performance-friendliness—for more flexible and extensible
interfaces later.

Not that I'd expect to ever meet Macroo32. 🤪

Again, you're dancing around the limits of a 1970s-era API/ABI design
and the general goal of upward-compatibility; of minimal disruptions to
existing 32-bit apps. Not any limits specific to Macro32.

The larger-scale and longer-term "fix" is a migration to a 64-bit only
environment, with the existing 32-/64-bit environment preserved for a
~decade pending deprecation, and eventually then removal. But that's
not happening.

And to be absolutely clear, I do not expect any substantial new Macro32
compiler work or features past what is needed for the port, and I do
not expect existing Macro32 apps will see anything more than
incremental work in existing Macro32.

TL;DR: it's the "control blocks" and the API design.

--
Pure Personal Opinion | HoffmanLabs LLC

On 10/13/2021 1:46 PM, Simon Clubley wrote:
> On 2021-10-13, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> Even simpler, since my computers run 24 x 365.25
>>
>
> So you shut them down over a leap second ? :-)
>
> Simon.
>

Well, I would, but it's over before I get a chance to do so.

--
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 12:42 PM, Jan-Erik Söderholm wrote:
> 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.

Ad hoc inquiries I'll give you. RDBMS is great for that.

But that wasn't in the discussion. Arne claimed that it took code to
use an RDBMS, and with some exceptions, that just isn't always so.

Yes, "SELECT * Where Name Like "Dave" is rather simple. But one must
still attach to the database. Request a Recordset. and so on.

A simple loop processing an RMS file looking in each record in the field
Name for "Dave" can be an open and a couple lines of code.

Not such a big 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/13/2021 1:59 PM, Arne Vajhøj wrote:
> On 10/13/2021 11:09 AM, Dave Froble wrote:
>> 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.
>
> Here is an example of some (Python) code using SQL to
> join, select, aggregate, sort and limit some data.
>
> import sqlite3
>
> con = sqlite3.connect('test.db')
> c = con.cursor()
> c.execute('''SELECT customers.name,SUM(orderlines.price) AS totalsales
> FROM customers
> LEFT JOIN orders ON customers.customer_id = orders.customer_id
> LEFT JOIN orderlines ON orders.order_id = orderlines.order_id
> WHERE orders.status = 'Delivered'
> GROUP BY customers.name
> HAVING totalsales > 10
> ORDER BY totalsales DESC
> LIMIT 3''')
> for row in c.fetchall():
> print('%s : %d' % (row[0], row[1]))
> con.commit()
> con.close()
>
> I believe that it would take a lot more code to
> retrieve data from index-sequential files and
> do the work on the data.
>
> Arne
>
>

Not a lot, however the sorting by customer name would entail some
additional code.

However, reading the order file, doing the selection, look-up customer
record, and release to record sort, then read back sorted records is not
"a lot more" code.

--
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 2:14 PM, Simon Clubley wrote:
> On 2021-10-12, Lawrence D?Oliveiro <lawrencedo99@gmail.com> wrote:
>> 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.
>>
>
> Microkernels have moved on and microkernels have massive security advantages.
>
> BTW, QNX, which is a RTOS with a massive user base, is microkernel based.
>
>>> 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?
>>
>
> Any program that interacts with DCL for one simple example.
>
> In the current VMS design, you can't move DCL into user mode, or allow
> user-controlled code to execute in DCL's supervisor mode, without ending
> up with an operating system that has all the security of MS-DOS.

MS-DOS has excellent security.

When nothing can be done, that is excellent security.

--
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 1:43 PM, Simon Clubley wrote:
> 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.

That seems pretty relevant to the question about file systems for large
disks.

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

It was a decision made 30 years ago to not extend those fields.

Problem? Maybe.

Major problem? I doubt it. Try count the number of questions about it.
Very few seems to have a problem with it in real life.

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

I believe that z/OS also has applications with some assembler.

But newer OS'es like Windows and Linux does not.

C was not that big a language when VMS was designed. I don't even
think VAX C was available with first VMS versions. So obviously
VMS API's was not defined in C.

Arne

On 10/13/2021 4:44 PM, Dave Froble wrote:
> On 10/13/2021 12:42 PM, Jan-Erik Söderholm wrote:
>> 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:
>>>>> 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.

Try add a column or update some values.

With a relational database in is one SQL statement.

With an index-sequential file it is writing a conversion program.

>>>> 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.
>
> Ad hoc inquiries I'll give you.  RDBMS is great for that.
>
> But that wasn't in the discussion.  Arne claimed that it took code to
> use an RDBMS, and with some exceptions, that just isn't always so.

I listed 4 different types of problems.

For two of them the relational database would mean replacing an
application with a one liner of SQL.

For two of them the relational database would mean an application
with less code, because the SQL replaces functionality in the code
with simple constructs.

> Yes, "SELECT * Where Name Like "Dave" is rather simple.  But one must
> still attach to the database.  Request a Recordset. and so on.
>
> A simple loop processing an RMS file looking in each record in the field
> Name for "Dave" can be an open and a couple lines of code.
>
> Not such a big difference.

Why I called that case for "slightly less code".

But then comes the more complex stuff.

Arne

In article <sjpojk$ctb$1@dont-email.me>, seaohveh@hoffmanlabs.invalid
(Stephen Hoffman) wrote:

> To Simon's comment, how DCL gets mapped into process address space
> is just ugly, too. And hard to debug.

Can someone point me to the documentation on this? It's something I've
never encountered.

John

On 10/13/2021 7:56 PM, John Dallman wrote:
> In article <sjpojk$ctb$1@dont-email.me>, seaohveh@hoffmanlabs.invalid
> (Stephen Hoffman) wrote:
>> To Simon's comment, how DCL gets mapped into process address space
>> is just ugly, too. And hard to debug.
>
> Can someone point me to the documentation on this? It's something I've
> never encountered.

Documentation for what?

That DCL (and DCLTABBLES) get mapped into P1 space (S mode stack)?

It is well known.

It must be somewhere in IDSM.

Arne

On Wednesday, October 13, 2021 at 11:36:00 PM UTC+13, chris wrote:
> 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.

There are no such things as “power grabs” in Free software. You are Free to choose, and the reason why there are 300-over Linux distros is precisely because it is so easy to exercise that choice. There are even quite a few options with no systemd in them.

Myself, I have found that systemd makes many things easier to do. For example, writing a .service file is a lot easier than creating an entire init script.

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

Debian systems currently (by default) run parallel text-based syslogs as well as the systemd journal.

Here’s one fun thing: text-based logfiles have their timestamps in the “system” timezone, which is a pretty nebulous concept on a *nix system. (Consider someone remoting from one part of the world, into a server in a different part, in response to a customer problem report originating in yet another part, logged in their local timezone.) The systemd journal records everything in UTC, and you can easily display entries in any timezone, just by setting “TZ=«timezone»” at the front of the command.

> Linux is far too bloated and all things to all men these days, rather than a
> technically efficient OS.

I don’t why you say that, when it has always been possible to build custom kernels that include only the features that you need. Remember, it runs happily on something as low-powered as the Raspberry π.

> Been running FreeBSD for a few years now and like breath of fresh air in software
> engineering terms.

Seems like their development is mainly dominated by one company these days, with perhaps a less-than-admirable attitude to code quality and security <https://arstechnica.com/gadgets/2021/03/buffer-overruns-license-violations-and-bad-code-freebsd-13s-close-call/> ...

On Thursday, October 14, 2021 at 4:10:52 AM UTC+13, Dave Froble wrote:
> Also, I've noticed that doing some things with SQL can be much more complex.

Only if you have to do them in COBOL!

On Thursday, October 14, 2021 at 6:46:38 AM UTC+13, Simon Clubley wrote:
> On 2021-10-13, Dave Froble <da...@tsoft-inc.com> wrote:
>>
>> Even simpler, since my computers run 24 x 365.25
>>
> So you shut them down over a leap second ? :-)

Actually I think 365.25 is already about a quarter of an hour longer than an actual sidereal year, so leap seconds are going to be lost in the rounding error ...

On Thursday, October 14, 2021 at 6:56:38 AM UTC+13, Simon Clubley wrote:

> On 2021-10-13, Lawrence D?Oliveiro <lawren...@gmail.com> wrote:
>>
>> 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?
>
> NetBSD ? :-)

Or, to put it another way, how many of them would make the job of porting to new architectures better, instead of worse?

Answer: none.

Except Linux.

On Thursday, October 14, 2021 at 7:14:08 AM UTC+13, Simon Clubley wrote:
>
> On 2021-10-12, Lawrence D?Oliveiro <lawren...@gmail.com> wrote:
>
>> 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.
>
> Microkernels have moved on and microkernels have massive security advantages.

Counterexample: Intel’s infamous Management Engine that exerts total control over its CPUs, that the OS cannot bypass, runs microkernel-based MINIX, and turned out to have massive security holes in it.

So the idea that microkernels have real-world security advantages is pretty dubious at best.

> BTW, QNX, which is a RTOS with a massive user base, is microkernel based.

I think it’s getting pushed aside by Linux in some areas. Remember NASA’s Mars copter? Yup, that was the first time running Linux and a bunch of other open-source software on another planet.

>>> 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?
>>
>
> Any program that interacts with DCL for one simple example.

The fact that DCL runs in supervisor mode is an internal implementation matter. It could be replaced by a thread or an entirely separate process (even a privileged one), for example, and what difference would that make to user-mode code?

> In the current VMS design, you can't move DCL into user mode, or allow
> user-controlled code to execute in DCL's supervisor mode, without ending
> up with an operating system that has all the security of MS-DOS.

Yes, but as far as I know there is no user-controlled code in DCL.

On Thursday, October 14, 2021 at 9:44:56 AM UTC+13, Dave Froble wrote:

> A simple loop processing an RMS file looking in each record in the field
> Name for "Dave" can be an open and a couple lines of code.
>
> Not such a big difference.

Even on a single table, SQL allows for ORDER BY clauses so the records get returned in an order more suited to the application’s needs. And the ordering can be an expression, not necessary a simple field. Try doing that in RMS.

But beyond that, SQL allows lookups using JOINs on multiple tables, plus of course subqueries -- try implementing that in RMS!

On 10/13/2021 7:23 PM, Arne Vajhøj wrote:
> On 10/13/2021 4:44 PM, Dave Froble wrote:
>> On 10/13/2021 12:42 PM, Jan-Erik Söderholm wrote:
>>> 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:
>>>>>> 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.
>
> Try add a column or update some values.

Yep! Every RDBMS I've seen, which isn't too many, is rather good at
that. Now, what does that have to do with "lot of application code"?

> With a relational database in is one SQL statement.
>
> With an index-sequential file it is writing a conversion program.

Not always. With DAS that utility already exists. And a bunch more
utilities, that work with any DAS file.

RMS isn't the only product around ...

>>>>> 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.
>>
>> Ad hoc inquiries I'll give you. RDBMS is great for that.
>>
>> But that wasn't in the discussion. Arne claimed that it took code to
>> use an RDBMS, and with some exceptions, that just isn't always so.
>
> I listed 4 different types of problems.
>
> For two of them the relational database would mean replacing an
> application with a one liner of SQL.
>
> For two of them the relational database would mean an application
> with less code, because the SQL replaces functionality in the code
> with simple constructs.
>
>> Yes, "SELECT * Where Name Like "Dave" is rather simple. But one must
>> still attach to the database. Request a Recordset. and so on.
>>
>> A simple loop processing an RMS file looking in each record in the
>> field Name for "Dave" can be an open and a couple lines of code.
>>
>> Not such a big difference.
>
> Why I called that case for "slightly less code".
>
> But then comes the more complex stuff.

One gets what one pays for. Yeah, an RDBMS can be a fine product. If I
were designing any new apps, I'd most likely choose to use an RDBMS.

I still feel that you're painting the gulf much wider than it actually is.

--
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 4:53 PM, Dave Froble wrote:
> On 10/13/2021 1:59 PM, Arne Vajhøj wrote:
>> On 10/13/2021 11:09 AM, Dave Froble wrote:
>>> 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.
>>
>> Here is an example of some (Python) code using SQL to
>> join, select, aggregate, sort and limit some data.
>>
>> import sqlite3
>>
>> con = sqlite3.connect('test.db')
>> c = con.cursor()
>> c.execute('''SELECT customers.name,SUM(orderlines.price) AS totalsales
>>              FROM customers
>>              LEFT JOIN orders ON customers.customer_id =
>> orders.customer_id
>>              LEFT JOIN orderlines ON orders.order_id =
>> orderlines.order_id
>>              WHERE orders.status = 'Delivered'
>>              GROUP BY customers.name
>>              HAVING totalsales > 10
>>              ORDER BY totalsales DESC
>>              LIMIT 3''')
>> for row in c.fetchall():
>>     print('%s : %d' % (row[0], row[1]))
>> con.commit()
>> con.close()
>>
>> I believe that it would take a lot more code to
>> retrieve data from index-sequential files and
>> do the work on the data.
>
> Not a lot, however the sorting by customer name would entail some
> additional code.
>
> However, reading the order file, doing the selection, look-up customer
> record, and release to record sort, then read back sorted records is not
> "a lot more" code.

I tried writing it in Pascal using index-sequential files.

program cmplx(input,output);

const
MAX_ORDERLINES_PER_ORDER = 100;

type
orderline = record
item : packed array [1..50] of char;
price : integer;
end;
customer = record
customer_id : [key(0)] integer;
name : packed array [1..50] of char;
address : packed array [1..100] of char;
end;
order = record
order_id : [key(0)] integer;
customer_id : [key(1)] integer;
ref : packed array [1..50] of char;
status : packed array [1..25] of char;
no_orderlines : integer;
orderlines : array [1..MAX_ORDERLINES_PER_ORDER] of
orderline;
end;

const
MAX_CUSTOMERS = 10000;

type
extcustomer = record
basis : customer;
total_sales : integer;
end;
extcustomerlist = array [1..MAX_CUSTOMERS] of extcustomer;

var
no_xc : integer;
xc_list : extcustomerlist;

procedure load_data;

var
fc : file of customer;
fo : file of order;
c : customer;
o : order;
i : integer;

begin
open(fc, 'customer.isq', old, organization := indexed, access_method
:= keyed);
open(fo, 'order.isq', old, organization := indexed, access_method :=
keyed);
resetk(fc, 0);
no_xc := 0;
while not eof(fc) do begin
c := fc^;
no_xc := no_xc + 1;
xc_list[no_xc].basis := c;
xc_list[no_xc].total_sales := 0;
resetk(fo, 1);
findk(fo, 1, c.customer_id);
while not(ufb(fo)) and not(eof(fo)) and (fo^.customer_id =
c.customer_id) do begin
o := fo^;
if o.status = 'Delivered' then begin
for i := 1 to o.no_orderlines do begin
xc_list[no_xc].total_sales := xc_list[no_xc].total_sales
+ o.orderlines[i].price;
end;
end;
get(fo); ;
end;
get(fc);
end;
close(fo);
close(fc);
end;

procedure sort_data;

var
i, j : integer;
tmp : extcustomer;

begin
for i := 1 to no_xc do begin
for j := (i + 1) to no_xc do begin
if xc_list[i].total_sales < xc_list[j].total_sales then begin
tmp := xc_list[i];
xc_list[i] := xc_list[j];
xc_list[j] := tmp;
end;
end;
end;
end;

procedure dump_data;

var
i : integer;

begin
for i := 1 to min(no_xc, 3) do begin
if xc_list[i].total_sales > 10 then begin
writeln(xc_list[i].basis.name,' ',xc_list[i].total_sales);
end;
end;
end;

begin
load_data;
sort_data;
dump_data;
end.

Arne

On 10/13/2021 8:31 PM, Arne Vajhøj wrote:
> On 10/13/2021 4:53 PM, Dave Froble wrote:
>> On 10/13/2021 1:59 PM, Arne Vajhøj wrote:
>>> On 10/13/2021 11:09 AM, Dave Froble wrote:
>>>> 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.
>>>
>>> Here is an example of some (Python) code using SQL to
>>> join, select, aggregate, sort and limit some data.
>>>
>>> import sqlite3
>>>
>>> con = sqlite3.connect('test.db')
>>> c = con.cursor()
>>> c.execute('''SELECT customers.name,SUM(orderlines.price) AS totalsales
>>> FROM customers
>>> LEFT JOIN orders ON customers.customer_id =
>>> orders.customer_id
>>> LEFT JOIN orderlines ON orders.order_id =
>>> orderlines.order_id
>>> WHERE orders.status = 'Delivered'
>>> GROUP BY customers.name
>>> HAVING totalsales > 10
>>> ORDER BY totalsales DESC
>>> LIMIT 3''')
>>> for row in c.fetchall():
>>> print('%s : %d' % (row[0], row[1]))
>>> con.commit()
>>> con.close()
>>>
>>> I believe that it would take a lot more code to
>>> retrieve data from index-sequential files and
>>> do the work on the data.
>>
>> Not a lot, however the sorting by customer name would entail some
>> additional code.
>>
>> However, reading the order file, doing the selection, look-up customer
>> record, and release to record sort, then read back sorted records is
>> not "a lot more" code.
>
> I tried writing it in Pascal using index-sequential files.
>
> program cmplx(input,output);
>
> const
> MAX_ORDERLINES_PER_ORDER = 100;
>
> type
> orderline = record
> item : packed array [1..50] of char;
> price : integer;
> end;
> customer = record
> customer_id : [key(0)] integer;
> name : packed array [1..50] of char;
> address : packed array [1..100] of char;
> end;
> order = record
> order_id : [key(0)] integer;
> customer_id : [key(1)] integer;
> ref : packed array [1..50] of char;
> status : packed array [1..25] of char;
> no_orderlines : integer;
> orderlines : array [1..MAX_ORDERLINES_PER_ORDER] of
> orderline;
> end;
>
> const
> MAX_CUSTOMERS = 10000;
>
> type
> extcustomer = record
> basis : customer;
> total_sales : integer;
> end;
> extcustomerlist = array [1..MAX_CUSTOMERS] of extcustomer;
>
> var
> no_xc : integer;
> xc_list : extcustomerlist;
>
> procedure load_data;
>
> var
> fc : file of customer;
> fo : file of order;
> c : customer;
> o : order;
> i : integer;
>
> begin
> open(fc, 'customer.isq', old, organization := indexed, access_method
> := keyed);
> open(fo, 'order.isq', old, organization := indexed, access_method :=
> keyed);
> resetk(fc, 0);
> no_xc := 0;
> while not eof(fc) do begin
> c := fc^;
> no_xc := no_xc + 1;
> xc_list[no_xc].basis := c;
> xc_list[no_xc].total_sales := 0;
> resetk(fo, 1);
> findk(fo, 1, c.customer_id);
> while not(ufb(fo)) and not(eof(fo)) and (fo^.customer_id =
> c.customer_id) do begin
> o := fo^;
> if o.status = 'Delivered' then begin
> for i := 1 to o.no_orderlines do begin
> xc_list[no_xc].total_sales := xc_list[no_xc].total_sales
> + o.orderlines[i].price;
> end;
> end;
> get(fo); ;
> end;
> get(fc);
> end;
> close(fo);
> close(fc);
> end;
>
> procedure sort_data;
>
> var
> i, j : integer;
> tmp : extcustomer;
>
> begin
> for i := 1 to no_xc do begin
> for j := (i + 1) to no_xc do begin
> if xc_list[i].total_sales < xc_list[j].total_sales then begin
> tmp := xc_list[i];
> xc_list[i] := xc_list[j];
> xc_list[j] := tmp;
> end;
> end;
> end;
> end;
>
> procedure dump_data;
>
> var
> i : integer;
>
> begin
> for i := 1 to min(no_xc, 3) do begin
> if xc_list[i].total_sales > 10 then begin
> writeln(xc_list[i].basis.name,' ',xc_list[i].total_sales);
> end;
> end;
> end;
>
> begin
> load_data;
> sort_data;
> dump_data;
> end.
>
> Arne
>
>

Gee, I'm sure glad I never tried Pascal.

Ok, the gauntlet has been thrown down. I accept. I will attempt to
better define the task, then implement it, in Basic, using my tools, and
my coding style. Give me a day or two.

Task definition

Select customers with shipped orders
Select orders with total dollars shipped >= 10
Sort by customer name, then by dollars, descending
Limit output to 3 orders per customer
print customer name and total dollars per order