On 2016-11-11, at 08:52, Steve Thompson wrote:
>
> But, might I suggest that you do the member name in lower case? That way, you
> can see it, and I think ISPF will allow you to view/edit it if you need to
> while fixing a problem if your JOB fails for any reason.
>
Ah, but what if the original member name already *is* in lower case?
I don't think your recovery scheme is very useful. In case of such a
failure, the job might as well be started anew.
> On 11/11/2016 07:58 AM, John McKown wrote:
>>
>>
>> ... Now, do an OPEN on _two_ different DCBs for the
>> DD. First OPEN a DCB for _input_. Then OPEN a second DCB for _output_. When
>> you OPEN a member of a PDS for _output_, the access method always positions
>> to write at the end of the PDS, into "unused" space. You can now read
>> records from the INPUT DCB and write them immediately to the OUTPUT DCB. At
>> EOF on the input DCB, close the input DCB. Continue writing the new
>> information to the output DCB. Finally, close the output DCB. This will do
>> a STOW ...
>>
Note the paradigm: the access method actually writes to an anonymous
member and only creates/replaces the directory entry at CLOSE/STOW.
Is it possible to change the output member name immediately before
the CLOSE/STOW so the original member is left intact before completion.
Where is the member name kept while the DCB is open?
ISPF Library Management Services support this nicely. Paradigm
LMINIT
LMOPEN
LMPUT; ...
LMCLOSE MEMBER( ... )
LMFREE
Notice that the member name is specified only on LMCLOSE, not on LMOPEN.
(Silly restriction: it's impossible to create an empty member this way.
There must be at least one LMPUT. Why?)
PDSE supports writing multiple members concurrently. I believe multiple
DCBs are always required for this. ISPF supports this with a sequence
similar to above. I don't recall whether it works with a single DDNAME.
I wish Rexx supported a similar process: defer supplying the menber
name until DISKW (FINIS). And that for performance Rexx supported
manipulating multiple members with a single OPEN.
UNIX temporary files are open()ed then immediately unlinked so there
is no residue on abnormal termination. Alas, there's no way to open()
a file creating an inode but never a directory entry to close the
minuscule timing window in the existing process.
All the PDS(E) schemes don't really append to a member; they copy it
and add some records. Consider using UNIX directory files instead of
the archaic PDS(E) members. You can truly append to UNIX files.
-- gil
