The dynamic allocation should be under HSM for the recall. After the recall is performed the actual GDG all request is no longer a dynamic allocation and the IEFDB401 exit should no longer see it.
Mark Jacobs Time Customer Service Inc. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Steve Flynn Sent: Wednesday, May 10, 2006 8:03 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: HSM and GDG all requests On 10/05/06, Mark Jacobs <[EMAIL PROTECTED]> wrote: > We have in the past couple of weeks had users perform a HRECALL on a GDG > base entry. This causes all migrated datasets to be recalled. This is > causing havoc with out storage groups. > > Is there any reason why the following wouldn't work. > > Use an IEFDB401 Dynamic Allocation Parameter Validation Exit to perform > the following checks > > 1) Is it a GDG ALL Request? (Using IGGCSI00 catalog search > interface) > > 2) No. Allow request > > 3) Is JOBNAME == HSM > > 4) Yes. Deny request. > > 5) Else allow request. What happens when a batch job wants to alloc an entire GDG base and then read all the generations, via a straightforward //GDGBASE DD DSN=SOME.GDG.BASE,DISP=SHR Will that get past your exit and be allowed? In this case the recalling user will be the userid the job is running under and therefore will be denied according to your pseudocode, wont it? -- Steve Despair - It's always darkest just before it goes pitch black... ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
