On 9/20/2023 12:18 AM, Hein RMS van den Heuvel wrote:
> Yes indeed traditionally folks only had half a clue about RMS and vaguely know 512 was a special value and very popular.
>
> With that they proceeded to maximize their storage losses.
>
> The one flag byte overhead relative file records have (plus two for variable) makes the cells larger than 512
> By default FORTRANT/RMS will now use the default 2 block bucketsize
> Thus wasting 511 (509) bytes per 512 byte record.

I could have used recl=508.

:-)

Arne

On 9/20/2023 8:22 AM, Simon Clubley wrote:
> On 2023-09-20, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 9/19/2023 11:15 PM, gah4 wrote:
>>> On Tuesday, September 19, 2023 at 5:46:29?PM UTC-7, Arne Vajhøj wrote:
>>>> open(unit=1,file='rel.dat',status='new',form='formatted',
>>>> + organization='relative',recl=512,recordtype='variable',
>>>> + access='direct')
>>>
>>> OP asked about fixed record size, and traditionally that is
>>> the way it was done. I haven't followed that detail of later
>>> Fortran standards. They have to, at least, allocate to the
>>> maximum size.
>>
>> True.
>>
>> I added a little more for my example.
>>
>> If I understand the docs correctly then the above
>> allocates 512 bytes (per recl) for each cell, but
>> handles actual lengths 0-512 within that cell.
>
> It allocates 512 bytes for the _data_ within that cell. It then allocates
> a bit more per record to store the length of each record. Look at the
> example Hein posted.
>
> $ set response/mode=good_natured
>
> Even without your statement about never having used relative files,
> at this point I would be actively suspecting that to be the case. :-)
>
> I _have_ used relative files in the past in a number of cases, but I have
> never, ever, used anything other than fixed length records with them.
>
> The idea of variable length records within a relative file is utterly
> alien to me.

Maybe.

I could have used fixed:

$ type rel2wrt.for
program rel2wrt
integer*4 i
character*20 buf
open(unit=1,file='rel.dat',status='new',form='formatted',
+ organization='relative',recl=20,recordtype='fixed',
+ access='direct')
do 100 i = 1, 100
write(buf,'(14HThis is line #,i4.4,2H!!)') i
write(unit=1,rec=i) buf
100 continue
close(unit=1)
end
$ for rel2wrt
$ link rel2wrt
$ run rel2wrt
$ type rel2rdseq.for
program rel2rdseq
integer*4 i
character*20 buf
open(unit=1,file='rel.dat',status='old',form='formatted',
+ organization='relative',recl=20,recordtype='fixed',
+ access='sequential')
100 read(unit=1,fmt='(a)',end=200) buf
write(*,*) '|'//buf//'|'
goto 100
200 close(unit=1)
end
$ for rel2rdseq
$ link rel2rdseq
$ run rel2rdseq
|This is line #0001!!|
|This is line #0002!!|
....
|This is line #0100!!|
$ type rel2rddir.for
program rel2rddir
integer*4 i
character*20 buf
open(unit=1,file='rel.dat',status='old',form='formatted',
+ organization='relative',recl=20,recordtype='fixed',
+ access='direct')
do 200 i = 1, 100
read(unit=1,fmt='(a)',rec=i) buf
write(*,*) '|'//buf//'|'
200 continue
close(unit=1)
end
$ for rel2rddir
$ link rel2rddir
$ run rel2rddir
|This is line #0001!!|
|This is line #0002!!|
....
|This is line #0100!!|

But the point was to illustrate usage of relative files.

The code above is a very poor illustration of relative files.

Because there is nothing relative specific in it. The exact same code
works fine with:
organization='sequential'

Direct access for rfm fixed works fine even for org sequential. No need
for org relative.

Direct access for rfm variable does not work for org sequential only
for org relative.

Arne

