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
