On Mon, 14 Nov 2016 00:58:00 +0000, David W Noon wrote: > >The problem with writing directly to the PDS is that a single DCB can >maintain only 1 position for reading or writing -- and that's exclusive >or. Opening a second DCB presents problems I'll address below. > Much as I said last week. We're in strong agreement here:
On Sat, 12 Nov 2016 12:53:40 -0600, Paul Gilmartin wrote: >In a recent thread in ASSEMBLER_LIST, the OP asks if it's possible >to append to a PDS(E) member. No, because the architecture of >PDS makes this prohibitively difficult. Likewise, concurrent writing >to multiple PDS members is prohibited because of that architecture. (DWN:) >If you wish, but I have known programmers who have had 2 or more DCB's >open for output/update on a single PDS. They thought it was safe because >they used separate DDNAMEs. > That's their problem; they didn't follow the instructions. PDSE supports concurrent writing to multiple members. Multiple DCBs are required in order to separate the output streams. >But the problem arises when the output DCB expands the dataset into >previously unused space, without the input DCB(s) being notified of the >expansion. The members stowed by the output DCB will have TTR addresses >beyond the original DS1LSTAR and will cause addressing errors on FIND or >POINT macros on the input DCB(s). > Indeed. There's strong counsel against using secondary extents on shared libraries; particularly load module libraries. I don't know how well PDSE addresses tnis; I don't even know how meaningful a DEB is for a PDSE which I understand does the physical I/O in the PDSE address space. >> z/OS DFSMS Using Data Sets >> >> When a PDSE member is updated or replaced, it is written in the first >> available space. This is either at the end of the data set or in a space >> in the middle of the data set marked for reuse. This space need not be >> contiguous. ... > >I can believe this of a load module PDSE, because the physical records >are all the same size: 4096 bytes. > All physical blocks in all PDSEs, program objects or data, are 4096 bytes long. DCBBLKSI for a PDSE is a fiction, preserved for compatibility. >For more general data, what happens when the physical record is too >large for the first available space? Can a physical record be >discontiguous? I find it difficult to contemplate a physical record >being split up and spread across different parts of the dataset. How >would such a record be addressed as a TTR? > Agreed. Splitting a physical record is a contradiction in terms. But former DASD models (3350? 3330?) faked it with a "track overflow" feature. But nonadjacent (I'll avoid "discontiguous") blocks are routine within a classic PDS member. It can happen if exhausting an extent while writing a member causes secondary allocation. The secondary extent is likely not to be adjacent. The TTRs used by BPAM are not physical disk addresses. >To offer a suggestion for the above: if IBM switched all PDSE (i.e. not >just load module PDSE) processing to paging, it would require a quite >thick abstraction layer ... > In this century such things are done routinely. Physical storage is an array of FBA disks which the controller maps into old-fashioned CKD drives which PDSE uses to somewhat simulate another layer of FBA storage with 4KiB "pages" which it uses to simulate CKD again for BPAM. Somehow, it all works. >... This >abstraction layer could pose a performance drain on BPAM applications. > And the hardware technology is so improved that it outperforms the simpler architecture of a few decades ago. Customers suggest removing abstraction layers. IBM resists this because of the implementation resource required and because removing the abstraction would lead to incompatibilities at the application layer. >My take on BPAM for PDSE is that when space is not available to satisfy >any given write operation, an exclusive ENQ allows the access method to >do a compression (whole or partial) to make space available. This allows >the physical records to remain intact and for the I/O operations to >transfer any physical record as a single block of data from disk. > Much of the PDSE architecture remains undisclosed, but the organization into 4KiB pages is clearly documented. And a logical record larger than 4KiB must occupy multiple pages. I don't know that it's disclosed whether PDSE performs concurrent reorganization to improve performance. And whatever it does is subject to change. >As an example, here is a program I wrote more than 30 years ago: > ><http://www.cbttape.org/ftp/cbt/CBT090.zip> > >I have not updated it to process PDSE load libraries because I did not >think it was possible to use BPAM to read a PDSE load module. > I believe it is not and that you must use Program Management interfaces. I believe AMBLIST and AMASPZAP and probably IEBCOPY do so. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
