Was getting way off topic, so new topic

Time to spam c.o.v

:-)

On 10/13/2021 10:54 PM, Dave Froble wrote:
> 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
>
> Is that it?
>

In article <a5642b04-7036-464d-80ed-35b335fc69dfn@googlegroups.com>,
=?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?= <lawrencedo99@gmail.com> writes:

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

365.25 would mean a leap year every 4 years. The length is closer to
365.2422. 365.2425 corresponds to missing 3 leap years every 400 years,
which is what is done: a year divisble by 100 is not a leap year unless
also visible by 400. That was the case in 2000. Had it not been, there
might have been more Y2K problems. :-|

So the current system is good for well over a human lifetime.

The leap seconds are added because the rotation rate of the Earth is
slowing down, not to compensate for the inexact leap-year system, which
is obviously off by much more than a second if it lets a day build up
over 4 years. The day was about 16 hours long earlier in the Earth's
history. Basically, the tides slow the Earth down. As a result, the
Moon recedes from the Earth. Thus, the fact that it appears the same
size as the Sun is not only a coincidence, but also one that holds now
but not in general.

One can actually measure the change in the rotation rate of the Earth
due to things like northern spring, when leaves appear on trees,
increasing the moment of inertia and slowing down the Earth (and the
opposite in northern autumn).

Den 2021-10-14 kl. 02:30, skrev Lawrence D’Oliveiro:
> 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!
>

Doesn't really matter what language you use EXEC SQL and END EXEC in,
the SQL within that block looks the same.

On 10/14/21 01:29, Lawrence D’Oliveiro wrote:

>
> There are no such things as “power grabs” in Free software. You are Free to choose,

Perhaps, but the amount of money and effort that Red Hat (now owned
by IBM btw) put into Linux means they have disproportionate amount of
influence in the direction of the project. They are not the only
ones, but once big business get involved, then commercial interests,
rather than pursuit of excellence, will will always take precedence.

> 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.
>
Well, you are free to choose. I can understand the initial motivation
for systemd, in terms of orderly system service and process startup,
just think the approach was wrong. With Solaris the layered svcs
and svcadm framework uses XML files, but the underlying
structure of /etc files remains the same, which provides far more
choice in management terms and is more help if there is a system
crash. I know this subject has been debated to death and good for
Debian to provide both, just don't want systemd anywhere near
systems here, as it violates so much in terms of partitioning and design
elegance. Could never respect such a crock of rubbish. Good
design is lightweight, whereas Linux is starting to sink under the
weight of it's own complexity.

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

All machines here are set to UTC, so the point is ?.

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

Well, do occasionally rebuild kernels, but an OS is here primarily to
enable productive work, not spend all day configuring or debugging it.

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

Not at all. Try reading the whole article, rather than cherry
picking :-). Had you done so, you would realise that the company
and individual concerned have been dropped from the project.

The fact that FreeBSD is embedded in so much commercial network kit,
also used by Apple OSX in the past, speaks volumes. Designed by
engineers, for engineers :-)...

Chris

On 10/14/21 01:46, Lawrence D’Oliveiro wrote:
> 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!

I come here to bury Caesar, not to praise him :-) ?. RMS is a Record
Management System, not a database, not the same thing at all. As a
foundation, or set of system services, yes, but not the complete
product.

Comparing Apples to Oranges is rarely productive...

Chris

On 10/14/2021 8:15 AM, chris wrote:
> On 10/14/21 01:46, Lawrence D’Oliveiro wrote:
>> 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!
>
> I come here to bury Caesar, not to praise him :-) ?. RMS is a Record
> Management System, not a database, not the same thing at all. As a
> foundation, or set of system services, yes, but not the complete
> product.
>
> Comparing Apples to Oranges is rarely productive...

Here we are not talking about RMS in general, but specifically
about index-sequential files.

VMS index-sequential files are per modern terminology a NoSQL
database of the Key Value Store type.

And the RMS services is the API to that.

Yes a relational database provide a lot
more functionality.

But that is sort of the point. If one can benefit from
any of these extra functionalities (and one does not have a
problem with the HW resource requirements for a relational
database which few will have today) then a relational database
saves writing code.

You pick a product that does more so you have to do less.

Arne

