At 10:00 AM -0500 on 07/06/2010, McKown, John wrote about Re: ENQ
trap for dynamic allocation:
Perhaps what is needed is a new PARMLIB specification in the ALLOCnn
member. Perhaps similar to the SDSN_WAIT parameter. Perhaps called
DYN_DSN_WAIT(YES|NO). Which would specify whether a DYNALLOC of an
"in use" dataset should WAIT until the DSN is freed or not. Now, I
know that this can lead to a deadly embrace where JOB "A" allocates
DSN "A" in JCL with DISP=OLD while job "B" allocated DSN "B" in JCL.
Job "A" then tries to DYNALLOC "B" and waits. Job "B" tries the same
and wait, which causes a deadlock. So another parameter of
DYN_DSN_WAIT_TIME could be specified so that after the specific
period of time the DYNALLOC fails as it does today. Or IBM could try
to write a deadlock detection routine which would fail the second
DYNALLOC with a "potential deadlock" failure code.
Even worse, due to the design flaw in ENQ that does not allow an EXC
ENQ to be converted into a SHR ENQ, you have the situation that so
long as any step in a Job Stream has DISP=OLD, the EXC ENQ is held
until the last step that uses the data set has completed (even though
that step has DISP=SHR coded). Thus I can run into this situation
even though the owning step (and all subsequent steps) only want/need
a SHR ENQ due to a prior completed step having needed a EXC ENQ.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
