On 8/22/2023 7:46 PM, Arne Vajhøj wrote:
> On 8/22/2023 10:17 AM, Johnny Billquist wrote:
>> On 2023-08-21 14:10, Simon Clubley wrote:
>>> On 2023-08-18, Dave Froble <davef@tsoft-inc.com> wrote:
>>>> Just not anywhere as nice with RMS and "external to the database"
>>>> record
>>>> definitions.
>>>
>>> RMS was clearly designed by people who thought punched cards were
>>> cool...
>>
>> Yeah. Just like BDB. Or any other key-value datastore. Definitely
>> smells like puched cards...
>
> The concept is sort of timeless.
>
> ISAM/VSAM on IBM mainframe must be about as old as me.
>
> Lots of OS got similar features. Including VMS RMS.
> *nix got DBM in 1979 and BDB in 1994.
>
> It is a standard or at least de facto standard feature
> in Cobol.
>
> In this century the concept has become known
> as NoSQL key value store and several new has
> been created like:
>   LevelDB (Google) 2011
>   LMDB 2011
>   RocksDB (Facebook) 2012
>
> Where the age of RMS indexed-sequential files
> show is the 32 KB record size limit.

Timeless concept but the usage model has changed from
"default database choice" to "either low level building block
for something higher level like Relational Database or
NoSQL document store or a choice for special cases".

Arne

On 8/21/2023 8:10 AM, Simon Clubley wrote:
> On 2023-08-18, Dave Froble <davef@tsoft-inc.com> wrote:
>> Just not anywhere as nice with RMS and "external to the database" record
>> definitions.
>
> RMS was clearly designed by people who thought punched cards were cool...

Not sure what aspect of RMS that make you say that.

The existence of index-sequential file organization is a
common choice from IBM to FaceBook (see previous post). By
putting it in the OS with compiler support instead of
a language RTL or external library they made it very
easy to use same files from Cobol, Pascal and Basic. That is
pretty valuable for a multi-language environment like
VMS. And it is not oldfashioned in any way.

The existence of VAR, VFC, STM, STM_LF and STM_CR record
formats provided the ablity to actually provide info
about a files record format. Which at the conceptual
level is a good thing. It has become a bit problematic
in practice due to all the *nix software coming over
assuming STM_LF. But noone could foresee that back in
the late 70's.

Are there some details that could have been done
different and better? Absolutely! Having record
size limit of 2 GB (32 bit length) instead of
32 KB (16 bit length) would have been nice. If VAR
files has length both as line header and line trailer,
then such a file could easily be read backwards. I am
sure that if Hein could travel back in time he could
have optimized caching a lot. But wanting to change
some implementation details 45 years later is
no unique for RMS.

Arne

On 8/22/2023 8:05 PM, Arne Vajhøj wrote:
> On 8/21/2023 8:10 AM, Simon Clubley wrote:
>> On 2023-08-18, Dave Froble <davef@tsoft-inc.com> wrote:
>>> Just not anywhere as nice with RMS and "external to the database" record
>>> definitions.
>>
>> RMS was clearly designed by people who thought punched cards were cool...
>
> Not sure what aspect of RMS that make you say that.
>
> The existence of index-sequential file organization is a
> common choice from IBM to FaceBook (see previous post). By
> putting it in the OS with compiler support instead of
> a language RTL or external library they made it very
> easy to use same files from Cobol, Pascal and Basic. That is
> pretty valuable for a multi-language environment like
> VMS. And it is not oldfashioned in any way.
>
> The existence of VAR, VFC, STM, STM_LF and STM_CR record
> formats provided the ablity to actually provide info
> about a files record format. Which at the conceptual
> level is a good thing. It has become a bit problematic
> in practice due to all the *nix software coming over
> assuming STM_LF. But noone could foresee that back in
> the late 70's.
>
> Are there some details that could have been done
> different and better? Absolutely! Having record
> size limit of 2 GB (32 bit length) instead of
> 32 KB (16 bit length) would have been nice.

Some times you just drive me batty ....

What good would be a 2 GB record, when contemporary disk drives might be 100 MB,
or less?

