Our tech people can't find the source of this problem and I am looking for any guesses you might have.
Sysplex in question has 11 lpars on 5 CECs zOS 1.4 with 1.7 being tested. Sometimes this summer some of the lpars in this plex will be running 1.7 if all goes well. (So far it hasn't.) I am told GRS used to propagate ENQ in star configuration. Batch job on lpar 1 builds VSAM file called N. At the end of the build job is a step using a program to frontend IDCAMS. The frontend issues an ENQ RET=NONE with scope of SYSTEMS. It then links to IDCAMS. IDCAMS renames C to O and renames N to C, effectively bringing a new version of C into play. When IDCAMS ends, the frontend issues DEQ. Meanwhile on lpar 2, a batch job using program called BT689 wants to use file C. It calls a linked subroutine BS689 which issues an ENQ with the same scope as mentioned above. The ENQ does not specify RET=NONE, but that is the default. It does specify RNL=NO, which is not the default. That should not matter since both ENQ have scope of SYSTEMS. After it obtains the ENQ, BS689 does SVC 99 to dynamically allocate the file. BT689 uses the file for a few reads and then ends. Previously the job on lpar 1 would fail periodically because the file was in use. This time the program BT689 on lpar 2 failed with message in its log R15=>00000004 S99INFO=>00000002 S99ERROR=>00001708 IKJ56228I DATA SET C NOT IN CATALOG OR CATALOG CAN NOT BE ACCESSED I own the job on lpar 1, which is time scheduled. The jobs on lpar 2 (which could be any of 5 lpars in theory) run at various times 7x24 and are not under my control. This situation could happen on any of 11 plexes but only fails on the largest plex. If it matters, all plexes use CICS, but the large plex has the least usage of MQ, IMS and DB2. Plexes do not share DASD and therefore do not share catalogues. The questions I have are: 1) Could RNL=NO be the issue that causes the ENQ to fail? 2) Because of the large number of lpars in the plex, could there be latency in the processing and propagation of the ENQ? That is could control return after the ENQ before propagation is finished? 3) Is there latency in the updating of the catalog by IDCAMS? 4) Should WAITs be added after the ENQs? Should WAIT be added before the DEQ? This question is becoming more serious as the number of jobs using BT689 increase. Eventually it could be used multiple times in each batch job that produces a report on each plex. ----------------------------------------- The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you ---------------------------------------------------------------------- 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