On 10/14/2021 1:43 AM, Dave Froble wrote:
> Was getting way off topic, so new topic
>
> Time to spam c.o.v
>
> :-)

Different people may have different opinions.

But I strongly believe that a nice piece of VMS Basic
code provide more value for c.o.v/I-V readers
and therefore are more on-topic than the
traditional ramblings "back in the early 1990's
DEC should have done this and that".

:-)

Arne

On 10/14/2021 4:34 AM, Jan-Erik Söderholm wrote:
> Den 2021-10-14 kl. 02:30, skrev Lawrence D’Oliveiro:
>> 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!
>
> Doesn't really matter what language you use EXEC SQL and END EXEC in,
> the SQL within that block looks the same.

Embedded SQL in language X and embedded SQL in language Y are
obviously very similar.

But embedded SQL is not the only way to access a
relational database.

3 common ways are:
- embedded SQL
- call API
- ORM

(ignoring Rdb's rather unique compilable modules)

And the availability and industry usage of those
vary by language.

Availability:

embedded SQL call API ORM
Cobol some databases rare no
C some databases most databases no
Java yes yes yes
C# no yes yes
PHP no yes yes
Python no yes yes

Usage:

embedded SQL call API ORM
Cobol lot none -
C some lot -
Java none some lot
C# - lot lot
PHP - lot some
Python - lot little

Note that embedded SQL is not so bad code wise.

My expectation will be that:

code(ORM) < code (embedded SQL) < code(call API)

Cobol is a verbose language whether using SQL or not.

Arne

On 10/13/2021 8:43 PM, Lawrence D’Oliveiro wrote:
> 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:
>>>> 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?

If the program sets symbols or define logicals in process
table then it makes a difference.

Arne

On 10/13/2021 10:54 PM, Dave Froble wrote:
> 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
>
> Is that it?

Close.

- aggregate sales by customer for only orderes delivered
- filter so only customers where total sales > 10
- sort sales descending and pick top 3

SQL decomposition/evolution:

-- basic data
SELECT customers.name,orderlines.price
FROM customers
LEFT JOIN orders ON customers.customer_id = orders.customer_id
LEFT JOIN orderlines ON orders.order_id = orderlines.order_id;
A company|10
A company|20
A company|30
A company|35
A company|40
A company|20
A company|25
A company|30
A company|10
A company|15
B company|5
B company|5
B company|10
B company|5
B company|10
B company|10
B company|10
B company|20
C company|20
C company|40
C company|80
C company|160
C company|320
D company|80
D company|160
E company|
-- add aggregation
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
GROUP BY customers.name;
A company|235
B company|75
C company|620
D company|240
E company|
-- add condition to only consider delivered orders
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;
A company|135
B company|75
C company|620
D company|240
-- add condition to only show rows with more than 10 in total sales
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;
A company|135
B company|75
C company|620
D company|240
-- add sort descending by total sales
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;
C company|620
D company|240
A company|135
B company|75
-- add limit to 3 output rows
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;
C company|620
D company|240
A company|135

Arne

On 10/13/2021 10:54 PM, Dave Froble wrote:
> 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:
>>>> Here is an example of some (Python) code using SQL to
>>>> join, select, aggregate, sort and limit some data.

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

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

I like Pascal. I know Pascal reasonable well. And Pascal
got good support for index-sequential files (not like C
where one would need to use direct RMS calls).

I don't think there is that big potential
improvements.

Record definitions are a must.

Opening and closing index-sequential files is a must.

Iteration over customers and nested iteration over orders is not
a must. But I think iterating over orders and updating an
in-memory customer list will be more code.

If statements for conditions are a must,

2 loops + 1 if + 3 assignments for sorting can not be done
easier unless there is a builtin sort function.

I chose to map the 3 tables to 2 index-sequential files
because I cnsider it realistic to have order and all orderlines
in a 32K record but unrealistic to have a customer and all orders
in a 32K record.

Arne

On 2021-10-13 23:57:00 +0000, John Dallman said:

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

IDSM.

LOGINOUT activates DCL into P0 space to size it, then performs a
rundown, allocates the necessary address space in P1 for DCL and for
its tables, and activates (merges) DCL again.

Other CLIs are activated (merged) directly into P1.

The debugger doesn't know from P1 supervisor code, which leaves you
with delta, with your own debugging code, breadcrumb debugging, maybe
the tr_print ring buffers, etc.

#include <vms_macros.h>
…
tr_print(( “hello, world %d”, i ));

There are a few examples of CLIs in older DECUS and probably in
Freeware open-source listings, not that they're at all common.
DEC/shell was one of the few products offered.

In L4 or other such operating system designs, I'd tend to assume any
CLI will either be chained activations with the images, or will be
operating in a separate process.

This if the hardware lacks a ring for the CLI, or if the OS isn't
inclined to create a ring for the CLI as VSI is doing with the x86-64
port.

--
Pure Personal Opinion | HoffmanLabs LLC

On 10/14/2021 11:27 AM, Arne Vajhøj wrote:
> On 10/13/2021 10:54 PM, Dave Froble wrote:
>> 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:
>>>>> Here is an example of some (Python) code using SQL to
>>>>> join, select, aggregate, sort and limit some data.
>
>>>>> 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.
>
>> Gee, I'm sure glad I never tried Pascal.
>
> I like Pascal. I know Pascal reasonable well. And Pascal
> got good support for index-sequential files (not like C
> where one would need to use direct RMS calls).
>
> I don't think there is that big potential
> improvements.
>
> Record definitions are a must.
>
> Opening and closing index-sequential files is a must.
>
> Iteration over customers and nested iteration over orders is not
> a must. But I think iterating over orders and updating an
> in-memory customer list will be more code.
>
> If statements for conditions are a must,
>
> 2 loops + 1 if + 3 assignments for sorting can not be done
> easier unless there is a builtin sort function.
>
> I chose to map the 3 tables to 2 index-sequential files
> because I cnsider it realistic to have order and all orderlines
> in a 32K record but unrealistic to have a customer and all orders
> in a 32K record.
>
> Arne

I give up. I got grass to mow before the dead of winter is upon me.

--
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-14 00:36:58 +0000, Lawrence D’Oliveiro said:

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

At this point in the VSI port to x86-64, your suggestion to re-host to
Linux is worse.

Short version:

the OpenVMS x86-64 kernel is already available.

Longer version; why re-hosting to the Linux kernel is worse:

Going to the effort of swapping a ~forty year old monolithic kernel for
a ~thirty year old monolithic kernel while preparing for next-decade
system hardware architecture designs seems... unwise.

The this-decade hardware architecture details are already here, or are
arriving soonest.

Unwise particularly given a working OpenVMS x86-64 kernel is available.
Getting LLVM working native is one of the larger parts of the
remaining OpenVMS release schedule, too. Which isn't a kernel issue,
and won't benefit from re-hosting the kernel.

Unwise given the IP lawyers necessarily get involved with discussions
re-using a GPL kernel and/or re-using drivers for a closed-source
product and particularly where the vendor reportedly has no rights to
release much of the closed source.

As for the portability of BSD kernel designs, the major platforms
already support all of the processor architectures that people running
servers are interested in now, as well as Arm and RISC-V:
https://www.freebsd.org/platforms/
https://www.netbsd.org/ports/
https://www.openbsd.org/plat.html

The BSD licenses also tend to lack the GPL-related compliance issues
that can arise for closed-source vendors.

For folks that do want OpenVMS-flavored APIs on Linux, that's already
available from Sector7. That product specifically targets migrating to
platform-native APIs, as well.

For folks that want access to Linux, BSD, Windows Server, or otherwise
on x86-64 and with OpenVMS on x86-64, hypervisor guests are already an
option.

(It'd be interesting to see if a hypervisor could add Galaxy-like
communications features, as the hypervisor and what SRM provided Galaxy
aren't all that different, but that's fodder for another thread.)

Would re-hosting the existing kernel to a more modern kernel be
interesting? Sure. Maybe. Eventually. But not prior to V10.0, given the
available kernel. And not onto the current Linux kernel.

Entirely FWIW and for those interested in "newer" or "different"
operating system kernel designs from the ~recent past—and to be
absolutely clear, OpenVMS will ~never see these used—there's the
~thirty year old Grasshopper design, and the always-weird Singularity
design, and the VMS-friendly DEC MICA design:
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.855.3247&rep=rep1&type=pdf

https://www.microsoft.com/en-us/research/project/singularity/
https://en.wikipedia.org/wiki/DEC_PRISM#MICA

--
Pure Personal Opinion | HoffmanLabs LLC

On 2021-10-13, Dave Froble <davef@tsoft-inc.com> wrote:
> On 10/13/2021 7:23 PM, Arne Vajhøj wrote:
>> 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 ...
>

Can that utility be used while existing programs which don't need the
new field continue to run at the same time as you are adding the new
field ?

If yes, is this still true if you are not allocating the new field
out of existing dead space in the record and need to extend the
underlying record to hold the new field ?

IOW, is there any application downtime while you are adding the new
field in DAS ?

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-14, Dave Froble <davef@tsoft-inc.com> wrote:
> Was getting way off topic, so new topic
>
> Time to spam c.o.v
>
>:-)
>