> If VAR
> files has length both as line header and line trailer,
> then such a file could easily be read backwards. I am
> sure that if Hein could travel back in time he could
> have optimized caching a lot. But wanting to change
> some implementation details 45 years later is
> no unique for RMS.

Change hell, just implement what's needed. In 5-10 years, it will all be
obsolete anyway.

--
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 8/22/2023 10:19 PM, Dave Froble wrote:
> On 8/22/2023 8:05 PM, Arne Vajhøj wrote:
>> Are there some details that could have been done
>> different and better? Absolutely! Having record
>> size limit of 2 GB (32 bit length) instead of
>> 32 KB (16 bit length) would have been nice.
>
> Some times you just drive me batty ....
>
> What good would be a 2 GB record, when contemporary disk drives might be
> 100 MB, or less?

I don't think it took that many years before 32 KB limit
was a problem.

And from 16 bit the next step is 32 bit. Nobody want 24 bit
length.

>> If VAR
>> files has length both as line header and line trailer,
>> then such a file could easily be read backwards. I am
>> sure that if Hein could travel back in time he could
>> have optimized caching a lot. But wanting to change
>> some implementation details 45 years later is
>> no unique for RMS.
>
> Change hell, just implement what's needed.  In 5-10 years, it will all
> be obsolete anyway.

Some things are hard to change later without breaking too much.

Of course they could have introduced VAR2 and kept VAR for
compatibility.

Arne

On Tuesday, August 22, 2023 at 10:19:59 PM UTC-4, Dave Froble wrote:
> What good would be a 2 GB record, when contemporary disk drives might be 100 MB,
> or less?

ZFS supports filesystems of 2^128 bytes, well beyond what was possible when it was designed, or even today. It is a lot newer than RMS and thus has more experience with "can't scale" issues.

OTOH, some things in VMS show a small-system-memory mindset. I don't know If that's the reason for the 32KB limit or if it was inherited from the mostly-compatibility-mode environment of early VMS utilities.

I'll also mention again that if you want to get oddball record data out of RMS, you should probably look at C-Kermit's CKVFIO.C. There's code in there to deal with just about every possible RMS record type, including a few specific 3rd-party uses of "Undefined".

On 2023-08-22, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 8/21/2023 8:10 AM, Simon Clubley wrote:
>> On 2023-08-18, Dave Froble <davef@tsoft-inc.com> wrote:
>>> Just not anywhere as nice with RMS and "external to the database" record
>>> definitions.
>>
>> RMS was clearly designed by people who thought punched cards were cool...
>
> Not sure what aspect of RMS that make you say that.
>

That the record is a series of opaque bytes, instead of structured
fields with the knowledge about the fields built into RMS itself.

Simon.

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

On Tuesday, August 22, 2023 at 8:05:25 PM UTC-4, Arne Vajhøj wrote:
> Are there some details that could have been done
> different and better? Absolutely! Having record
> size limit of 2 GB (32 bit length) instead of
> 32 KB (16 bit length) would have been nice. If VAR
> files has length both as line header and line trailer,
> then such a file could easily be read backwards. I am
> sure that if Hein could travel back in time he could
> have optimized caching a lot. But wanting to change
> some implementation details 45 years later is
> no unique for RMS.
>

I'm not sure that's true, given how slow hardware was 45 years ago. Adding
6 bytes of meta-data to a VAR file with an average record length of 30
characters will increase the size by 18%. More space on disk and more I/O
operations to process the file.

On Wednesday, August 23, 2023 at 8:28:06 AM UTC-4, Simon Clubley wrote:
> That the record is a series of opaque bytes, instead of structured
> fields with the knowledge about the fields built into RMS itself.
> Simon.

To support any number of Unix applications reading of files, the C runtime
includes fgets() to return what is logically a record. So what?

On 2023-08-23, David Jones <osuvman50@gmail.com> wrote:
> On Wednesday, August 23, 2023 at 8:28:06?AM UTC-4, Simon Clubley wrote:
>> That the record is a series of opaque bytes, instead of structured
>> fields with the knowledge about the fields built into RMS itself.
>> Simon.
>
> To support any number of Unix applications reading of files, the C runtime
> includes fgets() to return what is logically a record. So what?

