Using ENQ/DEQ is only good if all participants abide by it. You said: "We want to ENQ on the name of the program being handled to prevent other operations or changes being made to that program in parallel". What other operations? Your other change management operations? Or do you mean general execution/access of the object(JCL, program, etc)? I ask because if you mean honoring enqueues just within your change management operations, that might be doable with what you are asking. If you mean controlling execution/copying/editing whatever object you are acting on, well, that’s an entirely different proposition, and highly unlikely to be successful unless you can control *all* avenues of getting to that object.
How are these change management jobs being scheduled? Ad-hoc? From a scheduler? Is this a home-grown change management tool? I know you said the solution has to be independent of JCL. I'm wondering why? If you are using a ISV supplied change management package, most have the ability to "lock" a member. If homegrown, possibly using PDS's as repositories? How is the change manager JCL built? Dynamically? Without knowing your environment, it would seem to me that rather than spending a bunch of time writing/testing a RYO process that you, or your replacement one day down the road has to live with, I'd use standard JCL DISP=OLD processing on a dummy dataset name that includes the program name as part of it. _________________________________________________________________ Dave Jousma Assistant Vice President, Mainframe Engineering [email protected] 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Elardus Engelbrecht Sent: Monday, April 20, 2015 1:24 PM To: [email protected] Subject: Re: ENQ for the life of the job Steff Gladstone wrote: >The job is performing a change management system operation (moving a new >program version to production, saving previous generations, providing for >possible fallback, etc.). The operation for various reasons must be performed >in several job steps. We want to ENQ on the name of the program being handled >to prevent other operations or changes being made to that program in parallel. >Of course the ENQ must remain in effect for the duration of the entire >operation. Ok. You've got good replies plus a very good probing question from D Jousma: 1. ENQ macro at first step and DEQ macro in last step. (Just check up your GRS/MIM setup as well your keywords of course) 2. DD with DISP=(OLD,PASS) or IEFBR14 with an unreferenced DSN. Failsafe, unless a weird ABEND happens. 3. SMF/JES2 Exit. 4. CA-11 with GDG or so for restart purposes. I'm not sure about this one, but I accept what was written. While I have some experience with handling ENQ problems and testing it out with Assembler to test our defective tape management system with incorrectly setup GRS across the Sysplex, I have a good solution for you for that specific situation. Do you have automation? If so, set up a flag (condition flag or variable) indicationg your process is running with 1 or many jobs and 1 or many steps. Only when the whole story is completed you turn off [1] that flag allowing others to start a new operation. Now setup your automation so that nothing else can run while that flag is running (made TRUE). This is NOT a ENQ solution, but you can perhaps consider this way since you don't want any JCL changes. HTH! Groete / Greetings Elardus Engelbrecht [1] - I eventually did the reverse - I [rather, let the automation team do the dirty work] setup the flag when a SMF job on a LPAR has finished - Only when all and every SMF flags in the whole SysPlex were made TRUE, then a certain job is kicked off automagically for that day. Then all those flags were cleared out for the next set of runs. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