Having compared the two programs, I find the Pascal version to be
a lot more readable and easier to follow than the Basic version,
although Arne does put his begin statements in a strange place... :-)

The Basic version has much more jumping around and just doesn't read
as well as the Pascal version does.

BTW, Basic really does like spewing its special characters onto the
end of variable references. :-)

One thing I was surprised by was the goto and gosub to integer line
numbers instead of looping constructs and named function calls with
parameters as you see in the Pascal example and in other languages
such as C and Ada.

Is that style normal in DEC Basic code ?

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-14, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>
> In L4 or other such operating system designs, I'd tend to assume any
> CLI will either be chained activations with the images, or will be
> operating in a separate process.
>

I wonder what sys$cli() would look like internally in that case ?

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

Wasn't that due to the applications running on top of Minix instead of
Minix itself ?

For the record, I think the IME (and similar devices) are not a good
thing to have in hardware unless you can _guarantee_ they can be disabled
in all cases.

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

Ever heard of seL4 ?

The massive advantage of microkernels is that code which would otherwise
be in a shared fully privileged kernel address space is in fact isolated
in its own address space with far fewer access rights to other parts of
the system.

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

Unlike the Unix shells you are clearly thinking of, DCL provides services
to a program directly while the program is running.

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

_Normally_, there isn't. :-)

