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
