On Tuesday, June 21, 2022 at 12:08:21 AM UTC-4, Dave Froble wrote:
> Way, way, back, it was determined that due to the lack of adequate channels in
> Basic+, 12 to be precise, it would be advisable to have a single file that could
> be used for different types of data. Things with just a few records, such as
> maybe 20 terms codes, 50 state codes, and others. We even called it a "codes
> file".

That's the kind of thing SQLite is great at when used as what they call an
application file format. MacOS uses it for several of their applications now,
though they build the library without load extension capability.

On 2022-06-22, Richard Maher <maher_rjSPAMLESS@hotmail.com> wrote:
>
> Don't get me going on LDAP and JWTs :-(
>
> Authentication *IS NOT* authorization people!

Unfortunately way too many people think they are the same thing.

For example, Stephen lives in a country where an identifier (a SSN)
is used as an authoriser/password in way too many places. Utterly insane. :-(

Simon.

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

On 6/23/2022 10:14 AM, David Jones wrote:
> On Tuesday, June 21, 2022 at 12:08:21 AM UTC-4, Dave Froble wrote:
>> Way, way, back, it was determined that due to the lack of adequate channels in
>> Basic+, 12 to be precise, it would be advisable to have a single file that could
>> be used for different types of data. Things with just a few records, such as
>> maybe 20 terms codes, 50 state codes, and others. We even called it a "codes
>> file".
>
> That's the kind of thing SQLite is great at when used as what they call an
> application file format. MacOS uses it for several of their applications now,
> though they build the library without load extension capability.
>

Yes, today, and that's what I'd be looking at today. But we're talking about
something from 48 years ago, which still does the job today. Lots of better
options today. Might even be more tomorrow. But it's not broke, so why fix it?

Actually, not only is it not broke, it has utilities for ease of use. For a
"more modern" (I hated typing that) implementation perhaps the utilities for
ease of use might still be required to be developed.

--
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 2022-06-23 13:43:18 +0000, David Jones said:

> On Wednesday, June 22, 2022 at 11:59:22 AM UTC-4, Stephen Hoffman wrote:
>> As for your process creation... The PQL stuff is one of those areas
>> where the argument is optional, where the defaults are fickle, and
>> where the PQL list really shouldn't be optional.
>
> If they go to fix that, they should also drop the 63 character limit on
> the image name argument.

OpenVMS supports this feature via the SET FILE/ALIAS command.

I'm sure the SET FILE /ALIAS=GENERATE=UUID {ODS-5 path} command can be added.

Then you can enter the generated UUID into the image file path argument.

We can undoubtedly work logical names into this, but you'll have to
re-enter the logical name at boot.

🙄

--
Pure Personal Opinion | HoffmanLabs LLC

On 2022-06-24, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
> On 2022-06-23 13:43:18 +0000, David Jones said:
>
>> On Wednesday, June 22, 2022 at 11:59:22 AM UTC-4, Stephen Hoffman wrote:
>>> As for your process creation... The PQL stuff is one of those areas
>>> where the argument is optional, where the defaults are fickle, and
>>> where the PQL list really shouldn't be optional.
>>
>> If they go to fix that, they should also drop the 63 character limit on
>> the image name argument.
>
> OpenVMS supports this feature via the SET FILE/ALIAS command.
>
> I'm sure the SET FILE /ALIAS=GENERATE=UUID {ODS-5 path} command can be added.
>
> Then you can enter the generated UUID into the image file path argument.
>
> We can undoubtedly work logical names into this, but you'll have to
> re-enter the logical name at boot.
>

What we _really_ need are logical names whose name (not contents)
can be specified as a UTF-8 character sequence... :-)

Simon.

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

On 6/27/2022 1:18 PM, Simon Clubley wrote:
> On 2022-06-24, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>> On 2022-06-23 13:43:18 +0000, David Jones said:
>>
>>> On Wednesday, June 22, 2022 at 11:59:22 AM UTC-4, Stephen Hoffman wrote:
>>>> As for your process creation... The PQL stuff is one of those areas
>>>> where the argument is optional, where the defaults are fickle, and
>>>> where the PQL list really shouldn't be optional.
>>>
>>> If they go to fix that, they should also drop the 63 character limit on
>>> the image name argument.
>>
>> OpenVMS supports this feature via the SET FILE/ALIAS command.
>>
>> I'm sure the SET FILE /ALIAS=GENERATE=UUID {ODS-5 path} command can be added.
>>
>> Then you can enter the generated UUID into the image file path argument.
>>
>> We can undoubtedly work logical names into this, but you'll have to
>> re-enter the logical name at boot.
>>
>
> What we _really_ need are logical names whose name (not contents)
> can be specified as a UTF-8 character sequence... :-)
>
> Simon.
>

