It is likely that the "enqueue" is now either being done by ENQ LINKAGE=SYSTEM or by ISGENQ - both forms will *not* issue the old enqueue SVC.
Do NOT attempt to front-end the GRS PC - this would be *very* dangerous. The GRS execution environment can be extremely complex with various cross-memory links and various locks held (I spent 18 months in the bowels of GRS and have the grey hairs and nervous twitches to mark that experience). The normal GRS installation exits are also not going to be of much use either as I believe that prohibit any "WAIT" processing (eg WTOR). My suggestion is to examine why the IKJ* messages are being issued and see if you can top-and-tail the production jobs with a process that will wait for the resources rather than just fail. Rob Scott Lead Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Hooper Sent: 01 July 2010 15:19 To: IBM-MAIN@bama.ua.edu Subject: ENQ trap for dynamic allocation Fifteen years ago I wrote a facility that front-ends the ENQ SVC. It traps all ENQ requests and if SYSDSN ENQ comes back with a return code of 4 it examines the environment, issues console messages, and usually waits a minute and tries ENQ again. Thus a test job reading a production file would not cause a production job to fail but would keep trying and give the console operator a chance to cancel the test job or wait for it to finish. This facility is designed especially to eliminate the following messages: IKJ56225I DATA SET MYTEST.TEST.ENQ.FILE ALREADY IN USE, TRY LATER IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER Anyway, it works fine under z/OS 1.9 but doesn't work under z/OS 1.11. Apparently dynamic allocation (or IDCAMS) has changed and does not call SVC 56 to see if the dataset is allocated or else the ENQ parameter list has changed radically. This routine don't seem to get a chance to trap the SYSDSN ENQ request. In attempting to debug the routine I found that all SVC 56 effectively does is make a PC to the GRS address space. I am afraid that dynamic allocation is doing the PC without the SVC. I think there is a CA product that could replace this function but this home- grown facility has been "free" and I work for a frugal company. Does anyone know if I am correct in my assumption that dynamic allocation has changed? Does anyone have any idea of how to front-end the program call to GRS? Is the program call (PC) facility documented anywhere? ---------------------------------------------------------------------- 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
