On Sat, 12 Nov 2016 19:48:05 -0600, Paul Gilmartin (0000000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: BPAM" (in <1151053499262553.wa.paulgboulderaim....@listserv.ua.edu>):
> On Sun, 13 Nov 2016 00:20:44 +0000, David W Noon wrote: >>>> >>>> The traditional way to do this was to use a spill file, thus: [snip] > Eventually, that spill file is written back to the PDS, incurring exactly > the same BPAM overhead as if the extended member were written > directly to the target PDS. To that add the overhead of writing and > reading the spil file. That technique loses. 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. >> Having 2 or more DCB's open on the same PDS was a recipe for data >> corruption when at least 1 was opened for output. This is because BPAM >> uses the DS1LSTAR field of the format-1 DSCB to determine end-of-data at >> open time, but any DCB that writes to the PDS will move the end-of-data >> address without updating the DSCB and without notifying any other DCB >> operating on the same PDS. The format-1 was finally updated during the >> CLOSE macro. >> > You're trying to distract me with "at least". I agreed earlier in this thread > that no more than one PDS member can be written at a time. Let's > agree on not "at least" but "exactly". 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. > And the reads cause no interference. Surely no read updates DS1LSTAR, > and even FIND doesn't rely on DS1LSTAR; it gets TTR from the directory > entry. 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). [snip] >> A member cannot be in discontiguous space. Thus, a member that occurs >> early in the seek addresses of a PDS cannot receive additional space on >> the end of the dataset. >> >>> I strongly doubt that PDSE stores the pages of a member contiguously, >>> which you seem to assume is the reason for the restriction. >> >> I would not be too certain about that. BPAM still has to support NOTE >> and POINT macros for random access, and these assume that each member is >> in contiguous disk space so that the seek addresses are sequential. >> > And here you are "not too certain" of what IBM directly states: > z/OS 2.2.0 > z/OS DFSMS > z/OS DFSMS Using Data Sets > Non-VSAM Access to Data Sets and UNIX Files > Processing a Partitioned Data Set Extended (PDSE) > Structure of a PDSE > Reuse of Space > > 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. 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? >> To change that would require a major re-architecture of both BPAM and >> BSAM as regards NOTE and POINT processing. This would have to be >> transparent to older code that has used NOTE and POINT for decades. It >> might be possible, but it would be a serious challenge. [snip] 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 to map TTR addresses used by BPAM applications into RBA for accessing a VSAM linear dataset in control interval mode, which is the way to access an LDS when not memory mapped for DIV. The reason this abstraction would be so thick would be to map any physical record into potentially discontiguous pages. There is also the problem of BPAM physical records not fitting neatly into pages; this raises the potential for record "tails" to be in pages on their own or packed into pages with parts of other physical records, possibly with those other physical records belonging to other members of the PDSE. This abstraction layer could pose a performance drain on BPAM applications. 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. I think I should make the point that load module PDSE libraries are quite distinct entities from general data PDSE libraries; they are almost separate species. I have not tried reading a load module PDSE using BPAM because I am not sure it is even supported; only the API for program objects is supported -- but I might be a bit pessimistic here. 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. >> One possibility is that LMMREP does not perform an OPEN; it expects to >> have an already opened DCB in the TSO address space and for that some >> previous operation that will open a DCB is necessary. >> > Apologies; I trimmed too much. LMMREP requires prior LMPUT which > requires a prior LMOPEN. But why is LMPUT required? I hope not > merely to indirectly require the LMOPEN. As I wrote before, you should address that question to IBM. My paragraph above was merely a personal speculation. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