Enlighten me. I cannot think of one reason why ...

--
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 2022-06-27, Dave Froble <davef@tsoft-inc.com> wrote:
> On 6/27/2022 1:18 PM, Simon Clubley wrote:
>> On 2022-06-24, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>>>
>>> OpenVMS supports this feature via the SET FILE/ALIAS command.
>>>
>>> I'm sure the SET FILE /ALIAS=GENERATE=UUID {ODS-5 path} command can be added.
>>>
>>> Then you can enter the generated UUID into the image file path argument.
>>>
>>> We can undoubtedly work logical names into this, but you'll have to
>>> re-enter the logical name at boot.
>>>
>>
>> What we _really_ need are logical names whose name (not contents)
>> can be specified as a UTF-8 character sequence... :-)
>>
>
> Enlighten me. I cannot think of one reason why ...
>

You Americans really don't do subtle humour do you ? :-)

Simon.

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

On 6/27/2022 2:30 PM, Simon Clubley wrote:
> On 2022-06-27, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 6/27/2022 1:18 PM, Simon Clubley wrote:
>>> On 2022-06-24, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>>>>
>>>> OpenVMS supports this feature via the SET FILE/ALIAS command.
>>>>
>>>> I'm sure the SET FILE /ALIAS=GENERATE=UUID {ODS-5 path} command can be added.
>>>>
>>>> Then you can enter the generated UUID into the image file path argument.
>>>>
>>>> We can undoubtedly work logical names into this, but you'll have to
>>>> re-enter the logical name at boot.
>>>>
>>>
>>> What we _really_ need are logical names whose name (not contents)
>>> can be specified as a UTF-8 character sequence... :-)
>>>
>>
>> Enlighten me. I cannot think of one reason why ...
>>
>
> You Americans really don't do subtle humour do you ? :-)
>
> Simon.
>

Sometimes ...

--
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 Mon, 2022-06-27 at 17:18 +0000, Simon Clubley wrote:
> On 2022-06-24, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
> > On 2022-06-23 13:43:18 +0000, David Jones said:
> >
> > > On Wednesday, June 22, 2022 at 11:59:22 AM UTC-4, Stephen Hoffman
> > > wrote:
> > > > As for your process creation... The PQL stuff is one of those
> > > > areas
> > > > where the argument is optional, where the defaults are fickle,
> > > > and
> > > > where the PQL list really shouldn't be optional.
> > >
> > > If they go to fix that, they should also drop the 63 character
> > > limit on
> > > the image name argument.
> >
> > OpenVMS supports this feature via the SET FILE/ALIAS command.
> >
> > I'm sure the SET FILE /ALIAS=GENERATE=UUID {ODS-5 path} command can
> > be added.
> >
> > Then you can enter the generated UUID into the image file path
> > argument.
> >
> > We can undoubtedly work logical names into this, but you'll have to
> > re-enter the logical name at boot.
> >
>
> What we _really_ need are logical names whose name (not contents)
> can be specified as a UTF-8 character sequence... :-)

Ooh, what jolly japes we can play with emojis ...
--
Tactical Nuclear Kittens

On 2022-06-27 17:18:55 +0000, Simon Clubley said:

> What we _really_ need are logical names whose name (not contents) can
> be specified as a UTF-8 character sequence... :-)

DEFINE "🫣" "🤬"

DCL U+FEFF: 😱

--
Pure Personal Opinion | HoffmanLabs LLC

On 2022-06-27 18:25:14 +0000, Dave Froble said:

> On 6/27/2022 1:18 PM, Simon Clubley wrote:
>>
>> What we _really_ need are logical names whose name (not contents) can
>> be specified as a UTF-8 character sequence... :-)
>
> Enlighten me. I cannot think of one reason why ...

That was intended a joke, of course.

There is, however, much more to the computing world than what can be
represented in DEC MCS and ISO Latin 1.

OpenVMS RMS has support for UTF-8, not that much else does.

