On 8/09/2012 1:49 AM, Bob Shannon wrote: > Since the format of PDSEs has never been published, and since directory space > can be created when needed in non-contiguous areas, I seriously doubt ISPF can read the directory as a PS data set.
Well, if reading the directory with QSAM or BSAM counts, then why not? The REVIEW command can be used with the DATA operand to browse the directory of a PDS or PDSE. It uses BSAM so the "hardware" keys can be seen as well. You could then use the CUT subcommand to copy it to a data set if that was your fancy. For a PDSE end-of-file is presented right after the last used directory block, whereas for a PDS the unused directory blocks can also be read before reaching end-of-file. Time was when the first QSAM GET to a PDSE directory returned a buffer of mainly zeros, but the second GET gave access to the first (mocked up by the system) directory block. That was fixed a decade or two ago. So, if ISPF reads the directory sequentially (and I do not know if it does or not, though SMF 14/15 records might give a clue) it could acquire all of the ISPF stats and "usual" load module attributes for PDS and PDSE members. Of course, DESERV does give extra "directory entry" information for program objects which are not present in the data structure described by the IHAPDS macro. OTOH, I agree that ISPF would not directly access the 4K blocks on the tracks occupied by a PDSE and figure out the stats and facts using logic which decodes the internal PDSE data structures. Cheers, Greg Price ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
