IBM Mainframe Forum

I wrote a generic file read routine in assembler some time ago, and I am looking now to add support for RRDS files. (It currently supports QSAM, PDS and VSAM KSDS or ESDS files). Once, a long, long, long time ago, I read an RRDS in a COBOL program, but I have never tried to access an RRDS from an assembler program. There does not seem to be a lot of information available about using an RRDS in batch Assembler (probably because it is not a common need). I am not sure what to specify for the MACRF values, or if an RRN is required even if I am just reading sequentially. Any direction would be appreciated (and, of course, an actual example would be ideal). Thanks.

If ESDS's are analogues of sequential files and KSDS's are the equivalent of ISAM, then RRDS's are VSAM's answer to BDAM. They may be fast, but that is about their only advantage, and these days with modern systems even that is debatable.The dataset has to be formatted with a fixed number of slots, and you need a hashing algorithm that is specific to the individual implementation.

So you use the hashing algorithm to identify which slot you need to access based on some key, and then fetch the record. You then update it; multiple keys can hash to the same slot, and if there isn't enough room in the slot, you need to implement some kind of overflow mechanism where you chain the record to some vacant slots specially reserved for the purpose.

I wrote a program that did this about 25 years back, as an advanced module of an assembler course. Based on that experience, I have never used it since.

I think you may be out of luck if you want to extend your generic file routine; the details of individual RRDS implementations are all different. If you have ever used Xpediter, you will appreciate how touchy it is about the DDIO file, and how you have to use only the vendor supplied utilties to do anything with it.

Just my $0.02 worth...

Never being one to simply roll over and admit defeat, I think I have this working now. The answers to my original questions are:

1) the OPTCD for reading the RRDS are KEY,SEQ (There are other choices, such as skip sequential, but the important one is apparently KEY.)

2) Yes, a 4-byte variable to store the relative record read is required as an ARG on the RPL (even if just reading). I suppose this is because, unlike a key for a KSDS, the identifiying value is external to the record itself.

And, interestingly, my test for reading a file is an Xpediter DDIO file. It appears to work like a charm (not that the contents of the DDIO file are particularly intelligible).

I suspect you could read it as though it were a sequential dataset, which I have done for KSDS datasets. Since I did not have an RRDS to test it with I decided to keep silent. Thank you for telling us your solution.

not that the contents of the DDIO file are particularly intelligible

That was the point I was trying to make; because the internal structure of the file is unique to each implementation (e.g. how does Xpediter chain all of its records together to store a listing when they are too big to fit in a single slot?) it is quite hard to produce a generic solution. You'd get the same issue reading DB2 table spaces natively as linear datasets - although sthe tructure of these is documented, unless you work for BMC you probably don't need to go down that path.

Glad to see you got it working though.

The intention of my ALC routines is to allow flexible IO for various utilities written in COBOL. In other words, it allows a way around one of the chief remaining limitations of COBOL, which wants to know all of the details for every file it handles. (We are in the process of converting as much of our ALC to COBOL as possible. Yes, it is mostly a pointless project, but I wasn't the one who made the decision.) So, my routines really only need to obtain the records and make them available to the CALLing program. What to do with them after that is for them to deal with. (And for writing, it takes the record and makes sure that it gets into the file, but again, what it really contains is not my problem.)

And yes, I read all of the formats, but only sequentially. If I needed to add some kind of support for direct access, I could, but that has not been a requirement thus far.

Cobol supports rrds already. If you want to write it in assembler shouldn't be that bad. I would disagree about having to have a hash. I have used a rrds file like a linear sequentional type file where each record held that I was working on. It is true that the rrds file is formatted ahead of time (or should be by you if you don't want to wait around for the next cylinder (excuse me, control area) to be formatted. My process was to, at open, read from my last checkpoint to the next free record at system start then update my checkpoint value leaving the the file open and ready to go. (when I say checkpoint, it was mine, not a system type checkpoint).