Reference those RMS files through encoding hackery is certainly
possible, of course.

Dealing with UTF-8 is something an increasing number of apps have to deal with.

Websites and web servers have been UTF-8 for a number of years.

On OpenVMS, most apps ignore UTF-8, and require / assume / force
arriving data to ASCII.

Unfortunately, that can be names and addresses and other data that
doesn't map to ASCII.

Dates too are "fun", but I'll leave that "fun" for another, um, day.

Sure, we can all continue to use ASCII and DEC MCS, and can ignore the
whole character encoding issue.

And can map "unsupported" string encodings using UUID-generated names
(aliases), as my earlier joke had alluded.

Which is about the best option on OpenVMS, if porting is not a possibility.

If you're US based and not working outside of Romance languages, this
is less of an issue.

Though I'd consider testing customer-facing data interfaces with UTF-8.

This whole thing becomes a non-issue* in environments where UTF-8 is native.

*Mostly. UTF-8 still has some surprises waiting, including the byte
order mark, language-specific sort orders, and non-breaking spaces.

Getting to fully native UTF-8 support in the OpenVMS operating system,
tools, and platforms, is unlikely on any reasonable VSI OpenVMS
timeline.

--
Pure Personal Opinion | HoffmanLabs LLC

On 6/27/2022 6:51 PM, Stephen Hoffman wrote:
> There is, however, much more to the computing world than what can be
> represented in DEC MCS and ISO Latin 1.
>
> OpenVMS RMS has support for UTF-8, not that much else does.
>
> Reference those RMS files through encoding hackery is certainly
> possible, of course.
>
> Dealing with UTF-8 is something an increasing number of apps have to
> deal with.
>
> Websites and web servers have been UTF-8 for a number of years.
>
> On OpenVMS, most apps ignore UTF-8, and require / assume / force
> arriving data to ASCII.
>
> Unfortunately, that can be names and addresses and other data that
> doesn't map to ASCII.
>
> Dates too are "fun", but I'll leave that "fun" for another, um, day.
>
> Sure, we can all continue to use ASCII and DEC MCS, and can ignore the
> whole character encoding issue.
>
> And can map "unsupported" string encodings using UUID-generated names
> (aliases), as my earlier joke had alluded.
>
> Which is about the best option on OpenVMS, if porting is not a possibility.
>
> If you're US based and not working outside of Romance languages, this is
> less of an issue.
>
> Though I'd consider testing customer-facing data interfaces with UTF-8.
>
> This whole thing becomes a non-issue* in environments where UTF-8 is
> native.
>
> *Mostly. UTF-8 still has some surprises waiting, including the byte
> order mark, language-specific sort orders, and non-breaking spaces.
>
> Getting to fully native UTF-8 support in the OpenVMS operating system,
> tools, and platforms, is unlikely on any reasonable VSI OpenVMS timeline.

There are two models for Unicode support.

A) UTF-8 internal and UTF-8 external

That one is not so difficult to implement.

Most existing libraries work.

For anything ASCII everything works exactly as before.

One need some string function to operate on character index
instead of byte index.

But not so difficult.

Problem is that a lot of string functionality becomes expensive
because all use of character indexes become iterations.

B) UTF-16 internal and UTF-8 external

That one requires a lot of work.

Library support.

Application changes.

But it is efficient.

Which is why C/C++, Java and .NET all chose that path.

Arne

