On Mon, 21 May 2007 22:41:55 -0400, Robert A. Rosenberg wrote: >At 18:43 -0500 on 05/21/2007, Paul Gilmartin wrote about Re: Why is >there JOB scope for DSN ENQ's anyway?: > >There is a simple reason. The ENQs are done before the job is started >so that all of the datasets are available to the steps. If you >release and reacquire the ENQs, there is a possibility that you will >not be able to reacquire them (due to some other job grabbing them > You will reacquire them when that other job DEQs them. This is scarcely different from waiting for resources before the first step, save that the potential damage from cancelling a job between steps is greater than from cancelling before the first step.
>between your DEQ and ENQ) or even worse, ending up in a deadly >embrace (where two jobs each want the same ENQs but can not get > No. Deadly embrace is not possible because the job requesting resources holds none. >them). The way it works now, you wait until everything is available >and then run, doing DEQs for those datasets that are no longer needed. > >The question of holding a Exclusive ENQ when you only need a Shared >ENQ (ie: Exclusive in Step1 and continuing to hold Exclusive when >only needing Shared in subsequent steps) is due to a poor ENQ design > (a man sharing my own convictions) >Note: I acknowledge that there also needs to be updates to the ENQ >and ISGENQ macros to request this option and a new flag bit in their >Parm fields. That and what happens if you make the request on a >system that is missing the support is the bigger problem than making >the few lines of code change to support the capability. > The format of the new parameter list needs to be such that it is invalid on a system that is missing the support. -- gil ---------------------------------------------------------------------- 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
