At 12:11 -0500 on 10/03/2013, Joel C. Ewing wrote about Re: Standard
TSO/MVS way to delete a PDS(E) member:
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.
The SPFEDIT enqueue that is used (like other enqueues that are
issued) is defective since it is based on the obsolete assumption
that the dataset name it uses is unique - IOW: It does not qualify it
by using the VOLSER of the volume that the dataset resides on. This
means that you can get locked out or 213-30'ed if are working on
Dataset A on VOLSER1 at the same time as you are on the Dataset A
which is on VOLSER2. This usually occurs when you are working with
SYSRES resident datasets but there are other times when you can have
more than one copy of a dataset in your complex.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
