I've been going around and around all day with trying to make my CICS program update a record on an ESDS file. Essentially, I'm trying to sequentially read an ESDS log file, use it to post a transaction and then I want to flag the record to indicate that I've posted it.
ADD WS-LOGREC-LENGTH TO WS-CUR-LOG-RBA
GO BACK UP TO STARTBR...
Please note, that I am NOT a CICS programmer. Everything up there is basically what I was able to garner from my friend Mr. Google... So, I'm fully aware that it may be bogus...
Essentially, after my rewrite, I'm adding the length of the record to my RBA so that I know where to find the next one (The records are all fixed 100 byte records).
Anyway, this actually almost works. The problem came when the RBA got past an address of 32600. At that point, it appears that somehow an additional 68 bytes was added to the address. So, instead of address 32700 following 32600, the next address was 32768.
RBA OF RECORD - 32600
000000 F0F0F0F0 F0F0F0F0 F0F0F0F
000020 F0F0F0F0 F0F0F0F0 F0F0F0F
000040 F0F0F0F0 F0F0F0F0 F0F0F0F
This happened again 36000 bytes later - another 68 bytes popped into the file.
RBA OF RECORD - 65268
RBA OF RECORD - 65368
RBA OF RECORD - 65536
It was very consistent. So, I added code to add the 68 bytes to the RBA after every 326 records. It all worked.
My question is... Is this a good idea? Can that 68 bytes of padding always be counted on to be there after every 32k of data? Or, should I come up with a plan B? Is there a better way to keep track of the RBA of my next record when I want to read and rewrite the previous one?
Any suggestions that you have will be sincerely appreciated.
Joined: 06 Jun 2008 Posts: 8438 Location: Dubuque, Iowa, USA
What is the definition of the ESDS data set? I suspect you've got a CI size of 32768 (32K); 327 records of 100 bytes will fill the CI with 68 bytes unused at the end of the CI. This is not really a CICS issue but rather how VSAM works.
Actually, let me make one follow-up question now that my "mystery" 68 bytes has been resolved.
Is there a better way for me to handle this scenario than what I've selected (startbr, readnext, endbr, read, rewrite, increment RBA, rinse, repeat)? It seems that my having to calculate the RBA on the fly to be able to read each subsequent record is kind of shaky. That's especially true if I'm depending on the CISIZE to always be constant - the next guy that comes along to tune that file will break my program.
If I were to be able to make this a KSDS file, most of my problems would be able to go away because I'd be able to use GTEQ on the read. But, unfortunately, that is not an option for us.
Also, you shouldn't need to maintain the RBA in the browse yourself, unless you have a specific requirement to break the sequence. The RBA is maintained for you, in that field. If you leave it alone, all should be well. Only change it if you want to do something "out of sequence" and if you do change it, only ever change it to an RBA that is known to be of a record.
I start to read sequentially at the beginning of the ESDS file (RBA = 0) with a startbr and readnext.
After I endbr and rewrite to the file, however, my original readnext has lost its place. Hasn't it? I have to go back to the startbr with the address of the next record on file (which I haven't read yet). At least, that's what seemed to be happening to me when I was testing it. It all started working when I added the record length to the RBA before looping back to my original startbr again.
It's probable that my thinking is hosed here.... But, how else do I get the next RBA so that I can re-start my next browse? If I don't bump it up, the next startbr will just re-read the record that I just finished processing. Won't it?