If it were up to me, I would have added a parm to the ALLOC member of
PARMLIB that would indicate whether or not if a dataset was migrated it
should be recalled for DELETE process only. This would be an LPAR wide
application, but it would be easier to support I think.
Something like
ALLOCXX
MIGDEL(RECALL(Y/N){,EXIT=lmod}) - Action during a delete request the if
the dataset is migrated.
RECALL(Y) Go ahead and recall the dataset before Delete Processing
RECALL(N) Do not recall the dataset during delete processing, instead
issue HDEL command.
EXIT=lmod and exit that is invoked that would take additional actions
if desired
Default - Y
This way each component of z/OS could change their behavior over time.
And if IBM supplied an Exit with this parm, then each shop could customize
the process. Add user SMF records, take action in only certain events,
etc...
Lizette
> On Thu, 20 Aug 2009 08:52:10 +0000, Ted MacNEIL wrote:
>
> >>In z/OS V1.11, when IEFBR14 is used with DD statements to delete a data
set
> that has been migrated by DFSMShsm, Allocation is now designed to pass the
delete
> request to DFSMShsm under most circumstances so the data set can be
deleted without
> first recalling it.
> >
> >This has been discussed here, before.
> >While I understand the reasoning, I still think it's a kludge, as I've
said before.
> >
> Adding complexity to step initiation/termination and giving special
> treatment to one program name certainly feels like a kludge. Now that
> the initiator is IEFBR14-savvy, will it bypass loading and calling the
> module?
>
> But what do you see as a more orderly alternative? A new JCL "NO-OP"
> command? That wouldn't meet the likely objective of providing the
> enhancement with no changes to existing dusty JCL.
>
> Are there likely to be installations that have locally enhanced IEFBR14,
> perhaps to do reporting, that may be adversely affected by the change?
>
> There are existing ways to delete (and rename) data sets, such as batch
> TSO TMP and IDCAMS. Both these require SYSIN (SYSTSIN), so are hard
> to modularize in a PROC. I believe TSO DELETE already optimizes by
> doing an HDELETE of a migrated data set. Does IDCAMS DELETE do
> likewise?
>
> Should it have been left as it was? Can anyone propose a less kludgey
> alternative design?
>
> -- 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
