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
