On Mon, 4 May 2015 12:38:30 -0500, Tom Marchant wrote:
>
>>..., it still attempts Allocation.
>>Or at least verifies syntax of the DD statement. How silly!
>
>Not silly at all. A special case was recognized for DELETE with
>IEFBR14 because it is well known that IEFBR14 doesn't do
>anything except set the return code, and never has. So there
>is no need to recall the data set so that it can be processed
>before it is deleted at step end.
>
>The allocation is a totally different matter. Driving Allocation is
>one of the primary uses for IEFBR14.
>
No, it's silly. I can hardly imagine any query that tells that a DSN is
not migrated without collaterally providing information that it does
not exist. So, pseudocode:
query DSN status
if exists then
if migrated
then HDELETE
else let allocation handle it.
fi
else NOP
fi
... saving a trip through Allocation for a data set that will be deleted
immediately.
Guaranteeing that a data set can be allocated DISP=NEW regardless of its prior
status is one of the primary uses for IEFBR14 DISP=(MOD,DELETE). It should be
worth saving even the relatively small overhead of allocation.
Hmmm... If DISP=(MOD,DELETE,CATLG), is IEFBR14 executed to determine
whether it ABENDs?
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