1) Nobody is working with RMS ISAM files by using fgets().

2) Have you ever seriously worked with RMS ISAM files in production use ?
I have, and they are a bloody great big pain in the backside to manage
and make record changes to, even minor changes.

Having ISAM files where the records are a series of structured fields
instead of something that looks like a digital version of a punched card
would be something that would have been a hell of a lot easier to maintain.

Simon.

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

On Wednesday, August 23, 2023 at 1:09:41 PM UTC-4, Simon Clubley wrote:
> 2) Have you ever seriously worked with RMS ISAM files in production use ?
> I have, and they are a bloody great big pain in the backside to manage
> and make record changes to, even minor changes.
>
> Having ISAM files where the records are a series of structured fields
> instead of something that looks like a digital version of a punched card
> would be something that would have been a hell of a lot easier to maintain.
> Simon.
>
> --
> Simon Clubley, clubley@remo_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

Yes, I have (prolog 3). It is a hassle, but it would be several times worse if I
had to maintain a consistent index or coordinate shared access without RMS.

Direct access to a relative file organization was a solution to certain kinds of
problems back in the day, so RMS added support for that as well.

On 8/23/2023 8:28 AM, Simon Clubley wrote:
> On 2023-08-22, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 8/21/2023 8:10 AM, Simon Clubley wrote:
>>> On 2023-08-18, Dave Froble <davef@tsoft-inc.com> wrote:
>>>> Just not anywhere as nice with RMS and "external to the database" record
>>>> definitions.
>>>
>>> RMS was clearly designed by people who thought punched cards were cool...
>>
>> Not sure what aspect of RMS that make you say that.
>
> That the record is a series of opaque bytes, instead of structured
> fields with the knowledge about the fields built into RMS itself.

"series of opaque bytes" is how ISAM files and NoSQL key value
stores work everywhere: you got key (or keys) and a data BLOB.

And all records do not need to have the same structure, so it is
not possible to define the structure.

Of course one can decide to have same structure for all records
and document the structure in the database.

DEC actually did that. And called it Rdb. :-)

Arne

On 8/23/2023 1:09 PM, Simon Clubley wrote:
> 2) Have you ever seriously worked with RMS ISAM files in production use ?
> I have, and they are a bloody great big pain in the backside to manage
> and make record changes to, even minor changes.

You need a conversion program.

That is how this particular technology works.

> Having ISAM files where the records are a series of structured fields
> instead of something that looks like a digital version of a punched card
> would be something that would have been a hell of a lot easier to maintain.

If you want a relational database then use one.

RMS ISAM files work as ISAM files and NoSQL key value stores
do everywhere else.

If it is not the right tool for the job, then use
a different tool.

Today most likely it is not the right tool for the job.
Rdb or MySQL/MariaDB or SQLite are likely to be a better
choice.

Arne

On 8/23/2023 8:47 AM, David Jones wrote:
> On Tuesday, August 22, 2023 at 8:05:25 PM UTC-4, Arne Vajhøj wrote:
>> Are there some details that could have been done
>> different and better? Absolutely! Having record
>> size limit of 2 GB (32 bit length) instead of
>> 32 KB (16 bit length) would have been nice. If VAR
>> files has length both as line header and line trailer,
>> then such a file could easily be read backwards. I am
>> sure that if Hein could travel back in time he could
>> have optimized caching a lot. But wanting to change
>> some implementation details 45 years later is
>> no unique for RMS.
>
> I'm not sure that's true, given how slow hardware was 45 years ago. Adding
> 6 bytes of meta-data to a VAR file with an average record length of 30
> characters will increase the size by 18%. More space on disk and more I/O
> operations to process the file.

I am not sure that I can follow the math.

Current VAR record overhead is header 2 bytes + average 0.5 even
pad byte and 2.5/30 is 8.3%.

Increasing to 32 bit would mean header 4 bytes + average 0.5 even
pad byte and 4.5/30 is 15.0%.

