It's not just an EDIT SAVE that could cause grief with the batch
process, but any similarly exposed batch process that updates the PDS
with DISP=SHR. If you start using a batch process with the exposure and
it gets cloned to 20 other batch jobs, they all become potential
problems to each other. If you have a batch job that writes a
sequential file to a new PDS member with DISP=SHR that has never failed
before, it can potentially interact badly with any other batch job using
SHR updates to the same PDS and cause an ABEND. The first of these
things running when ISPF activity may be low or non-existent may not be
a problem, but one of the many corollaries to Murphy's Law is that usage
of questionable techniques tends to expand until the failure window does
become noticeable.
If you can keep suitably tight rein on usage times and frequency of a
questionable technique, you may be able to keep failures at an
acceptably low level, perhaps even for years. So I would not go so far
as to say one should never use such techniques; but keep in mind that if
usage increases they scale badly, and problems with a job stream may
cause a job using such techniques to run at an unusual time when there
may be a much higher conflict potential.
Joel C. Ewing
On 10/03/2013 04:31 PM, Bass, Walter W wrote:
> Ah - OK. Somewhere back in the mists of time I was once aware that the Edit
> SAVE only enqueued the PDS momentarily, but I failed to recall that fact when
> needed.
>
> So the abend concern is only if the ISPF Edit SAVE occurred at the same
> "instant" as the batch delete. A small but admittedly not impossible window
> of opportunity and according to Murphy, it would occur at the least
> convenient time.
>
> Thanks for clarifying the issue.
>
> Bill Bass
> United Healthcare
> Greenville SC
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]] On
> Behalf Of Joel C. Ewing
> Sent: Thursday, October 03, 2013 4:04 PM
> To: [email protected]
> Subject: Re: Standard TSO/MVS way to delete a PDS(E) member
>
> On 10/03/2013 02:52 PM, Paul Gilmartin wrote:
>> On Thu, 3 Oct 2013 12:11:55 -0500, Joel C. Ewing wrote:
>>>
>>> To test this properly requires either extraordinary timing ability, or
>>> getting a program which will OPEN a PDS for output without the
>>> appropriate ISPFEDIT enqueue and keep it open for long enough, say 10 to
>>> 30 seconds, from a batch job or a 2nd TSO session with DISP=SHR to the
>>> PDS, and while this is running with the dataset open for OUTPUT then
>>> trying other activity from batch or ISPF that requires an OPEN for
>>> OUTPUT to update the PDS while using SHR access at PDS allocation. I
>>> have done those tests in the past and have also run traces on the
>>> ENQ/DEQ requests issued while starting and terminating ISPF edit
>>> sessions to be sure I understood what was going on.
>>>
>> To expose this, you might try in batch Rexx (schematic; untested):
>>
>> RC = BPXWDYN( 'alloc rtddn(VAR) shr dsn(DATA.SET(MEMBER)) ...' )
>> address MVS 'EXECIO 0 DISKW' VAR '(open'
>> address SYSCALL 'sleep 30' /* or more, to taste. */
>> address MVS 'EXECIO 0 DISKW' VAR '(finis'
>> RC = BPXWDYN( 'free dd('VAR') ...' )
>>
>> ... and while that runs, try editing a member and saving it, or try your
>> DELETE program.
>>
>> -- gil
> Right. And it's irrelevant whether the sleeping task and the other task
> are attempting to reference the same or different members, it's the 2nd
> concurrent open-for-output attempt on the same PDS that causes the problem.
>
>
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