On 6/27/22 9:00 PM, Arne Vajhøj wrote:
> On 6/27/2022 6:51 PM, Stephen Hoffman wrote:
>> There is, however, much more to the computing world than what can be
>> represented in DEC MCS and ISO Latin 1.
>>
>> OpenVMS RMS has support for UTF-8, not that much else does.
>>
>> Reference those RMS files through encoding hackery is certainly
>> possible, of course.
>>
>> Dealing with UTF-8 is something an increasing number of apps have to
>> deal with.
>>
>> Websites and web servers have been UTF-8 for a number of years.
>>
>> On OpenVMS, most apps ignore UTF-8, and require / assume / force
>> arriving data to ASCII.
>>
>> Unfortunately, that can be names and addresses and other data that
>> doesn't map to ASCII.
>>
>> Dates too are "fun", but I'll leave that "fun" for another, um, day.
>>
>> Sure, we can all continue to use ASCII and DEC MCS, and can ignore the
>> whole character encoding issue.
>>
>> And can map "unsupported" string encodings using UUID-generated names
>> (aliases), as my earlier joke had alluded.
>>
>> Which is about the best option on OpenVMS, if porting is not a
>> possibility.
>>
>> If you're US based and not working outside of Romance languages, this
>> is less of an issue.
>>
>> Though I'd consider testing customer-facing data interfaces with UTF-8.
>>
>> This whole thing becomes a non-issue* in environments where UTF-8 is
>> native.
>>
>> *Mostly. UTF-8 still has some surprises waiting, including the byte
>> order mark, language-specific sort orders, and non-breaking spaces.
>>
>> Getting to fully native UTF-8 support in the OpenVMS operating system,
>> tools, and platforms, is unlikely on any reasonable VSI OpenVMS timeline.
>
> There are two models for Unicode support.
>
> A) UTF-8 internal and UTF-8 external
>
> That one is not so difficult to implement.
>
> Most existing libraries work.
>
> For anything ASCII everything works exactly as before.
>
> One need some string function to operate on character index
> instead of byte index.
>
> But not so difficult.
>
> Problem is that a lot of string functionality becomes expensive
> because all use of character indexes become iterations.
>
> B) UTF-16 internal and UTF-8 external
>
> That one requires a lot of work.
>
> Library support.
>
> Application changes.
>
> But it is efficient.
>
> Which is why C/C++, Java and .NET all chose that path.

I think they made those choices when UCS-2 was current and everyone
thought a wider fixed-width encoding would be enough. UTF-16 needs all
of the same varying-width handling that UTF-8 does but uses twice as
much memory for the most common characters.

> What we _really_ need are logical names whose name (not contents)
> can be specified as a UTF-8 character sequence... :-)

Obviously. How else will you be able to translate the file formerly
known as Prince?

De

On 6/27/2022 10:46 PM, Craig A. Berry wrote:
> On 6/27/22 9:00 PM, Arne Vajhøj wrote:
>> There are two models for Unicode support.
>>
>> A) UTF-8 internal and UTF-8 external
>>
>> That one is not so difficult to implement.
>>
>> Most existing libraries work.
>>
>> For anything ASCII everything works exactly as before.
>>
>> One need some string function to operate on character index
>> instead of byte index.
>>
>> But not so difficult.
>>
>> Problem is that a lot of string functionality becomes expensive
>> because all use of character indexes become iterations.
>>
>> B) UTF-16 internal and UTF-8 external
>>
>> That one requires a lot of work.
>>
>> Library support.
>>
>> Application changes.
>>
>> But it is efficient.
>>
>> Which is why C/C++, Java and .NET all chose that path.
>
> I think they made those choices when UCS-2 was current and everyone
> thought a wider fixed-width encoding would be enough.

Yes.

>   UTF-16 needs all
> of the same varying-width handling that UTF-8

In theory yes.

In practice it is common for applications only to support BMP.

> does but uses twice as
> much memory for the most common characters.

Most don't care.

Arne

On Monday, June 20, 2022 at 11:08:21 PM UTC-5, Dave Froble wrote:
>
> The concept worked well, to the point all applications used it. Every program
> got it's filenames from the codes file using keys/tokens/whatever you want to
> call them for one example. The entire TOLAS and other ERP type applications
> were built around the concept.
>
> From an old customer site, no longer in use:
>
> ---Code type---------Code description------
>
> CODES Codes Descriptors
> BANK_CODE Bank code records
> CHARGES Charge code records
> COLLECTOR Credit analyst codes
> COLLECT_LETTER Collection letter codes
> COLLECT_TXNS Collection transaction codes
> COMPANY_NAME Company name records
> CTL_DATES Date range control records
> CTY_TAX Taxing location rate records
> CUST_TYPE Customer type codes
> DAS14 DAS14 data file list(s)
> DETACH Detached process parameter records
> FILENAMES Data file names and locations

Wow! It's 2022 and Dave is still talking TOLAS. <Grin>
IBM thinks they are going to be able to pull that out of Navistar no problem at all. I've lost track of how many replacement efforts there have been over the decades.