Increasing to 32 bit and add trailer length to support reading
backwards would mean header 4 bytes + average 0.5 even pad byte
+ trailer 4 bytes and 8.5/30 is 28.3%.

Yes - it is some overhead. But NOS/VE is almost as old as
VMS and used header 6 bytes and trailer 6 bytes. They could
apparently live with it.

Arne

On 8/23/2023 4:24 PM, Arne Vajhøj wrote:
> On 8/23/2023 8:47 AM, David Jones wrote:
>> On Tuesday, August 22, 2023 at 8:05:25 PM UTC-4, Arne Vajhøj wrote:
>>> Are there some details that could have been done
>>> different and better? Absolutely! Having record
>>> size limit of 2 GB (32 bit length) instead of
>>> 32 KB (16 bit length) would have been nice. If VAR
>>> files has length both as line header and line trailer,
>>> then such a file could easily be read backwards. I am
>>> sure that if Hein could travel back in time he could
>>> have optimized caching a lot. But wanting to change
>>> some implementation details 45 years later is
>>> no unique for RMS.
>>
>> I'm not sure that's true, given how slow hardware was 45 years ago.
>> Adding
>> 6 bytes of meta-data to a VAR file with an average record length of 30
>> characters will increase the size by 18%. More space on disk and more I/O
>> operations to process the file.
>
> I am not sure that I can follow the math.
>
> Current VAR record overhead is header 2 bytes + average 0.5 even
> pad byte and 2.5/30 is 8.3%.
>
> Increasing to 32 bit would mean header 4 bytes + average 0.5 even
> pad byte and 4.5/30 is 15.0%.
>
> Increasing to 32 bit and add trailer length to support reading
> backwards would mean header 4 bytes + average 0.5 even pad byte
> + trailer 4 bytes and 8.5/30 is 28.3%.
>
> Yes - it is some overhead. But NOS/VE is almost as old as
> VMS and used header 6 bytes and trailer 6 bytes. They could
> apparently live with it.

There were some areas where the 32 KB limit problem showed up
even back in time:
* having to split a logical record up in multiple physical
records in index-sequential files using key suffixes or some
other key scheme
* Fortran segmented files
* stream/stream_lf files being considered technically invalid
if more than 32 K between EOL markers (including by
CONV$ functions)

Arne

On Wednesday, August 23, 2023 at 4:24:17 PM UTC-4, Arne Vajhøj wrote:
> On 8/23/2023 8:47 AM, David Jones wrote:
> > I'm not sure that's true, given how slow hardware was 45 years ago. Adding
> > 6 bytes of meta-data to a VAR file with an average record length of 30
> > characters will increase the size by 18%. More space on disk and more I/O
> > operations to process the file.
> I am not sure that I can follow the math.
>
> Current VAR record overhead is header 2 bytes + average 0.5 even
> pad byte and 2.5/30 is 8.3%.
>
> Increasing to 32 bit would mean header 4 bytes + average 0.5 even
> pad byte and 4.5/30 is 15.0%.
>
> Increasing to 32 bit and add trailer length to support reading
> backwards would mean header 4 bytes + average 0.5 even pad byte
> + trailer 4 bytes and 8.5/30 is 28.3%.
>

I was comparing data+overhead in the 8 byte case and 2 byte case:
128.3% / 108.3% = 118.46%
> Yes - it is some overhead. But NOS/VE is almost as old as
> VMS and used header 6 bytes and trailer 6 bytes. They could
> apparently live with it.

NOS/VE is a 64-bit OS for CDC mainframes, quite a different animal than the
VAX/VMS environment.

On 8/23/2023 1:09 PM, Simon Clubley wrote:
> On 2023-08-23, David Jones <osuvman50@gmail.com> wrote:
>> On Wednesday, August 23, 2023 at 8:28:06?AM UTC-4, Simon Clubley wrote:
>>> That the record is a series of opaque bytes, instead of structured
>>> fields with the knowledge about the fields built into RMS itself.
>>> Simon.
>>
>> To support any number of Unix applications reading of files, the C runtime
>> includes fgets() to return what is logically a record. So what?
>
> 1) Nobody is working with RMS ISAM files by using fgets().

