topic Re: Relative record access from DCL in Operating System - OpenVMS

Relative record access from DCL

Stephen Eickhoff_1 — Thu, 16 Aug 2007 14:48:47 GMT

In DCL, is it possible to access a specific record in an indexed file by RFA or record number, as opposed to reading every previous record sequentially?

Re: Relative record access from DCL

Hoff — Thu, 16 Aug 2007 15:23:17 GMT

DCL provides access into an RMS indexed file -- the title references "relative", and that's a different organization, though the text references indexed -- by record key, if that is what you mean.

This in addition to sequential access, or in combination with sequential access. You can, for instance, locate a record by key and then process subsequent records sequentially.

For details, look at the qualifiers /KEY and /INDEX and /MATCH available on the DCL command READ.

RMS doesn't have a record number concept with indexed files. (Though you could easily create and populate a key containing your own record number, and access records via that key directly.)

There's no easy way I'm aware of to do an RFA-based record access from within DCL.

Can't say I've ever tried to use a relative file strictly with DCL only (or know if anything other than sequential READ access works with a relative file); I generally go right to the indexed file organization for that task.

Re: Relative record access from DCL

Hein van den Heuvel — Thu, 16 Aug 2007 16:35:00 GMT

Sequential access to Relative files from DCL fully works.

Random access to Relative files (and Fixed length sequential files) is documented NOT to work, but actually easily works for just about all key values.
That is all but about 1 in 255 values.
Why? Because any byte value of %x22 in the binary key is special and requires you to fudge the key to an unnatural length doublequoting the double-quote.
(It works 100% for less than 30 records, but only 97% for 34 records, 99.65% of the time for 290 record :-)

$ conv/fdl="file; org rel; record; size 50; format fixed"/pad/trun tt: rel.tmp
aap
noot
mies
$ key="1234" ! Reserve 4 bytes
$ open/read rel rel.tmp
$ key[0,32]=2
$ read/key=&key rel record
$ show symb record
RECORD = "noot.............................................."
$ key[0,32]=5 ! Does not exist.
$ read/key=&key rel record
%RMS-E-RNF, record not found
$ close rel

I have recently added a request to DCL/RMS to somehow give us binary key value access.

Enjoy,
Hein.

Re: Relative record access from DCL

Hein van den Heuvel — Thu, 16 Aug 2007 16:48:34 GMT

And here is a proof you can get to all records:

$ perl -le "print for 1001..1050" > tmp.seq
$ conv/fdl="file; org rel; record; size 50; format fixed"/pad/trun tmp.seq tmp.rel
$ open rel tmp.rel
$ key="1234"
$ key[0,32]=33
$ read/key=&key rel record
$ show symb record
RECORD = "1033.............................................."
$ read rel record
$ show symb record
RECORD = "1034.............................................."
$ key[0,32]=34
$ read/key=&key rel record
%RMS-F-KSZ, invalid key size for $GET/$FIND
$ show symb key
KEY = ""..."
$ key[00,24]=%x222222
$ key[24,24]=0
$ show symb key
KEY = """"..."
$ read/key=&key rel record
$ show symb record
RECORD = "1034.............................................."

Not pretty huh?

Here is a proof that for example DELETE works for relative files:

$ open/read/write rel tmp.rel
$ read/DELETE/key=&key rel record
$ $ key[0,32]=1
$ read/key=&key rel record
$ show sym record
RECORD = "1001.............................................."
$ read rel record
$ show sym record
RECORD = "1002.............................................."
$ read rel record
$ show sym record
RECORD = "1004.............................................."

Finally, the big difference between relative files and indexed files with a record number as key is that for indexed files the record number must be part of teh record. For relative files is it a magic number on the side which does not exist. In fact when you convert a relative file with convert the records are re-numbered! That makes changing bucket sizes for relative tricky.

Hein