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:
>>>
>> (But you use the past tense. Is there a better way now?)
>
>I don't think there is a new way specific to PDSE libraries.
>
>>> OPEN (PDS,INPUT),(SPILL,OUTPUT)
>>> FIND PDS,<member>
>>>
>>> loop:
>>> READ PDS
>>> WRITE SPILL
>>>
>>> end loop:
>>> WRITE SPILL with additional records
>>>
>> Why was it not traditional at this point simply to:
>> STOW SPILL,<member>,R
>
>The spill file was usually a sequential dataset on a scratch unit,
>typically VIO. There was no need for the overheads of BPAM (directory
>management, etc.).
>
>>> CLOSE PDS,SPILL
>>> <snip>
>>>
>> ... and avoid the remaining code?
>
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.
>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".
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.
>>> This would not facilitate the appending of data to an existing member.
>>> The serialization mechanism would not provide additional space to hold
>>> additional records within a member.
>>>
>> That's what secondary extents are for.
>
>Not so.
>
>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. ...
>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.
>
IBM took up that challenge and largely succeeded. There have been bugs.
(concerning using LMMREP to create empty members):
>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.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