On 9/20/2023 7:39 PM, Arne Vajhøj wrote:
> On 9/20/2023 8:22 AM, Simon Clubley wrote:
>> On 2023-09-20, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 9/19/2023 11:15 PM, gah4 wrote:
>>>> On Tuesday, September 19, 2023 at 5:46:29?PM UTC-7, Arne Vajhøj wrote:
>>>>> open(unit=1,file='rel.dat',status='new',form='formatted',
>>>>> + organization='relative',recl=512,recordtype='variable',
>>>>> + access='direct')
>>>> OP asked about fixed record size, and traditionally that is
>>>> the way it was done.  I haven't followed that detail of later
>>>> Fortran standards. They have to, at least, allocate to the
>>>> maximum size.
>>>
>>> True.
>>>
>>> I added a little more for my example.
>>>
>>> If I understand the docs correctly then the above
>>> allocates 512 bytes (per recl) for each cell, but
>>> handles actual lengths 0-512 within that cell.
>>
>> It allocates 512 bytes for the _data_ within that cell. It then allocates
>> a bit more per record to store the length of each record. Look at the
>> example Hein posted.
>>
>> $ set response/mode=good_natured
>>
>> Even without your statement about never having used relative files,
>> at this point I would be actively suspecting that to be the case. :-)
>>
>> I _have_ used relative files in the past in a number of cases, but I have
>> never, ever, used anything other than fixed length records with them.
>>
>> The idea of variable length records within a relative file is utterly
>> alien to me.
>
> Maybe.
>
> I could have used fixed:
....
> But the point was to illustrate usage of relative files.
>
> The code above is a very poor illustration of relative files.
>
> Because there is nothing relative specific in it. The exact same code
> works fine with:
>    organization='sequential'
>
> Direct access for rfm fixed works fine even for org sequential. No need
> for org relative.
>
> Direct access for rfm variable does not work for org sequential only
> for org relative.

Alternatively I could have used non-existing records
to illustrate relative.

$ type rel3wrt.for
program rel3wrt
integer*4 i
character*20 buf
open(unit=1,file='rel.dat',status='new',form='formatted',
+ organization='relative',recl=20,recordtype='fixed',
+ access='direct')
do 100 i = 1, 100, 2
write(buf,'(14HThis is line #,i4.4,2H!!)') i
write(unit=1,rec=i) buf
100 continue
close(unit=1)
end
$ for rel3wrt
$ link rel3wrt
$ run rel3wrt
$ type rel3rdseq.for
program rel3rdseq
integer*4 i
character*20 buf
open(unit=1,file='rel.dat',status='old',form='formatted',
+ organization='relative',recl=20,recordtype='fixed',
+ access='sequential')
100 read(unit=1,fmt='(a)',end=200) buf
write(*,*) '|'//buf//'|'
goto 100
200 close(unit=1)
end
$ for rel3rdseq
$ link rel3rdseq
$ run rel3rdseq
|This is line #0001!!|
|This is line #0003!!|
....
|This is line #0099!!|
$ type rel3rddir.for
program rel3rddir
integer*4 i
character*20 buf
open(unit=1,file='rel.dat',status='old',form='formatted',
+ organization='relative',recl=20,recordtype='fixed',
+ access='direct')
do 200 i = 1, 100
read(unit=1,fmt='(a)',rec=i, err=200) buf
write(*,*) '|'//buf//'|'
200 continue
close(unit=1)
end
$ for rel3rddir
$ link rel3rddir
$ run rel3rddir
|This is line #0001!!|
|This is line #0003!!|
....
|This is line #0099!!|

which can be done for org sequential but quite as nice:

$ type seq3wrt.for
program seq3wrt
integer*4 i
character*20 buf
open(unit=1,file='seq.dat',status='new',form='formatted',
+ organization='sequential',recl=20,recordtype='fixed',
+ access='direct')
do 100 i = 1, 100, 2
write(buf,'(14HThis is line #,i4.4,2H!!)') i
write(unit=1,rec=i) buf
100 continue
close(unit=1)
end
$ for seq3wrt
$ link seq3wrt
$ run seq3wrt
$ type seq3rdseq.for
program seq3rdseq
integer*4 i
character*20 buf
open(unit=1,file='seq.dat',status='old',form='formatted',
+ organization='sequential',recl=20,recordtype='fixed',
+ access='sequential')
100 read(unit=1,fmt='(a)',end=200) buf
if(buf(1:1).ne.char(0)) then
write(*,*) '|'//buf//'|'
end if
goto 100
200 close(unit=1)
end
$ for seq3rdseq
$ link seq3rdseq
$ run seq3rdseq
|This is line #0001!!|
|This is line #0003!!|
....
|This is line #0099!!|
$ type seq3rddir.for
program seq3rddir
integer*4 i
character*20 buf
open(unit=1,file='seq.dat',status='old',form='formatted',
+ organization='sequential',recl=20,recordtype='fixed',
+ access='direct')
do 200 i = 1, 100
read(unit=1,fmt='(a)',rec=i,err=200) buf
if(buf(1:1).ne.char(0)) then
write(*,*) '|'//buf//'|'
end if
200 continue
close(unit=1)
end
$ for seq3rddir
$ link seq3rddir
$ run seq3rddir
|This is line #0001!!|
|This is line #0003!!|
....
|This is line #0099!!|

Arne

On 9/20/2023 12:23 PM, bill wrote:
> Funny thing about this.  I found very little about it in any of
> the (many) COBOL books I have.  I also don't remember ever having
> done it in a production program in my entire 40 year career.
> This kind of task was done much better with ISAM and today it
> would be database.