On Thursday, June 23, 2022 at 9:14:07 AM UTC-5, osuv...@gmail.com wrote:
> On Tuesday, June 21, 2022 at 12:08:21 AM UTC-4, Dave Froble wrote:
> > Way, way, back, it was determined that due to the lack of adequate channels in
> > Basic+, 12 to be precise, it would be advisable to have a single file that could
> > be used for different types of data. Things with just a few records, such as
> > maybe 20 terms codes, 50 state codes, and others. We even called it a "codes
> > file".
> That's the kind of thing SQLite is great at when used as what they call an
> application file format. MacOS uses it for several of their applications now,
> though they build the library without load extension capability.

No man. You need to find a copy of this book

https://www.theminimumyouneedtoknow.com/app_book.html

and read the section on multi-typed records. SQL of no flavor can do what we did back then. What I put in the book was the best I could remember from LIOCS Perspective software. There were quite a few other DEC VARS that took the same approach to the point of using the same record types. I "think" they all stole the same Singer BASIC code.

Been over a decade or more since I looked at the TOLAS stuff Dave helped create. CODES was multi-typed records exposed to too much Gamma Radiation combined with too much LSD.

Sometimes a CODES record had an actual value in it like a logical file name or something. Other times the "value" was a logic code. Customer orders for a customer with this CODES key calls this set of functions for processing/pricing. Oh, you have a different code, you go down a different path. The logic paths were in that CODES record.

Other times a CODES record told you what BASIC MAP to use to map the fields of a record.

Yes, I can hear Dave screaming already "No! No! You idiot! You've only got some of it right!" It's been more than a decade man and I've spend that decade making medical devices.

You simply can't do the bastardizations we did with RMS indexed files using any form of SQL.

LIOCS and everyone else who stole the Singer ERP software originally written in Singer BASIC
Every record would have the same primary key format. Here is a snipped from that book

Invoice:
Key 0:
Invoice number char 10 15 in system s written later.
Rec_type char 2
Sequence_no char 2 Sometimes called line number
Generic m ap with filler at the end for some amount.

Record types:
10 Invoice header
20 Bill to information
30 Ship to information
40 Carrier information
60 Invoice detail
61 Detail comment
62 Credit or discount line
70 Credit or discount summary
80 Invoice summary

The 70 and 80 record types are not that common.

For the world that evolved from the ashes of Singer . . .

PDP BASIC we had separate FLD$() routines for each record type.

BASIC/PLUS (was that when we first got MAP that allowed things like INV_NO$ = 2%, followed by the & in the right margin?) Anyway there would be one MAP (INV) declaration for each record type.

VAX BASIC we got RECORD types. We all got smarter and declared file level IO-ROUTINE modules for each file. I think we nested the %INCLUDE statements so there was one %INCLUDE that pulled in all of the different RECORD definitions. All OPEN/CLOSE/CREATE/KEYED HIT/SEQUENTIAL/error was handled in the IO-ROUTINE module. As long as you didn't forget to check for error things worked well.

RMS indexed files had the fantastic feature of "Key of reference". Once you performed a keyed hit via a key, it established a "key of reference." (not every x86-wanna-be-a-real-computer-one-day-when-I-grow-up platforms have any concept like this) Once you did a keyed hit for the 10 record, you could sequentially process the order/invoice/whatever until the primary number changed. The record types put everything in the proper order for printing, screen display, general processing, etc.

Now, layer CODES on top of this.

Dave, feel free to jump in and point out how little I remember of TOLAS.

At any rate, there is no SQL that will let you put multi-typed records in a table. The "best" you could hope for is to have the primary key fields then a BLOB object one had to hack like we did in BASIC. You would be right back to CVT$% and RSET logic. (Didn't they drop RSET and LSET from the DEC BASIC specification at some point?)

On Thursday, June 23, 2022 at 4:28:37 PM UTC-5, Dave Froble wrote:

> Actually, not only is it not broke, it has utilities for ease of use. For a
> "more modern" (I hated typing that) implementation perhaps the utilities for
> ease of use might still be required to be developed.

See my reply on this. The "more modern" approach would take us back to PDP 11 days of FLD$() because the entire record past the end of the primary key would have to be a BLOB to implement multi-typed records. It would be viciously inefficient.

All you need is RMS indexed files to have usable file sizes and limits. Something like 36TB would be nice for starters.

On Tuesday, June 28, 2022 at 7:43:54 AM UTC-5, Arne Vajhøj wrote:
> On 6/27/2022 10:46 PM, Craig A. Berry wrote:
> >> B) UTF-16 internal and UTF-8 external
> >>
> >> That one requires a lot of work.
> >>
> >> Library support.
> >>
> >> Application changes.
> >>
> >> But it is efficient.
> >>
> >> Which is why C/C++, Java and .NET all chose that path.
> >
> > I think they made those choices when UCS-2 was current and everyone
> > thought a wider fixed-width encoding would be enough.
> Yes.
> > UTF-16 needs all
> > of the same varying-width handling that UTF-8
> In theory yes.
>
> In practice it is common for applications only to support BMP.
> > does but uses twice as
> > much memory for the most common characters.
> Most don't care.