The point of my comments is that DCL needs to operate in a more
privileged environment than is available to user-mode code.

In the current design, you can't fold user-mode code into DCL's
supervisor mode or move DCL into user mode without having a total
breakdown in system security, hence you need an extra mode other
than the normal KU modes to run DCL in.

Simon.

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

On 10/14/2021 2:06 PM, Simon Clubley wrote:
> On 2021-10-14, Dave Froble <davef@tsoft-inc.com> wrote:
>> Was getting way off topic, so new topic
>>
>> Time to spam c.o.v
>
> Having compared the two programs, I find the Pascal version to be
> a lot more readable and easier to follow than the Basic version,
> although Arne does put his begin statements in a strange place... :-)

No no. The right place.

:-)

> The Basic version has much more jumping around and just doesn't read
> as well as the Pascal version does.
>
> BTW, Basic really does like spewing its special characters onto the
> end of variable references. :-)

Those suffixes are not requires so if one is programming in Pascal
in Basic, then one does not need them.

What one has to do if one is programming in Basic in Basic I better
let Dave answer.

> One thing I was surprised by was the goto and gosub to integer line
> numbers instead of looping constructs and named function calls with
> parameters as you see in the Pascal example and in other languages
> such as C and Ada.
>
> Is that style normal in DEC Basic code ?

Arne

On 2021-10-14 18:09:10 +0000, Simon Clubley said:

> On 2021-10-14, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>>
>> In L4 or other such operating system designs, I'd tend to assume any
>> CLI will either be chained activations with the images, or will be
>> operating in a separate process.
>>
>
> I wonder what sys$cli() would look like internally in that case ?

A round-trip through the inter-process message-passing layer, or maybe
directly via a shared (possibly read-only) memory section, or a
combination, most likely.

http://sigops.org/s/conferences/sosp/2013/papers/p133-elphinstone.pdf

Same as a local OO call dispatches through an intra-process
message-passing layer.

https://www.mikeash.com/pyblog/friday-qa-2017-06-30-dissecting-objc_msgsend-on-arm64.html

Processors with myriad cores allows myriad processes/threads active in
parallel.