I don't think relative files has been big anywhere anytime.

But it is supported in the Cobol standard.

I don't see any point of relative files in newer times, but
I suspect that going sufficiently long time back there were
performance reasons to prefer relative over indexed/ISAM

A relative read is:

calculate byte offset = record number * record length
read record length bytes starting at byte offset from file

An indexed/ISAM read is:

read root page
search in root page and find next level index page
read index page
search in index page and find either next level index page or data page
....
read data page
find record in data page

Difference in both number of IO's and CPU usage.

Does it matter on a x86-86? Probably not.

Did it matter on Itanium and Alpha? Probably not.

Did it matter on VAX? Maybe in some cases.

Did it matter on PDP-11? Probably.

Did it matter on PDP-8? If stuff like this was even possible then I am
pretty sure yes.

Arne

On 9/20/2023 7:53 PM, Arne Vajhøj wrote:
> On 9/20/2023 7:39 PM, Arne Vajhøj wrote:
>> On 9/20/2023 8:22 AM, Simon Clubley wrote:
>>> On 2023-09-20, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 9/19/2023 11:15 PM, gah4 wrote:
>>>>> On Tuesday, September 19, 2023 at 5:46:29?PM UTC-7, Arne Vajhøj wrote:
>>>>>> open(unit=1,file='rel.dat',status='new',form='formatted',
>>>>>> + organization='relative',recl=512,recordtype='variable',
>>>>>> + access='direct')
>>>>> OP asked about fixed record size, and traditionally that is
>>>>> the way it was done.  I haven't followed that detail of later
>>>>> Fortran standards. They have to, at least, allocate to the
>>>>> maximum size.
>>>>
>>>> True.
>>>>
>>>> I added a little more for my example.
>>>>
>>>> If I understand the docs correctly then the above
>>>> allocates 512 bytes (per recl) for each cell, but
>>>> handles actual lengths 0-512 within that cell.
>>>
>>> It allocates 512 bytes for the _data_ within that cell. It then
>>> allocates
>>> a bit more per record to store the length of each record. Look at the
>>> example Hein posted.
>>>
>>> $ set response/mode=good_natured
>>>
>>> Even without your statement about never having used relative files,
>>> at this point I would be actively suspecting that to be the case. :-)
>>>
>>> I _have_ used relative files in the past in a number of cases, but I
>>> have
>>> never, ever, used anything other than fixed length records with them.
>>>
>>> The idea of variable length records within a relative file is utterly
>>> alien to me.
>>
>> Maybe.
>>
>> I could have used fixed:
> ...
>> But the point was to illustrate usage of relative files.
>>
>> The code above is a very poor illustration of relative files.
>>
>> Because there is nothing relative specific in it. The exact same code
>> works fine with:
>>     organization='sequential'
>>
>> Direct access for rfm fixed works fine even for org sequential. No need
>> for org relative.
>>
>> Direct access for rfm variable does not work for org sequential only
>> for org relative.
>
> Alternatively I could have used non-existing records
> to illustrate relative.

> which can be done for org sequential but quite as nice:
^not

Arne

On Wednesday, September 20, 2023 at 8:07:47 PM UTC-4, Arne Vajhøj wrote:
: > A relative read is:
>
> calculate byte offset = record number * record length
> read record length bytes starting at byte offset from file

Noop.
Not for RMS. Not even for fixed length record sequential files.

Sequential files are conceptually divided into fixed length Multi Block Count (MBC) time 512 byte buffers.
For shared file access the first accessor locks in the MBC. Default MBC=16 = 8KB.
RMS will first take an integer round down to MBC to find the first MBC block to read and finds the record in there.
It may need a second read if the records spills over the end, even if it could have just started the read later.

For Relative files RMS divides the file up into buckets (default = big enough to hold 1 at least record.
It first calculates records/bucket (RPB) integer divide of bucketsize*512 and (one (flag byte) plus Maximum Record Size).
Next calculate VBN as 1 (File Prologue) plus integer divide of record number by RPB times RPB.
Read BKS * 512 bytes, and locate the record.
Hein.

On Wednesday, September 20, 2023 at 7:33:10 PM UTC-4, Arne Vajhøj wrote:
> On 9/20/2023 12:18 AM, Hein RMS van den Heuvel wrote:
> > Yes indeed traditionally folks only had half a clue about RMS and vaguely know 512 was a special value and very popular.
> >
> > With that they proceeded to maximize their storage losses.
> >

> I could have used recl=508.

Yes you could, and so could have hundreds of commercial programmers but the point is they didn't!
They all picked 512 and proceeded to add 'filler' bytes to their record definitions 'just in case' just like you did.

:-)

