Are you SURE that your batch job on LPAR 1 is the problem? That is, are you sure there is not some other factor outside of what you have described here? Is it possible something else is deleting or renaming C?
The reason I ask is that it seems to me that even if you totally dropped the ENQs the situation you described would be unlikely. I don't mean you should drop the ENQs or that the situation would be sufficiently unlikely for mainframe production, I just mean that you would be unlikely to hit it in any given day, and therefore this must be something else. File N does not exist for only a fraction of a second (rename to rename) - what's the odds that a batch job would hit that more than once in a blue moon? (Again, too often to go that way in production, but I am just doing a mental exercise here.) After BS689 fails, does C still not exist? Or has it reappeared? Any chance that the rename in your job is failing and you are not checking return codes correctly? Have you checked timestamps? Have you confirmed that BS689 failed at the exact instant that your job was doing the rename? Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Kirk Talman Sent: Wednesday, April 12, 2006 10:41 AM To: [email protected] Subject: Another fine mess 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 ---------------------------------------------------------------------- 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
