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.
-- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Hooper > Sent: Tuesday, July 06, 2010 9:47 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: ENQ trap for dynamic allocation > > The dynamic allocation issue that we suffer from is primarily > IDCAMS. Some of > the functions that do not use the FILE parameter allocate the > affected file > with dynamic allocation. There are other utilities such as > DFDSS (ADRDSSU) > that also get involved at least with ENQ testing. These may > or may not use > the program call interface to ENQ. The point is that if a > batch job uses JCL to > allocate a file and has a conflict then it issues a "waiting > for dataset" message > but does not fail. Other dataset conflicts especially those > using dynamic > allocation are not so lucky. I would like to blame the > developers but they are > also victims. One other side effect is without this facility > sloppy scheduling > will now cause failures. An improperly scheduled production > job may cause > another to fail. Someone will have to scour syslogs to find > those jobs. With > the front-end one job would just wait a little bit. This > facility has saved > thousands of failures over the years. I assume others have > had similar issues > and either use data isolation or a 2x4 over the head > approach. It might be > worth a SHARE requirement to provide an exit point to address > this problem. > > ---------------------------------------------------------------------- > 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 > > ---------------------------------------------------------------------- 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