Actually most do care about the memory consumption. Especially when it cascades out to disk that is too small. They also care about the overhead of CHAR processing.

C++ will soon follow the path CopperSpice took. They created QChar32 because we are now out to 32-bit Unicode. UTF-8 and UTF-16 have their own hacks for multi-unit characters and that adds processing overhead. The 32-bit character approach allows the database/indexed file/real data storage that isn't JSON or XML to cleanly do record compression for storage and decompression for retrieval without making the processor drag the 8-bottom plow of multi-unit character processing.

On Sunday, July 3, 2022 at 4:05:05 PM UTC-4, seasoned_geek wrote:
> At any rate, there is no SQL that will let you put multi-typed records in a table. The "best" you could hope for is to have the primary key fields then a BLOB object one had to hack like we did in BASIC. You would be right back to CVT$% and RSET logic. (Didn't they drop RSET and LSET from the DEC BASIC specification at some point?)

A sensible schema for the database would obviate the need for multi-typed records. Different types
of data are normalized into different tables.

As an exercise, I wrote an SQLite program to load OpenVMS accountng.dat files into a database. One
table had the record header information and then each packet type had a table (with a column that
referenced the record header table). The SQLitefiles ended up slightly smaller than the source file, my
guess is that the many small integers in resource packets consume less than the 4 bytes per counter
in the original. There were also small metadata tables, such as one holding the RFA of the last record
read -- loading the same file again will skip the previously read records and only add the subsequently
written records.

On 7/3/2022 4:05 PM, seasoned_geek wrote:
> On Thursday, June 23, 2022 at 9:14:07 AM UTC-5, osuv...@gmail.com wrote:
>> On Tuesday, June 21, 2022 at 12:08:21 AM UTC-4, Dave Froble wrote:
>>> Way, way, back, it was determined that due to the lack of adequate channels in
>>> Basic+, 12 to be precise, it would be advisable to have a single file that could
>>> be used for different types of data. Things with just a few records, such as
>>> maybe 20 terms codes, 50 state codes, and others. We even called it a "codes
>>> file".
>> That's the kind of thing SQLite is great at when used as what they call an
>> application file format. MacOS uses it for several of their applications now,
>> though they build the library without load extension capability.
>
> No man. You need to find a copy of this book
>
> https://www.theminimumyouneedtoknow.com/app_book.html
>
> and read the section on multi-typed records. SQL of no flavor can do
> what we did back then. What I put in the book was the best I could
> remember from LIOCS Perspective software. There were quite a few
> other DEC VARS that took the same approach to the point of using the
> same record types. I "think" they all stole the same Singer BASIC
> code.
> You simply can't do the bastardizations we did with RMS indexed files using any form of SQL.
>
> LIOCS and everyone else who stole the Singer ERP software originally written in Singer BASIC
> Every record would have the same primary key format. Here is a snipped from that book
>
> Invoice:
> Key 0:
> Invoice number char 10 15 in system s written later.
> Rec_type char 2
> Sequence_no char 2 Sometimes called line number
> Generic m ap with filler at the end for some amount.
>
> Record types:
> 10 Invoice header
> 20 Bill to information
> 30 Ship to information
> 40 Carrier information
> 60 Invoice detail
> 61 Detail comment
> 62 Credit or discount line
> 70 Credit or discount summary
> 80 Invoice summary

> At any rate, there is no SQL that will let you put multi-typed
> records in a table. The "best" you could hope for is to have the
> primary key fields then a BLOB object one had to hack like we did in
> BASIC. You would be right back to CVT$% and RSET logic. (Didn't they
> drop RSET and LSET from the DEC BASIC specification at some point?)

Not true.

You define a super class and sub classes and your ORM framework
transparently stores and retrieved the different classes.

That is basic persistence knowledge. Any young developer would
know that.

> RMS indexed files had the fantastic feature of "Key of reference".
> Once you performed a keyed hit via a key, it established a "key of
> reference." (not every
> x86-wanna-be-a-real-computer-one-day-when-I-grow-up platforms have
> any concept like this) Once you did a keyed hit for the 10 record,
> you could sequentially process the order/invoice/whatever until the
> primary number changed. The record types put everything in the proper
> order for printing, screen display, general processing, etc.
In SQL you just put in the ORDER BY's you need. Maybe not as
efficient (that all depends on the databases query optimizer).
But it is very simple to use.

