MVS allows multiple PDS datasets to be concatenated and opened for input. This results in a DEB with extents for every dataset in the concatenation. To make this happen the DCB must have DSORG=PO specified (not DSORG=PS).
Below is a dump of a DEB created for concatenated PDS datasets.
0000 00AF1078 02AFD610 69000000 00001100 ......O......... 0010 05000000 FF000000 8F095BC0 04AFDE88 ..........$....H 0020 50001E68 00000178 00000178 001D001E &............... 0030 50001E68 00000179 00000179 001D001E &............... 0040 50001E68 00000176 00000176 001D001E &............... 0050 50001E68 00000177 00000177 001D001E &............... 0060 50001E68 00000175 00000175 001D001E &............... 0070 02040000 00000000 00000000 00000000 ................
There are three datasets concatenated here. The first has two extents, the second has two extents and the third has a single extent. The first thing we need to check is a bit that is not documented in the IEZDEB mapping macro. We need to see if bit 7 (x’01’) is on in the DEBOFLGS field located at offset +08. If this bit is set to one then we know we have concatenated datasets.
Next we need to locate the pointers to the beginning extent for each dataset. The are located immediately following the last extent description in the DEB. The DEBAMLNG field (one byte located at offset +4) indicates how many pointers there are. There will be one less than the number of datasets concatenated. The pointer to the first dataset is not included because it is always the first extent.
We can locate the pointers by using the DEBNMEXT field (one byte located at offset +16 [x’10’]) which contains the total number of extents.
In this example we see that the second dataset begins with extent number 2 (relative to zero – or the 3rd extent) and the third dataset begins with extent number 4 (relative to zero – or the 5th extent).
Each PDS directory is located at the beginning of the extent for the dataset. It is important to remember the TTR pointers in the directory blocks are relative to the beginning of the dataset. The TTR to MBBCCHHR conversion must take the concatenation number into account when calculating the physical address from a TTR pointer.
I have not written any example code but if you understand the basics of reading a PDS member it should not be too difficult to read from concatenated PDS datasets.
In MVS 3.8j, must a concatenation of PDSs have the PDS with the largest block size positioned first in the concatenation unless a BLKSIZE parameter is specified explicitly accomodating the largest block size in the concatenation?
Yes, that would be true since the access methods BSAM/QSAM use the block size of the first data set in the concatenation to allocate the I/O buffers. Of course for EXCP this does not have to be a requirement since the programmer writing the EXCP code can determine the I/O buffer size any way they desire. For example if you are only using 3350 DASD a buffer size of 19069 would work for any data set. The problem with doing something like this is that if you move the code to a different device type it may break.