Processors increasingly with big.LITTLE designs, and with a mix of
app-focused cores, and purpose-designed cores for ML, GPU, or other
tasks, too.

If I'm going to do ~ten years' work re-hosting a kernel, and GPL/IP and
other discussions aside, I probably don't want to end up with the Linux
kernel of today (or a fork of same) underneath. (And that's not
intended to slag on or as a dig against Linux!)

--
Pure Personal Opinion | HoffmanLabs LLC

On 10/14/21 5:55 PM, Stephen Hoffman wrote:
> LOGINOUT activates DCL into P0 space to size it, then performs a
> rundown, allocates the necessary address space in P1 for DCL and for its
> tables, and activates (merges) DCL again.

Dunno when P0 space sizing was used, nowadays DCL is directly merge
activated into P1.

On 10/14/2021 1:48 PM, Simon Clubley wrote:
> On 2021-10-13, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 10/13/2021 7:23 PM, Arne Vajhøj wrote:
>>> 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 ...
>>
>
> Can that utility be used while existing programs which don't need the
> new field continue to run at the same time as you are adding the new
> field ?
>
> If yes, is this still true if you are not allocating the new field
> out of existing dead space in the record and need to extend the
> underlying record to hold the new field ?
>
> IOW, is there any application downtime while you are adding the new
> field in DAS ?
>
> Simon.
>

In a word, yes.

Now, tell me that a database doesn't defer some transactions if it is re-defining a table definition.

In the era that DAS and a whole bunch of software comes from, downtime for maintenance, backups, and such was normal.

Today's software benefits from new capabilities, new requirements, and such. That is a good thing.

But consider where the new capabilities came from. Perhaps learning things while using older software?

Arne figured a new conversion program would be required. Not with a product that anticipated
such conversions, and provided methods to perform them. Does DAS have limitations? Damn right it does,
and I seem to recall writing multiple times that if I was designing an application today, I'd most likely
choose a modern RDBMS. However, I sometimes get the impression, perhaps mistakenly, that some might feel
that every year everything should be re-implemented using new technology, throwing out all the old stuff.
That sort of irritates me. After all, it was the old stuff that got us to where we are today, including
the lessons that caused the development of newer methods.

--
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/14/2021 2:06 PM, Simon Clubley wrote:
> On 2021-10-14, Dave Froble <davef@tsoft-inc.com> wrote:
>> Was getting way off topic, so new topic
>>
>> Time to spam c.o.v
>>
>> :-)
>>
>
> Having compared the two programs, I find the Pascal version to be
> a lot more readable and easier to follow than the Basic version,
> although Arne does put his begin statements in a strange place... :-)

Yeah, Arne's code had lots of comments to explain things. Not!

I'd really be interested in what parts of the Basic code was so bad?

I do realize that since you are not familiar with DAS and it's implementation,
and my library routines, which would not be understood. That's normal.

> The Basic version has much more jumping around and just doesn't read
> as well as the Pascal version does.

I really resent that claim. With a few exceptions, mainline code is pretty
much straight through, and for someone who seems to like scripting languages
with all their library routines, placing specific in subroutines should
seem rather natural.

I'm a really big fan of modular code.

My IDE is a big fan of things having a place, and things being in their place.
Much of what you call jumping around is actually the IDE pulling in pieces of
code to perform specific functions. I'm guessing if I had pulled in the forms
control stuff, which is used for paging in reports, you'd be even more confused.
But it works great, and doesn't have to be re-written for every program. Such
also avoids coding errors.

> BTW, Basic really does like spewing its special characters onto the
> end of variable references. :-)

And other languages don't have such quirks?

> One thing I was surprised by was the goto and gosub to integer line
> numbers instead of looping constructs and named function calls with
> parameters as you see in the Pascal example and in other languages
> such as C and Ada.

I've seen people attempt to jump through many difficult hoops to attempt to follow
some coding standard. Doesn't make any sense to me. There are perfectly logical
uses for both GoSub and GoTo. Such as just throwing out the anchor if fatal errors
occur. Moving special functionality out of the mainline code makes it more readable,
for me.

Did I mention I don't like C, and most likely would not like Ada?

Got to ask, just what do you think a NEXT, WHILE_END, and such statements do?
Sure looks like another form of GoTo to me.

