At 15:21 -0600 on 12/08/2015, John McKown wrote about Re: Inquire
intrdr default job class:
On Tue, Dec 8, 2015 at 3:05 PM, Paul Gilmartin <
0000000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
On Tue, 8 Dec 2015 14:30:25 -0500, Robert A. Rosenberg wrote:
>At 10:29 -0700 on 12/08/2015, Paul Gilmartin wrote about Re: Inquire
>intrdr default job class:
>
>>ISPF EDIT has some effective techniques for serializing updates to
>>PDS members, precluding two programmers' editing the same member
>>simultaneously.
>
>Does the ISPF EDIT support take into account that the "Same Member"
>means the same PDS not just any PDS with the same name but different
>volumes? Using the PDS name without qualifying it with the VOLSER
>where it resides is the same problem/design-flaw which ENQ on SYSDSN
>has since it leads to False Positive errors claiming the resource is
>in use due to not bothering to take into account the volume where a
>dataset resides.
>
I wonder whether IBM knows about that.
> -- gil
ÐThe "flaw" exists:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ispzpc90/APPENDIX1.1.3
<quote>
APPENDIX1.1.3 Member name enqueue
To restrict concurrent use of a member of a partitioned data set, while
still allowing ISPF users to use different members of the same data set
(PDF EDIT, Table Processing, File Tailoring), ISPF issues this ENQ macro
for the member:
ENQ SPFEDIT,rname,E,52,SYSTEMS
where
rname
Ð Ð
the data set name, length of 44, padded with blanks, followed by the member
name, length of 8, padded with blanks
</quote>Ð
IMO a BIG DESIGN FLAW. At the time the ENQ SPFEDIT is issued SPF
KNOWS the VOLSER of the PDS being edited and the failure/refusal to
supply it as part of the RNAME leads to False Positives on "Already
ENQ'ed" returns. If user1 is editing DSN(Member1) on VOLSER1 and
user2 is editing DSN(Member1) on VOLSER2, whoever starts second is
going to get an ENQ reject due to the ENQ ignoring the difference
between the 2 DSN's VOLSERs.
ÐI do not really agree that not including the volser in the SYSDSN enqueue
is a "flaw". If it were done, then their could need to bÐe multiple ENQs,
one for each volume in a multi-volume DSN. Also, when a DSN is extended to
another volume, then an new SYSDSN ENQ would need to be issued. This could
possibly fail, although I would think it unlikely. But remember this was
designed in OS/360 and "set in stone" back when it would cost much more,
relatively speaking, in CPU and main memory overhead. Once "set in stone",
changing it is very difficult. Not only to code & test, but to put up with
customers who could start screaming about needing to change their code to
be compatible.
I call it a flaw but acknowledge that there is little that can be
done to fix it. The ENQs that are issued at JCL time are issued in
many cases before the VOLSER of the data sets is known. Thus you have
to live with the fact that DSNs are not unique and have jobs single
thread when datasets on different Volumes are referenced in the JCL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
