In a recent note, Tom Schmidt said: > Date: Sat, 3 Dec 2005 16:21:59 -0600 > > On Sat, 3 Dec 2005 10:13:28 -0500, "Bill Ogden" wrote: > > >Symbolics that might specify or imply a volser, data set name, device type, > >or DISP parameter can create a significant problem if not resolved early. > >Remember that these are needed to test all the ENQ and allocation situations > >that exist before a job is started, and this must be done in a way to > >prevent deadlocks. > > > >The other operating systems mentioned do not have a routine way to protect > >all the resources needed by a job while avoiding deadlocks after the job is > >started. (These systems generally lack the concept of a "job" as needed for > >large-scale batch operation.) > > > >Bill Ogden > > Symbolic substitution will create a significant problem IFF the user > is somehow astonished at the (unintended) result. If the result is > what the user (or site) intended to achieve, then so much the better. > Bill's point is not so easily dismissed. So deferring symbol evaluation would significantly erode the serialization and deadlock protection that many production shops depend on.
But that's no obstacle to deferring symbol evaluation until job initiation on the executing system, immediately before the ENQs are issued. I'll note that a similar erosion already happens, in the case where I refer to a data set by a catalogued alias. Apparently the OS ENQs on the alias name at job initiation, and attempts to ENQ on the RELATED name later, at allocation within the job step. If that ENQ fails, the job is terminated immediately; no waiting for resolution of the ENQ. (This is JES2 behavior; would JES3 be different?) (Would a better design perform the initial ENQ on the RELATED name rather than the ALIAS? There's still hazard of the ALIAS's changing between job initiation and step allocation, but it's a narrower window.) Would users tolerate similar behavior associated with deferred resolution of symbols? > I wonder how many sites would truly use (and be willing to pay for) a > job-level symbolic substitution service? > That's a different question. As an employee of an ISV who'd like to use such a service, it doesn't help me if I can't count on every customer's having it; I need it as base OS behavior. -- gil -- StorageTek INFORMATION made POWERFUL ---------------------------------------------------------------------- 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