At least not from Basic ...

> 2) Have you ever seriously worked with RMS ISAM files in production use ?
> I have, and they are a bloody great big pain in the backside to manage
> and make record changes to, even minor changes.

I really don't know where that is coming from. While not my favorite, I find
working with RMS files to be reasonable. Perhaps we have different definitions
of reasonable.

> Having ISAM files where the records are a series of structured fields
> instead of something that looks like a digital version of a punched card
> would be something that would have been a hell of a lot easier to maintain.

Now you're talking about something like my database product, and you are
correct, much better to have record definitions as part of the data store.

Regardless, the tech has gotten better, and that's how it should be.

--
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 8/23/2023 5:43 PM, David Jones wrote:
> On Wednesday, August 23, 2023 at 4:24:17 PM UTC-4, Arne Vajhøj wrote:
>> On 8/23/2023 8:47 AM, David Jones wrote:
>>> I'm not sure that's true, given how slow hardware was 45 years ago. Adding
>>> 6 bytes of meta-data to a VAR file with an average record length of 30
>>> characters will increase the size by 18%. More space on disk and more I/O
>>> operations to process the file.
>> I am not sure that I can follow the math.
>>
>> Current VAR record overhead is header 2 bytes + average 0.5 even
>> pad byte and 2.5/30 is 8.3%.
>>
>> Increasing to 32 bit would mean header 4 bytes + average 0.5 even
>> pad byte and 4.5/30 is 15.0%.
>>
>> Increasing to 32 bit and add trailer length to support reading
>> backwards would mean header 4 bytes + average 0.5 even pad byte
>> + trailer 4 bytes and 8.5/30 is 28.3%.
>>
>
> I was comparing data+overhead in the 8 byte case and 2 byte case:
> 128.3% / 108.3% = 118.46%

Ah. Got it.

>> Yes - it is some overhead. But NOS/VE is almost as old as
>> VMS and used header 6 bytes and trailer 6 bytes. They could
>> apparently live with it.
>
> NOS/VE is a 64-bit OS for CDC mainframes, quite a different animal than the
> VAX/VMS environment.

Maybe. But some universities actually had both.

Arne

On 2023-08-23 05:48, terry-...@glaver.org wrote:
> On Tuesday, August 22, 2023 at 10:19:59 PM UTC-4, Dave Froble wrote:
>> What good would be a 2 GB record, when contemporary disk drives might be 100 MB,
>> or less?
>
> ZFS supports filesystems of 2^128 bytes, well beyond what was possible when it was designed, or even today. It is a lot newer than RMS and thus has more experience with "can't scale" issues.
>
> OTOH, some things in VMS show a small-system-memory mindset. I don't know If that's the reason for the 32KB limit or if it was inherited from the mostly-compatibility-mode environment of early VMS utilities.

It's most likely inherited from the PDP-11, where RMS also exists...

Johnny

On 2023-08-23 14:28, Simon Clubley wrote:
> On 2023-08-22, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 8/21/2023 8:10 AM, Simon Clubley wrote:
>>> On 2023-08-18, Dave Froble <davef@tsoft-inc.com> wrote:
>>>> Just not anywhere as nice with RMS and "external to the database" record
>>>> definitions.
>>>
>>> RMS was clearly designed by people who thought punched cards were cool...
>>
>> Not sure what aspect of RMS that make you say that.
>>
>
> That the record is a series of opaque bytes, instead of structured
> fields with the knowledge about the fields built into RMS itself.

I don't even understand what you said here.
There is *some* information about fields in RMS, but it's partial.
If you want to talk about opaque stream of bytes, I would say "aha - you
are talking about Unix view of a file".

Johnny

On 2023-08-23 19:09, Simon Clubley wrote:
> On 2023-08-23, David Jones <osuvman50@gmail.com> wrote:
>> On Wednesday, August 23, 2023 at 8:28:06?AM UTC-4, Simon Clubley wrote:
>>> That the record is a series of opaque bytes, instead of structured
>>> fields with the knowledge about the fields built into RMS itself.
>>> Simon.
>>
>> To support any number of Unix applications reading of files, the C runtime
>> includes fgets() to return what is logically a record. So what?
>
> 1) Nobody is working with RMS ISAM files by using fgets().

