You do not fully understand what is going on under the covers in ISPF.
The specific SPFEDIT enqueue to which I referred is not used when
interactively editing a member in ISPF but at the instant in time the
member is saved, which is the only point during editing where ISPF opens
the PDS for output. ISPF uses a different member-specific enqueue to
block multiple edit sessions on the same member. This is not the same
as the dataset-level SPFEDIT engueue used when preparing to update the
actual dataset. ISPF also uses these same dataset-level enqueue
conventions in all other non-editor ISPF functions that require opening
a PDS for OUTPUT, and some MVS utilities have been modified over the
years to also use SPFEDIT enqueue conventions.
To save a member or delete a member from either ISPF or batch requires
writing to the PDS and that the PDS be opened at least briefly for
output. The ABEND 213-30 is enforced by MVS to prevent two such opens
from happening at the same time and has nothing to do with whether that
OPEN request comes from ISPF or batch or some other address space.
This ABEND can be totally avoided by either requesting exclusive access
to the dataset at allocation time (JCL or dynamic), or by having all
applications, batch or otherwise, that use SHR access follow ISPF-style
exclusive enqueues on the dataset level before attempting the action
that requires opening the PDS for output.
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.
I do not know whether the latest incarnation of IDCAMS DELETE does or
does not do SPFEDIT-style enqueues when doing member deletes, but if it
does not, doing this with only DISP=SHR access to the PDS has the
described failure potential.
The window for failure may not be large, but can be made much larger if
there are applications using SHR access that write very large members to
the PDS, or applications that hold the PDS dataset open for output while
performing other lengthy actions. Based on personal experience, even a
small window will eventually produce failures, not necessarily at a
convenient time.
Joel C Ewing
On 10/03/2013 09:46 AM, Bass, Walter W wrote:
> I fail to see why you would expect an abend if the member was being edited in
> ISPF when it was deleted in batch. My expectation was that the batch delete
> would work fine and that user performing the ISPF edit would not notice any
> impact.
>
> I would expect the following to happen:
> 1) The member would be successfully deleted.
> 2) If the ISPF EDIT session ended WITHOUT performing a SAVE after the delete
> had occurred, the member would remain deleted.
> 3) If the ISPF EDIT session ended WITH performing a SAVE after the delete had
> occurred, the member would be re-added and would exist.
>
> Because this was my expectation and I seemed easy enough to test, I did so.
> The results were exactly as described above.
>
> Bill Bass
> United Healthcare
> Greenville, SC
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]] On
> Behalf Of Joel C. Ewing
> Sent: Wednesday, October 02, 2013 11:12 PM
> To: [email protected]
> Subject: Re: Standard TSO/MVS way to delete a PDS(E) member
>
> On 10/02/2013 01:06 PM, Mark Zelden wrote:
>> On Wed, 2 Oct 2013 11:47:44 -0500, Kirk Wolf <[email protected]> wrote:
>>
>>> Mark,
>>>
>>> I'm curious - if the PDS is allocated with DISP=SHR, will IDCAMS use ISPF
>>> compatible ENQs to serialize the member when deleting?
>>>
>>> Kirk Wolf
>>> Dovetailed Technologies
>>> http://dovetail.com
>>>
>>
>>
>> In a word, no. But this is a problem all over the OS with various
>> utilities. If
>> the scenario you want to use IDCAMS w/SHR for deleting a PDS member
>> is a concern, then use ISPF services. If not, then it works just fine and
>> does the trick in the overwhelming majority of scenarios that I can think
>> of wanting to use it for. For example, setting up a batch installation,
>> maintenance or production job stream. If it is something you need to
>> repeat on a regular basis, there is probably not a human involved
>> editing the PDS member when you desire to do the delete.
>>
>> Regards,
>>
>> Mark
>> --
>> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
>> mailto:[email protected]
>> ITIL v3 Foundation Certified
>> Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
>> Systems Programming expert at http://search390.techtarget.com/ateExperts/
>
> When SHR allocation is used, an enqueue on the member is not as
> important as the exclusive enqueue ISPF services uses on "SPFEDIT" Major
> name to guarantee no one else tries to open the PDS for output at the
> same time with an overlapping directory update, as that would be fatal
> for PDS integrity if allowed. At least for many decades MVS prevents
> PDS directory destruction by ABENDing witih 213-30 an attempt to OPEN a
> PDS for OUTPUT if it is already OPEN for output elsewhere, but that
> means unless a delete process somehow uses the required ISPF SPFEDIT
> enqueue, it is subject to "random" ABEND failures if its execution
> conflicts with other PDS update activity that also uses SHR allocation
> of that PDS.
>
--
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