Hein

On Wednesday, September 20, 2023 at 7:37:33 PM UTC-7, Hein RMS van den Heuvel wrote:

(snip)

> For Relative files RMS divides the file up into buckets (default = big enough to hold 1 at least record.
> It first calculates records/bucket (RPB) integer divide of bucketsize*512 and (one (flag byte) plus Maximum Record Size).
> Next calculate VBN as 1 (File Prologue) plus integer divide of record number by RPB times RPB.
> Read BKS * 512 bytes, and locate the record.

For comparison OS/360, not all that long before VMS, writes disk tracks with
physical blocks equal to the record lengths. (Sequential files are normally written
with blocked records, but again they are written to the physical block length.)

Disks are accessed by cylinder, track, and block within the track. OS knows how
many blocks are on a track, and calculates the track and record within the track.
That made more sense in 1963 than it did later.

More recent OS work the same way, but the disk drives emulate the count-key-data
system using fixed-block disk drives.

On 9/20/2023 8:07 PM, Arne Vajhøj wrote:
> On 9/20/2023 12:23 PM, bill wrote:
>> Funny thing about this.  I found very little about it in any of
>> the (many) COBOL books I have.  I also don't remember ever having
>> done it in a production program in my entire 40 year career.
>> This kind of task was done much better with ISAM and today it
>> would be database.
>
> I don't think relative files has been big anywhere anytime.
>
> But it is supported in the Cobol standard.
>
> I don't see any point of relative files in newer times, but
> I suspect that going sufficiently long time back there were
> performance reasons to prefer relative over indexed/ISAM

While ISAM may be less efficient relative files can waste a
lot of space. Space is allocated for empty records and back
in the good ole days disk space was premium and very expensive.

>
> A relative read is:
>
> calculate byte offset = record number * record length
> read record length bytes starting at byte offset from file
>
> An indexed/ISAM read is:
>
> read root page
> search in root page and find next level index page
> read index page
> search in index page and find either next level index page or data page
> ...
> read data page
> find record in data page
>
> Difference in both number of IO's and CPU usage.
>
> Does it matter on a x86-86? Probably not.
>
> Did it matter on Itanium and Alpha? Probably not.
>
> Did it matter on VAX? Maybe in some cases.
>
> Did it matter on PDP-11? Probably.
>
> Did it matter on PDP-8? If stuff like this was even possible then I am
> pretty sure yes.
>
> Arne
>

bill

On Thursday, September 21, 2023 at 5:19:50 AM UTC-7, bill wrote:

(snip)

> While ISAM may be less efficient relative files can waste a
> lot of space. Space is allocated for empty records and back
> in the good ole days disk space was premium and very expensive.

Relative files are convenient if your numbering system is already
not sparse.

Otherwise, it is usually to make it a hash table, and hash the
index before using it to read/write a record.

ISAM is convenient, in that it does some of the work for you,
that you could otherwise do yourself.

As far as I know, ISAM first appeared in OS/360. Among others,
it uses features of the S/360 disk controllers for finding records.
That minimized memory use at the time. For one,
it puts absolute disk addresses in the index, not relative.
The data sets have the U (unmovable) attribute.
There are utility programs that know how to back them
up, and restore them to different disk addresses.

They also use self-modifying channel programs.
Pretty much the equivalent of self-modifying code,
but at the I/O channel level.

There is special code in VM/CMS for processing the self-modifying
channel programs from ISAM. But much of that was later fixed
by VSAM instead, which also has ISAM emulation.

On 9/21/2023 1:10 PM, gah4 wrote:
> On Thursday, September 21, 2023 at 5:19:50 AM UTC-7, bill wrote:
>
> (snip)
>
>> While ISAM may be less efficient relative files can waste a
>> lot of space. Space is allocated for empty records and back
>> in the good ole days disk space was premium and very expensive.
>
> Relative files are convenient if your numbering system is already
> not sparse.
>
> Otherwise, it is usually to make it a hash table, and hash the
> index before using it to read/write a record.

If the requirement is some type of keyed file, then just use a keyed file type.

--
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 Thursday, September 21, 2023 at 10:22:57 AM UTC-7, Dave Froble wrote:

(snip)

> > Otherwise, it is usually to make it a hash table, and hash the
> > index before using it to read/write a record.

> If the requirement is some type of keyed file, then just use a keyed file type.

OS/360 has a keyed file type, but I believe it does a linear search.
I suspect it is used for the index of ISAM.

On Thursday, September 21, 2023 at 2:20:44 PM UTC-4, gah4 wrote:
>
> > If the requirement is some type of keyed file, then just use a keyed file type.
> OS/360 has a keyed file type, but I believe it does a linear search.
> I suspect it is used for the index of ISAM.

My recollection is that RMS indexed files are more akin to IBM VSAM file structure,
ISAM came earlier.

On Thursday, September 21, 2023 at 2:02:39 PM UTC-7, David Jones wrote:
> On Thursday, September 21, 2023 at 2:20:44 PM UTC-4, gah4 wrote:
> > > If the requirement is some type of keyed file, then just use a keyed file type.
> > OS/360 has a keyed file type, but I believe it does a linear search.
> > I suspect it is used for the index of ISAM.

> My recollection is that RMS indexed files are more akin to IBM VSAM file structure,
> ISAM came earlier.

VSAM is supposed to have started with OS/VS about 1973.
That would have been in time for VMS.

I think it was some time after 1973 by the time I first heard about it,
and even then much longer before I knew anything about it.
(Other than sounding fancy and new.)

BISAM and QISAM, the actual IBM names, depends a lot on feature
of S/360 and especially channels. But also memory sizes increased
much from 1963 to 1973. OS/360 could run on machines down to
about 64K bytes, though for them DOS/360 might be more usual.

Otherwise, outside IBM, ISAM seems to be a generic term for something
that might or might not be so similar.

On 9/21/2023 8:19 AM, bill wrote:
> On 9/20/2023 8:07 PM, Arne Vajhøj wrote:
>> On 9/20/2023 12:23 PM, bill wrote:
>>> Funny thing about this.  I found very little about it in any of
>>> the (many) COBOL books I have.  I also don't remember ever having
>>> done it in a production program in my entire 40 year career.
>>> This kind of task was done much better with ISAM and today it
>>> would be database.
>>
>> I don't think relative files has been big anywhere anytime.
>>
>> But it is supported in the Cobol standard.
>>
>> I don't see any point of relative files in newer times, but
>> I suspect that going sufficiently long time back there were
>> performance reasons to prefer relative over indexed/ISAM
>
> While ISAM may be less efficient relative files can waste a
> lot of space.  Space is allocated for empty records and back
> in the good ole days disk space was premium and very expensive.

True. Relative files only makes sense if keys does not have
too much holes. As usual there are tradeoffs.

Arne

On 9/21/2023 1:10 PM, gah4 wrote:
> On Thursday, September 21, 2023 at 5:19:50 AM UTC-7, bill wrote:
>> While ISAM may be less efficient relative files can waste a
>> lot of space. Space is allocated for empty records and back
>> in the good ole days disk space was premium and very expensive.
>
> Relative files are convenient if your numbering system is already
> not sparse.
>
> Otherwise, it is usually to make it a hash table, and hash the
> index before using it to read/write a record.

A hashing producing non sparse results will typical also
produce a lot of collisions requiring collision handling.

Arne

On 2023-09-22 00:06, gah4 wrote:
> On Thursday, September 21, 2023 at 2:02:39 PM UTC-7, David Jones wrote:
>> On Thursday, September 21, 2023 at 2:20:44 PM UTC-4, gah4 wrote:
>
>>>> If the requirement is some type of keyed file, then just use a keyed file type.
>>> OS/360 has a keyed file type, but I believe it does a linear search.
>>> I suspect it is used for the index of ISAM.
>
>> My recollection is that RMS indexed files are more akin to IBM VSAM file structure,
>> ISAM came earlier.
>
> VSAM is supposed to have started with OS/VS about 1973.
> That would have been in time for VMS.

Well, RMS didn't start with VMS. But I think RMS was at, or after 1973
anyway...

Johnny

On 9/21/2023 6:12 PM, Arne Vajhøj wrote:
> On 9/21/2023 1:10 PM, gah4 wrote:
>> On Thursday, September 21, 2023 at 5:19:50 AM UTC-7, bill wrote:
>>> While ISAM may be less efficient relative files can waste a
>>> lot of space. Space is allocated for empty records and back
>>> in the good ole days disk space was premium and very expensive.
>>
>> Relative files are convenient if your numbering system is already
>> not sparse.
>>
>> Otherwise, it is usually to make it a hash table, and hash the
>> index before using it to read/write a record.
>
> A hashing producing non sparse results will typical also
> produce a lot of collisions requiring collision handling.

That was not accurate described.

Any hashing requires collision handling, but hashing
producing lots of collisions requires clever collision
handling that does not kill performance.

Arne

On Thursday, September 21, 2023 at 3:13:00 PM UTC-7, Arne Vajhøj wrote:
> On 9/21/2023 1:10 PM, gah4 wrote:
> > On Thursday, September 21, 2023 at 5:19:50 AM UTC-7, bill wrote:
> >> While ISAM may be less efficient relative files can waste a
> >> lot of space. Space is allocated for empty records and back
> >> in the good ole days disk space was premium and very expensive.

> > Relative files are convenient if your numbering system is already
> > not sparse.

> > Otherwise, it is usually to make it a hash table, and hash the
> > index before using it to read/write a record.

> A hashing producing non sparse results will typical also
> produce a lot of collisions requiring collision handling.

Well, relative lets you figure it out yourself.

Especially the amount of sparseness you can live with, in exchange
for faster access. With others, the system figures it out for you.

I believe for IBM ISAM, you have to give the size when you first
create it. (Actually, that is the usual way files work in OS/360.)

There is a prime area and overflow area. It seems that it keeps some
space in the prime area for new records, but if they are not uniformly
enough spaced, then they go into the overflow area. So, not
so different from a hash table.

OS/360 disks are addressed by cylinder, track, and record within the track.
It tries to keep nearby records on the same track, or at least same cylinder.

On 9/20/2023 10:41 PM, Hein RMS van den Heuvel wrote:
> On Wednesday, September 20, 2023 at 7:33:10 PM UTC-4, Arne Vajhøj wrote:
>> On 9/20/2023 12:18 AM, Hein RMS van den Heuvel wrote:
>>> Yes indeed traditionally folks only had half a clue about RMS and vaguely know 512 was a special value and very popular.
>>>
>>> With that they proceeded to maximize their storage losses.
>
>> I could have used recl=508.
>
> Yes you could, and so could have hundreds of commercial programmers but the point is they didn't!
> They all picked 512 and proceeded to add 'filler' bytes to their record definitions 'just in case' just like you did.
>
> :-)

