At 09:56 -0600 on 01/26/2011, Paul Gilmartin wrote about Re: Long-r
unning job s, PDS, an d DISP=SHR:
On Wed, 26 Jan 2011 15:06:03 +0000, john gilmore
<[email protected]> wrote:
Scott Rowe writes:
<begin snippet>
...
</end snippet>
... he is saying that it is better to have an enq with major and
minor qnames that cast their net too widely than to have no enq at
all.
... true; but it is not nearly so interesting as it sounds. It is
indeed a straw man: no one has proposed abolishing the enq.
Robert Rosenberg appears to be agitating for narrowing the cast. Any
such change is hazardous, for example as recognized in:
Title: z/OS V1R11.0 ISPF Planning and Customizing
Document Number: GC34-4814-08
APPENDIX1.1.2 ISPF data set integrity enqueue
...
RESERVE SPFEDIT,dsname,E,44,SYSTEMS
...
Attention: Do not install SPF and ISPF on the same system.
There is a danger of destroying PDSs that are being updated
by SPF and ISPF at the same time because SPF uses a different
Qname (SPFDSN) than ISPF.
I suspect this is ancient and irrelevant. Otherwise, it's
insufficient: not "same system", but "any systems sharing the
volume".
A problem which I noted in response in my other reply about making
the change now. I stated that it would be hard/impossible to make the
change now. I am addressing the issue of the original ISPF (and
SYSIEWL [is there a P? - I have seen references here to both forms
and I do not remember which is right - assuming that there are not
two different QNAMES for different purposes]) RNAMEs not having the
VOLSER not how to fix the design flaw now.
I still, wonder is Mr. Rosenberg's concern hypothetical, or has he
(or anyone) suffered an impact?
Yes I have had problems where I got false positives due to attempts
to have more than one dataset being worked on at the same time when
there is a name conflict due to the VOLSER not being considered when
the private ENQ is done. I seem to remebr that the ISPF ENQ is held
for the time that the member is open in Edit (as I remember) so this
is not a quick hold. During that window, no other user can edit the
same member even if it is in a different dataset (which happens to
have the same name).
I know that there is no way to fix SYSDSN without a complete redesign
of the Initiation Process but that does not apply to when the ENQ is
done after the VOLSER is known as in the ISPF and LINKEDIT/BINDER
case (IOW: The RNAME could have been designed with the VOLSER
included in the first place).
If I had one ENQ fix that would be done, I would choose the ability
to change an Exclusive ENQ to a Shared one on the fly. This inability
leads to the Initiator leaving an Exclusive ENQ (caused by
DISP=OLD/MOD) in effect until the last step that references the DSN
has completed even though the subsequent steps are DISP=SHR. That
problem of the ENQ being held too long I HAVE run into and it has
caused scheduling delays of jobs that should have been able to start
but can not due to the false Exclusive ENQ (ie: The DISP=OLD/MOD step
has completed and all subsequent steps in the job are DISP=SHR).
Gerhard Postpischil's concern is fatuous. As long as all users of
a given resource use the same ENQ format it suffices. The slight
risk that a programmer might reflexively transpose the formats
of SYSIEWLP and SYSDSN is outweighed by the certain catastrophe
that would result from changing the format at this time.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