Arne

On 7/3/2022 4:15 PM, seasoned_geek wrote:
> On Tuesday, June 28, 2022 at 7:43:54 AM UTC-5, Arne Vajhøj wrote:
>> On 6/27/2022 10:46 PM, Craig A. Berry wrote:
>>>> B) UTF-16 internal and UTF-8 external
>>>>
>>>> That one requires a lot of work.
>>>>
>>>> Library support.
>>>>
>>>> Application changes.
>>>>
>>>> But it is efficient.
>>>>
>>>> Which is why C/C++, Java and .NET all chose that path.
>>>
>>> I think they made those choices when UCS-2 was current and everyone
>>> thought a wider fixed-width encoding would be enough.
>> Yes.
>>> UTF-16 needs all
>>> of the same varying-width handling that UTF-8
>> In theory yes.
>>
>> In practice it is common for applications only to support BMP.
>>> does but uses twice as
>>> much memory for the most common characters.
>> Most don't care.
>
> Actually most do care about the memory consumption. Especially when
> it cascades out to disk that is too small. They also care about the
> overhead of CHAR processing.
Developers at least in the static typed compiled subset of languages
prefer languages that work that way.

(script languages for whatever reason often use UTF-8 internally)

> C++ will soon follow the path CopperSpice took. They created QChar32
> because we are now out to 32-bit Unicode. UTF-8 and UTF-16 have their
> own hacks for multi-unit characters and that adds processing
> overhead. The 32-bit character approach allows the database/indexed
> file/real data storage that isn't JSON or XML to cleanly do record
> compression for storage and decompression for retrieval without
> making the processor drag the 8-bottom plow of multi-unit character
> processing.
Maybe. I don't follow C++ standardization process.

But right now UTF-16 in memory and UTF-8 on disk is what
is used (in most of before mentioned segment).

Arne

On 2022-07-03 20:15:58 +0000, seasoned_geek said:

> On Tuesday, June 28, 2022 at 7:43:54 AM UTC-5, Arne Vajhøj wrote:
>> On 6/27/2022 10:46 PM, Craig A. Berry wrote:> >> B) UTF-16 internal and
>> UTF-8 external> >>> >> That one requires a lot of work.> >>> >> Library
>> support.> >>> >> Application changes.> >>> >> But it is efficient.> >>>
>> >> Which is why C/C++, Java and .NET all chose that path.> >> > I think
>> they made those choices when UCS-2 was current and everyone> > thought
>> a wider fixed-width encoding would be enough.
>> Yes.
>>> UTF-16 needs all> > of the same varying-width handling that UTF-8
>> In theory yes.>> In practice it is common for applications only to support BMP.
>>> does but uses twice as> > much memory for the most common characters.
>> Most don't care.
> Actually most do care about the memory consumption. Especially when it
> cascades out to disk that is too small. They also care about the
> overhead of CHAR processing.
>
> C++ will soon follow the path CopperSpice took. They created QChar32
> because we are now out to 32-bit Unicode. UTF-8 and UTF-16 have their
> own hacks for multi-unit characters and that adds processing overhead.
> The 32-bit character approach allows the database/indexed file/real
> data storage that isn't JSON or XML to cleanly do record compression
> for storage and decompression for retrieval without making the
> processor drag the 8-bottom plow of multi-unit character processing.

ObjC and ObjC++ solved this soup years ago.

As for C++, that's been a bit of a dog's breakfast for a while, and I use it.

Microsoft messed up with their wchar_t choice, which hasn't helped code
portability. Akin to the size_t choice on OpenVMS.

Characters (first) outside of what can be stored in char16_t happened
just after Y2K with Unicode 3.1, not that most folks noticed.

And yeah, the first plane (65536) is all but full now, so off into
char32_t for ~anything new.