There are a few magic numbers 255, 512, 8192, 32767 etc. that probably
are more likely to show up than others.

If space efficiency is not important, then it does not matter.

If space efficiency is important and there is a problem, then
the problem should be investigated - and figuring it out should
not be that difficult.

And as long as they do not call VMS engineering and complain
over the "in-efficiency" then all should be fine.

But for some reason I get the impression that some people
did call VMS engineering and complained over it ...

:-)

Arne

PS: Maybe the manual should make a recommendation of record
size of multipla of 512 minus 4 (which if I understand
your description correct is what minimize unusable space).

On 9/20/2023 10:37 PM, Hein RMS van den Heuvel wrote:
> On Wednesday, September 20, 2023 at 8:07:47 PM UTC-4, Arne Vajhøj wrote:
>> A relative read is:
>>
>> calculate byte offset = record number * record length
>> read record length bytes starting at byte offset from file
>
> Noop.
> Not for RMS. Not even for fixed length record sequential files.
>
> Sequential files are conceptually divided into fixed length Multi Block Count (MBC) time 512 byte buffers.
> For shared file access the first accessor locks in the MBC. Default MBC=16 = 8KB.
> RMS will first take an integer round down to MBC to find the first MBC block to read and finds the record in there.
> It may need a second read if the records spills over the end, even if it could have just started the read later.
>
> For Relative files RMS divides the file up into buckets (default = big enough to hold 1 at least record.
> It first calculates records/bucket (RPB) integer divide of bucketsize*512 and (one (flag byte) plus Maximum Record Size).
> Next calculate VBN as 1 (File Prologue) plus integer divide of record number by RPB times RPB.
> Read BKS * 512 bytes, and locate the record.

My mistake.

VMS read blocks not bytes. And RMS use buffers.

Let me rephrase:

calculate what "chunk" on disk has the data
read that "chunk" into memory and extract data from there

Arne

On 9/19/2023 8:44 PM, Arne Vajhøj wrote:
> On 9/16/2023 4:16 PM, Arne Vajhøj wrote:
>> I don't think I have ever used ORG=REL.
>
> But then I could start now!

Cobol:

$ type relwrt.cob
identification division.
program-id.relwrt.
* environment division.
input-output section.
file-control.
select optional f assign to "rel.dat" organization is relative access
mode is dynamic relative key is recno.
* data division.
file section.
fd f.
01 myrec.
03 buf pic x(512).
working-storage section.
01 recno pic 9(9) comp.
01 i pic 9(9) comp.
01 i2 pic 9(9) display.
* procedure division.
main-paragraph.
open i-o f
perform varying i from 1 by 1 until i > 100
move i to recno
move i to i2
string "This is line #" delimited by size i2 delimited by size
"!" delimited by size into buf
write myrec
invalid key continue
not invalid key continue
end-write
end-perform
close f
stop run.
$ cob relwrt
$ link relwrt
$ run relwrt
$ type relrdseq.cob
identification division.
program-id.relrdseq.
* environment division.
input-output section.
file-control.
select f assign to "rel.dat" organization is relative access mode is
dynamic relative key is recno.
* data division.
file section.
fd f.
01 myrec.
03 buf pic x(512).
working-storage section.
01 recno pic 9(9) comp.
01 eof pic x(1) value 'N'.
* procedure division.
main-paragraph.
open i-o f
perform until eof = 'Y'
read f next
at end move 'Y' to eof
not at end display "|" buf "|"
end-read
end-perform
close f
stop run.
$ cob relrdseq
$ link relrdseq
$ run relrdseq
|This is line #000000001!|
|This is line #000000002!|
....
|This is line #000000100!|
$ type relrddir.cob
identification division.
program-id.relrddir.
* environment division.
input-output section.
file-control.
select f assign to "rel.dat" organization is relative access mode is
dynamic relative key is recno.
* data division.
file section.
fd f.
01 myrec.
03 buf pic x(512).
working-storage section.
01 recno pic 9(9) comp.
01 i pic 9(9) comp.
* procedure division.
main-paragraph.
open i-o f
perform varying i from 1 by 1 until i > 100
move i to recno
read f
invalid key continue
not invalid key display "|" buf "|"
end-read
end-perform
close f
stop run.
$ cob relrddir
$ link relrddir
$ run relrddir
|This is line #000000001!|
|This is line #000000002!|
....
|This is line #000000100!|

Arne

On 9/19/2023 8:44 PM, Arne Vajhøj wrote:
> On 9/16/2023 4:16 PM, Arne Vajhøj wrote:
>> I don't think I have ever used ORG=REL.
>
> But then I could start now!

Basic (I know some Basic ode has already been posted):

$ type relwrt.bas
program relwrt

declare integer i
map (myrec) string buf = 512

open "rel.dat" for output as file #1, organization relative variable,
recordsize 512, map myrec
for i = 1 to 100
buf = format$(i, "This is line _#####_!")
put #1, record i
next i
close #1

end program
$ bas relwrt
$ link relwrt
$ run relwrt
$ type relrdseq.bas
program relrdseq

map (myrec) string buf = 512

open "rel.dat" for input as file #1, organization relative variable,
recordsize 512, map myrec
handler eof_handler
end handler
when error use eof_handler
while 1 = 1
get #1
print "|" + trm$(buf) + "|"
next
end when
close #1

end program
$ bas relrdseq
$ link relrdseq
$ run relrdseq
|This is line # 1!|
|This is line # 2!|
....
|This is line # 100!|
$ type relrddir.bas
program relrddir

declare integer i
map (myrec) string buf = 512

open "rel.dat" for input as file #1, organization relative variable,
recordsize 512, map myrec
for i = 1 to 100
get #1, record i
print "|" + trm$(buf) + "|"
next i
close #1

end program
$ bas relrddir
$ link relrddir
$ run relrddir
|This is line # 1!|
|This is line # 2!|
....
|This is line # 100!|

Arne

On 9/19/2023 8:44 PM, Arne Vajhøj wrote:
> On 9/16/2023 4:16 PM, Arne Vajhøj wrote:
>> I don't think I have ever used ORG=REL.
>
> But then I could start now!

Macro-32 (I know some Macro-32 code has already been posted):

$ type relwrt.mar
.title relwrt
$DSCDEF
$FABDEF
$RABDEF
$RMSDEF
.psect $PDATA quad,pic,con,lcl,shr,noexe,nowrt
fnm: .ascii "rel.dat"
endfnm:
dir: .ascid "This is line #!4ZL!!"
.psect $LOCAL quad,pic,con,lcl,noshr,noexe,wrt
myfab: $FAB
fna=fnm,fns=endfnm-fnm,org=rel,rfm=var,fop=cif,mrs=512,fac=put
myrab: $RAB fab=myfab,rac=key
key: .blkl 1
buf: .ascid "This is line #nnnn!"
endbuf:
.psect $CODE quad,pic,con,lcl,shr,exe,nowrt
.entry relwrt,^m<r2>
$create fab=myfab
$connect rab=myrab
movl #1,r2
100$: $FAO_S ctrstr=dir,outlen=buf+dsc$w_length,outbuf=buf,p1=r2
movl r2,key
moval key,myrab+rab$l_kbf
movb #4,myrab+rab$b_ksz
movl buf+dsc$a_pointer,myrab+rab$l_rbf
movw buf+dsc$w_length,myrab+rab$w_rsz
$put rab=myrab
incl r2
cmpl r2,#100
bleq 100$
$disconnect rab=myrab
$close fab=myfab
ret
.end relwrt
$ mac relwrt
$ link relwrt
$ run relwrt
$ type relrdseq.mar
.title relrdseq
$DSCDEF
$FABDEF
$RABDEF
$RMSDEF
.psect $PDATA quad,pic,con,lcl,shr,noexe,nowrt
fnm: .ascii "rel.dat"
endfnm:
.psect $LOCAL quad,pic,con,lcl,noshr,noexe,wrt
myfab: $FAB fna=fnm,fns=endfnm-fnm,org=rel,rfm=var,mrs=512,fac=get
myrab: $RAB fab=myfab,rac=seq
buf: .ascid " "
endbuf:
.psect $CODE quad,pic,con,lcl,shr,exe,nowrt
.entry relrdseq,^m<r3,r4>
$open fab=myfab
$connect rab=myrab
100$: movl buf+dsc$a_pointer,myrab+rab$l_ubf
movw buf+dsc$w_length,myrab+rab$w_usz
incl myrab+rab$l_ubf
decw myrab+rab$w_usz
$get rab=myrab
cmpl r0,#RMS$_NORMAL
bneq 200$
movl buf+dsc$a_pointer,r3
movb #124,(r3)
addw2 myrab+rab$w_rsz,r3
movb #124,(r3)
movw buf+dsc$w_length,r4
addw3 #2,myrab+rab$w_rsz,buf+dsc$w_length
pushab buf
calls #1,G^LIB$PUT_OUTPUT
movw r4,buf+dsc$w_length
brb 100$
200$: $disconnect rab=myrab
$close fab=myfab
ret
.end relrdseq
$ mac relrdseq
$ link relrdseq
$ run relrdseq
|This is line #0001|
|This is line #0002|
....
|This is line #0100|
$ type relrddir.mar
.title relrddir
$DSCDEF
$FABDEF
$RABDEF
$RMSDEF
.psect $PDATA quad,pic,con,lcl,shr,noexe,nowrt
fnm: .ascii "rel.dat"
endfnm:
.psect $LOCAL quad,pic,con,lcl,noshr,noexe,wrt
myfab: $FAB fna=fnm,fns=endfnm-fnm,org=rel,rfm=var,mrs=512,fac=get
myrab: $RAB fab=myfab,rac=key
key: .blkl 1
buf: .ascid " "
endbuf:
.psect $CODE quad,pic,con,lcl,shr,exe,nowrt
.entry relrddir,^m<r2,r3,r4>
$open fab=myfab
$connect rab=myrab
movl #1,r2
100$: movl r2,key
moval key,myrab+rab$l_kbf
movb #4,myrab+rab$b_ksz
movl buf+dsc$a_pointer,myrab+rab$l_ubf
movw buf+dsc$w_length,myrab+rab$w_usz
incl myrab+rab$l_ubf
decw myrab+rab$w_usz
$get rab=myrab
movl buf+dsc$a_pointer,r3
movb #124,(r3)
addw2 myrab+rab$w_rsz,r3
movb #124,(r3)
movw buf+dsc$w_length,r4
addw3 #2,myrab+rab$w_rsz,buf+dsc$w_length
pushab buf
calls #1,G^LIB$PUT_OUTPUT
movw r4,buf+dsc$w_length
incl r2
cmpl r2,#100
bleq 100$
$disconnect rab=myrab
$close fab=myfab
ret
.end relrddir
$ mac relrddir
$ link relrddir
$ run relrddir
|This is line #0001|
|This is line #0002|
....
|This is line #0100|

Arne

On 9/20/2023 7:15 AM, Arne Vajhøj wrote:
> On 9/20/2023 12:02 AM, Dave Froble wrote:
>> On 9/19/2023 8:50 PM, Arne Vajhøj wrote:
>>> On 9/19/2023 8:44 PM, Arne Vajhøj wrote:
>>>> On 9/16/2023 4:16 PM, Arne Vajhøj wrote:
>>>>> I don't think I have ever used ORG=REL.
>>>>
>>>> But then I could start now!
>>>
>>> C / RMS:
>>
>> Is it just me, or, was my Basic example shorter and easier to read
>> than your Cobol, Fortran, and C examples?
>
> The Basic code was a bit shorter than the Fortran and Pascal code.
> No so surprising VMS Basic is pretty good in expressing logic
> in few lines.
>
> The Basic code was a lot shorter than the C code, because
> that was using RMS calls and not language specific statement -
> working with RMS Calls and FAB & RAB blocks always require
> way more code than language specific statements.

The stats for my code:

Fortran: 13 + 11 + 12 = 36
Basic: 13 + 16 + 13 = 42
Pascal: 23 + 22 + 22 = 67
Cobol: 32 + 28 + 29 = 89
Macro-32: 34 + 38 + 43 = 115
C: 57 + 55 + 57 = 169

Obviously the result depends a little on coding style - and
mine is just mine.

Arne