Dumb question: While you're doing this random access, is there any data at the points you're trying to access? Most, though perhaps not all, random access dataset have data pre-loaded, or at least the areas being accesses are pre-formatted. We need more information about what you're trying to accomplish before we can even postulate a theory about your problem. Why multi-volume? Why temporary? How is it being used?
It's multi-volume because it's very large. We need to have datasets that are more than 4GB. We use EXCP to access the datasets for performance reasons.
The datasets we process can be temporary and they can be permanent. Temporary ones are used for "work" storage for intermediate results and then permanent datasets are updated.
The dataset is not preloaded, it often starts empty and then grows with random reads/writes, and is often temporary so chucked away again. We track the size (high water mark) of the datasets and as data is written to it use either an update record or a format record channel command appropriately to write the data to the datasets (the data is not "sparse" -- the dataset is expanded sequentially). When necessary we issue an EOV macro to expand the dataset when we need to write beyond the end of the current extent. In the case of multivolume dataset this may result in the new extent being created in a different volume. We keep a seperate DCB for each volume in the multi volume dataset. When the EOV causes a shift to a new volume, the DCB now relates to that new volume so we update our list accordingly. So in the case of the temporary datasets they start out empty and then as the processing runs the temporary dataset gets filled up, potentially expanding to multiple volumes as necessary.
So lets say we want to write data to a given byte offset (an "RBA" if you like). We translate the RBA into a volume sequence number and a TTTR and then check to see if we've currently got the relevant DCB open. If not then we open is using the RDJFCB/OPEN TYPE=J method specifying the volume sequence number in the JFCB. At this point I check whether the volume serial numbers of the UCBs associated with each extent match what I would expect given the information in the list of volume serial numbers in the JFCB, and this is where I detect that the wrong volume is sometimes opened. Having made sure that we've got the right DCB for the volume we then translate the TTTR into an MBBCCHHR in that dataset and write the relevant block using a write update record or format track channel program. The program only ever reads and writes a block (hardware record) at a time, so there's no concern about having to update partial records and that kind of thing.
So that's the basic scenario. If you're familar with SAS, then think MXG processing. The SMF data is read in and many large datasets are created in the WORK library (which is temporary). The WORK library can be many GB in size. WORK libraries are temporary. What we're doing is equivalent to SAS data libraries. Identical in fact as we write a SAS clone.
It all works swimmingly (and btw, a lot faster than any other I/O method we've tried -- C runtime library, BSAM, VSAM of all flavours -- of which only VSAM can cope with the volumes we need), apart from the OPEN TYPE=J not always seeming to open the correct volume in the case when the dataset is DISP=NEW, or indeed DISP=MOD. If it's DISP=OLD, it (appears) to work correctly.
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