> Is that style normal in DEC Basic code ?

No, it is not. I've seen people attempt to force their coding standards
in many languages, including Basic. It is a people thing.

Personally, I think my example was rather easy to read, and straight forward. Any
issue with subroutines is most likely due to having to read them elsewhere,
something that was much easier with paper listings. But, much of that was again,
because of the IDE pulling in pre-written code. I know what they do, you don't,
so our perceptions will obviously be 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/14/2021 2:36 PM, Arne Vajhøj wrote:
> On 10/14/2021 2:06 PM, Simon Clubley wrote:
>> On 2021-10-14, Dave Froble <davef@tsoft-inc.com> wrote:
>>> Was getting way off topic, so new topic
>>>
>>> Time to spam c.o.v
>>
>> Having compared the two programs, I find the Pascal version to be
>> a lot more readable and easier to follow than the Basic version,
>> although Arne does put his begin statements in a strange place... :-)
>
> No no. The right place.
>
> :-)
>
>> The Basic version has much more jumping around and just doesn't read
>> as well as the Pascal version does.
>>
>> BTW, Basic really does like spewing its special characters onto the
>> end of variable references. :-)
>
> Those suffixes are not requires so if one is programming in Pascal
> in Basic, then one does not need them.

Basic can be very happy to let the programmer specify that all variables
must be declared. Then variable names can be whatever they are declared
to be. Frankly, I see no decent reason to do all that typing when the
compiler can do a much better job than any programmer. One just needs to
give it some hints. I learned the variable suffex stuff long ago, and
it's just natural to me. Just as conventions in another language might
be natural to someone used to that language. Things like "!" instead of "#"
to denote comments.

--
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/14/2021 3:12 PM, Dave Froble wrote:
> On 10/14/2021 1:48 PM, Simon Clubley wrote:
>> On 2021-10-13, Dave Froble <davef@tsoft-inc.com> wrote:
>>> On 10/13/2021 7:23 PM, Arne Vajhøj wrote:
>>>> 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 ...
>>
>> Can that utility be used while existing programs which don't need the
>> new field continue to run at the same time as you are adding the new
>> field ?
>>
>> If yes, is this still true if you are not allocating the new field
>> out of existing dead space in the record and need to extend the
>> underlying record to hold the new field ?
>>
>> IOW, is there any application downtime while you are adding the new
>> field in DAS ?
>
> In a word, yes.
>
> Now, tell me that a database doesn't defer some transactions if it is
> re-defining a table definition.

I would expect an update to be waiting while conflicting updates
complete for both DML updates (data updates) and DDL updates (structure
updates) even though I think it is rare to do structure updates on
running system, because often a database structure changes require a
matching application update (not to make it continue to work, but to
activate some new feature supported by the new database structure).

> In the era that DAS and a whole bunch of software comes from, downtime
> for maintenance, backups, and such was normal.
>
> Today's software benefits from new capabilities, new requirements, and
> such.  That is a good thing.
>
> But consider where the new capabilities came from.  Perhaps learning
> things while using older software?
>
> Arne figured a new conversion program would be required.  Not with a
> product that anticipated
> such conversions, and provided methods to perform them.  Does DAS have
> limitations?  Damn right it does,
> and I seem to recall writing multiple times that if I was designing an
> application today, I'd most likely
> choose a modern RDBMS.

RDBMS sure got some advantages.

Lots of functionality.

A few dozens of products to chose from - from bloody expensive to free.

Standard interface language SQL known by maybe 15 million developers
worldwide.

That makes a pretty good case.

But not necessarily for all cases.

A product like RocksDB was created just 9 years ago. And it
illustrates that there are cases where a RDBMS is not the best choice.

>   However, I sometimes get the impression, perhaps
> mistakenly, that some might feel
> that every year everything should be re-implemented using new
> technology, throwing out all the old stuff.
> That sort of irritates me.  After all, it was the old stuff that got us
> to where we are today, including
> the lessons that caused the development of newer methods.

Definitely not every year.

Major conversions are very expensive.

And there is a reason that "leading edge" is sometimes
spelled "bleeding edge".

And sometimes new technologies that looked promising turns
into a dead end.

But maybe a big technology lift every 10 years.

Arne