On Thu, 20 Aug 2009 23:52:23 -0700, Gibney, Dave wrote: >> >> > Since the initiator doesn't know whether any program will >> > OPEN a data set or not, this can be made to work only if >> > all RECALLs are deferred until OPEN. This then means that >> > RECALLs will proceed consecutively rather than concurrently, >> > with attendant performance consequences. >> >> Don't RECALLs already proceed consecutively rather than concurrently? > >Yup. > OK. I'll stand corrected. Wishful thinking, I guess. Since I can readily perform asynchrous recalls in DSLIST, I had hoped there was an API that job step initiation could likewise exploit. I do this regularly if, for example I want to get Info on several migrated data sets, I'll first issue HRECALL on each.
The good news is that there would be no performance degradation if recall were deferred until OPEN, and even some benefit if data sets never opened were never recalled. But that would be a major change in behavior: allocation failures could occur after execution begins. Could the programmer control this by coding UNIT=(,,DEFER) to cause recall to be deferred until OPEN? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