True. Because that would really just get you an opaque stream of bytes.

> 2) Have you ever seriously worked with RMS ISAM files in production use ?
> I have, and they are a bloody great big pain in the backside to manage
> and make record changes to, even minor changes.

I would disagree. There are even tools that make this easy. At least
under RSX, and I would be very surprised to learn that VMS have anything
less.

> Having ISAM files where the records are a series of structured fields
> instead of something that looks like a digital version of a punched card
> would be something that would have been a hell of a lot easier to maintain.

You do know that they can be of variable length, right?

"Punched cards"... I get the feeling you have never worked with punched
cards...

Johnny

On Thursday, August 24, 2023 at 5:59:38 AM UTC-4, Johnny Billquist wrote:
> "Punched cards"... I get the feeling you have never worked with punched
> cards...
>

I don't know about Simon, but I used punch cards for my PL/1 class on a
mainframe. VMS seems to have dropped INPSMB.EXE somewhere along
the way, so I don't think it can start jobs from a card reader any more.

Into the early 2000s, however, I did write tools to process a file, distributed on
CD-ROM, that was literally 80 column card images (distribution on cards stopped
in 1986). Look up National Bureau of Standards AIDS83 format.

Den 2023-08-24 kl. 13:23, skrev David Jones:
> On Thursday, August 24, 2023 at 5:59:38 AM UTC-4, Johnny Billquist wrote:
>> "Punched cards"... I get the feeling you have never worked with punched
>> cards...
>>
>
> I don't know about Simon, but I used punch cards for my PL/1 class on a
> mainframe. VMS seems to have dropped INPSMB.EXE somewhere along
> the way, so I don't think it can start jobs from a card reader any more.
>
> Into the early 2000s, however, I did write tools to process a file, distributed on
> CD-ROM, that was literally 80 column card images (distribution on cards stopped
> in 1986). Look up National Bureau of Standards AIDS83 format.

It was (maybe still is) interesting on the IBM MVS systems. They once
started as a "punched card input/line printer output" only systems.

Today (or at least 15 years ago), when you "submitted" a batch job from the
TSP/ISPF editor, it sent the file to a device called INTRDR, spelled out as
the "internal card reader". So, for the core OS, the batch job was still
running from a stack of punched cards, but simulated, so to speak...

And b.t.w, this is also partly so in DCL with the way inline data can be
coded in a DCL batch job with the $DECK and $EOD commands. And why not:

$ help job

JOB

Identifies the beginning of a batch job submitted through a card
reader. Each batch job submitted through the system card reader
must be preceded by a JOB card.

$ help eoj

EOJ

Marks the end of a batch job submitted through a card reader.

No idea what happens if you try these with the SUBMIT command... :-)

On Thursday, August 24, 2023 at 8:13:53 AM UTC-4, Jan-Erik Söderholm wrote:
> It was (maybe still is) interesting on the IBM MVS systems. They once
> started as a "punched card input/line printer output" only systems.

Wasn't that the canonical I/O on a virtual machine under VM/CMS?
>
> $ help eoj
>
> EOJ
>
> Marks the end of a batch job submitted through a card reader.
>

I got into the habit of using EOJ to logout as most sys admins that think
it's useful to define a logout symbol aren't aware this alternative exists. It
is a little cleaner than stop/id=0.

On 8/24/2023 5:57 AM, Johnny Billquist wrote:
> On 2023-08-23 14:28, Simon Clubley wrote:
>> On 2023-08-22, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 8/21/2023 8:10 AM, Simon Clubley wrote:
>>>> On 2023-08-18, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>> Just not anywhere as nice with RMS and "external to the database" record
>>>>> definitions.
>>>>
>>>> RMS was clearly designed by people who thought punched cards were cool...
>>>
>>> Not sure what aspect of RMS that make you say that.
>>>
>>
>> That the record is a series of opaque bytes, instead of structured
>> fields with the knowledge about the fields built into RMS itself.
>
> I don't even understand what you said here.
> There is *some* information about fields in RMS, but it's partial.
> If you want to talk about opaque stream of bytes, I would say "aha - you are
> talking about Unix view of a file".
>
> Johnny
>