The ICU, Reichwein, libunicode, or other available libraries might help
with Unicode. Or Boost, of course.

Or Go, Rust, Swift, or various other language choices—if OpenVMS isn't
a target, that is.

--
Pure Personal Opinion | HoffmanLabs LLC

In article <t9tmgc$39oe1$1@dont-email.me>, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> writes:
>On 2022-07-03 20:15:58 +0000, seasoned_geek said:
>
>> On Tuesday, June 28, 2022 at 7:43:54 AM UTC-5, Arne Vajhøj wrote:
>>> On 6/27/2022 10:46 PM, Craig A. Berry wrote:> >> B) UTF-16 internal and
>>> UTF-8 external> >>> >> That one requires a lot of work.> >>> >> Library
>>> support.> >>> >> Application changes.> >>> >> But it is efficient.> >>>
>>> >> Which is why C/C++, Java and .NET all chose that path.> >> > I think
>>> they made those choices when UCS-2 was current and everyone> > thought
>>> a wider fixed-width encoding would be enough.
>>> Yes.
>>>> UTF-16 needs all> > of the same varying-width handling that UTF-8
>>> In theory yes.>> In practice it is common for applications only to support BMP.
>>>> does but uses twice as> > much memory for the most common characters.
>>> Most don't care.
>> Actually most do care about the memory consumption. Especially when it
>> cascades out to disk that is too small. They also care about the
>> overhead of CHAR processing.
>>
>> C++ will soon follow the path CopperSpice took. They created QChar32
>> because we are now out to 32-bit Unicode. UTF-8 and UTF-16 have their
>> own hacks for multi-unit characters and that adds processing overhead.
>> The 32-bit character approach allows the database/indexed file/real
>> data storage that isn't JSON or XML to cleanly do record compression
>> for storage and decompression for retrieval without making the
>> processor drag the 8-bottom plow of multi-unit character processing.
>
>ObjC and ObjC++ solved this soup years ago.
>
>As for C++, that's been a bit of a dog's breakfast for a while, and I use it.
>
>Microsoft messed up with their wchar_t choice, which hasn't helped code
>portability. Akin to the size_t choice on OpenVMS.
>
>Characters (first) outside of what can be stored in char16_t happened
>just after Y2K with Unicode 3.1, not that most folks noticed.
>
>And yeah, the first plane (65536) is all but full now, so off into
>char32_t for ~anything new.
>
>The ICU, Reichwein, libunicode, or other available libraries might help
>with Unicode. Or Boost, of course.
>
>Or Go, Rust, Swift, or various other language choices—if OpenVMS isn't
>a target, that is.

Why does this thread make me think of Boltzmann's constant? ;)

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On Sunday, July 3, 2022 at 7:22:57 PM UTC-5, Arne Vajhøj wrote:
> On 7/3/2022 4:05 PM, seasoned_geek wrote:
> > On Thursday, June 23, 2022 at 9:14:07 AM UTC-5, osuv...@gmail.com wrote:
> >> On Tuesday, June 21, 2022 at 12:08:21 AM UTC-4, Dave Froble wrote:
> > At any rate, there is no SQL that will let you put multi-typed
> > records in a table. The "best" you could hope for is to have the
> > primary key fields then a BLOB object one had to hack like we did in
> > BASIC. You would be right back to CVT$% and RSET logic. (Didn't they
> > drop RSET and LSET from the DEC BASIC specification at some point?)
> Not true.
>
> You define a super class and sub classes and your ORM framework
> transparently stores and retrieved the different classes.
>
> That is basic persistence knowledge. Any young developer would
> know that.

Well, we will ask Dave to post the TOLAS invoice (or order) record layouts for a defunct customer and you create a functioning VAX BASIC program using SQLite along with Superclass and Subclass and post it here.

> > RMS indexed files had the fantastic feature of "Key of reference".
> > Once you performed a keyed hit via a key, it established a "key of
> > reference." (not every
> > x86-wanna-be-a-real-computer-one-day-when-I-grow-up platforms have
> > any concept like this) Once you did a keyed hit for the 10 record,
> > you could sequentially process the order/invoice/whatever until the
> > primary number changed. The record types put everything in the proper
> > order for printing, screen display, general processing, etc.
> In SQL you just put in the ORDER BY's you need. Maybe not as
> efficient (that all depends on the databases query optimizer).
> But it is very simple to use.

See above.