RMS keys are defined as locations in a data record. Not sure I'd define that as
"information about fields". As far as I know, RMS (other than key definitions)
knows nothing about data fields/columns/whatever.

--
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 2023-08-24 16:05, Dave Froble wrote:
> On 8/24/2023 5:57 AM, Johnny Billquist wrote:
>> On 2023-08-23 14:28, Simon Clubley wrote:
>>> On 2023-08-22, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 8/21/2023 8:10 AM, Simon Clubley wrote:
>>>>> On 2023-08-18, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>>> Just not anywhere as nice with RMS and "external to the database"
>>>>>> record
>>>>>> definitions.
>>>>>
>>>>> RMS was clearly designed by people who thought punched cards were
>>>>> cool...
>>>>
>>>> Not sure what aspect of RMS that make you say that.
>>>>
>>>
>>> That the record is a series of opaque bytes, instead of structured
>>> fields with the knowledge about the fields built into RMS itself.
>>
>> I don't even understand what you said here.
>> There is *some* information about fields in RMS, but it's partial.
>> If you want to talk about opaque stream of bytes, I would say "aha -
>> you are
>> talking about Unix view of a file".
>>
>>   Johnny
>>
>
> RMS keys are defined as locations in a data record.  Not sure I'd define
> that as "information about fields".  As far as I know, RMS (other than
> key definitions) knows nothing about data fields/columns/whatever.

RMS keys have a type (obviously). You can also have some meta-data, even
though I suspect it's mostly not used...

..dsp [1,7]mailqUEUE.DAT/fu

DU:[1,7]MAILQUEUE.DAT;17 RMS Prologue Version=2
Size: 2604./2604. Created: 5-OCT-2019 01:13
Owner: [001,054] Revised: 24-AUG-2023
19:19 (337
77)
File ID: (67530,64,0) Expires: <none_specified>
File protection: System:RWE, Owner:RWE, Group:, World:
File organization: Indexed, using 3 key(s) with 1 area(s)
File attributes: Allocation=2604, Extend=100, Bucket size=4
Record format: Fixed length 1104 byte records
Record attributes: None

Area number 0:
Bucket size=4
Allocation remaining=24, Extend=0

Primary key:
Name=Host, Minimum record length=255
Key information:
Type=String, Length=255, Duplicates, No changes
Position(s) and size(s):
Segment=0, position=0, length=255
Area information:
Index: Area number=0
Lowest level area=0
Bucket size=4, Fill factor=2048
Data: Area number=0
Bucket size=4, Fill factor=2048
Allocation information:
Root virtual block number=209, Root level=2
First data bucket virtual block number=9

Alternate key number 1:
Name=Entry No, Minimum record length=262
Key information:
Type=Binary, Length=4, No duplicates, No changes
Position(s) and size(s):
Segment=0, position=258, length=4
Area information:
Index: Area number=0
Lowest level area=0
Bucket size=4, Fill factor=2048
Data: Area number=0
Bucket size=4, Fill factor=2048
Allocation information:
Root virtual block number=13, Root level=1
First data bucket virtual block number=17

Alternate key number 2:
Name=Filename, Minimum record length=1074
Key information:
Type=String, Length=38, Duplicates, No changes
Position(s) and size(s):
Segment=0, position=1036, length=38
Area information:
Index: Area number=0
Lowest level area=0
Bucket size=4, Fill factor=2048
Data: Area number=0
Bucket size=4, Fill factor=2048
Allocation information:
Root virtual block number=21, Root level=1
First data bucket virtual block number=25

Note both the name, and type information for each key. However, the name
have no function as such within RMS. At least not under RSX. But you can
put information there if you want to.

And key #1 in my case is an unsigned 32-bit integer.

Johnny