The problem we solved with NORECALL was that of bogging down the system
with unecessary actual recalls when "HDELETEs" would do, reducing
elapsed time (and generally CPU time) significantly. We did make it
optional. If you don't want the new behavior, don't code
IEFBR14_DELMIGDS(NORECALL) in an active ALLOCxx.
But there are lots of ways to skin this particular cat. You can do the
same "temporary" allocations in the first "real" job step, or use
something like IDCAMS ALLOCATE (which will end with a nonzero return
code if something is amiss, unlike IEFBR14, and supports conditional
logic in its control statements, too, to support things like seamless
restarts) to do the allocations if you want to separate them from the
other jobsteps for coding clarity, with a COND- or IF-controlled cleanup
step if needed.
The recurring confusion about what IEFBR14 itself actually does (clear
GPR15 and return) and what people seem to think it does from the odd
post here and their (not yours) is one reason I call IEFBR14 the "most
misused program in the history of z/OS."
[email protected] (John McKown) wrote:
On Tue, May 5, 2015 at 7:29 AM, Paul Gilmartin <
<snip>
Is it "inappropriate"? Suppose, just for the sake of argument, that I am
an clever JCL coder. I know that all the NEW allocations for permanent data
sets in the job will amount to some number of cylinders. Now, I don't want
the job to fail some steps into the job due to lack of disk space. So what
I do is create a initial IEFBR14 step which allocates some number of
permanent DSNs of appropriate size with DISP=(NEW,DELETE).
<snip>
OK, I will admit that the above is a poorly contrived example of one reason
to not bypass allocation just because the PGM= is IEFBR14. Another reason
could be the amount of special coding required to support the "don't
allocate". If we are going on in that vein, then why even have the
initiator bother to run IEFBR14? Why not just have the initiator code
ignore the IEFBR14 step entirely and post the step as "ran successfully
with RC=0"? Being the way that I am, I don't really like a bunch of (IMO)
_unnecessary_ special coding
I don't know the answer to these questions. However, I feel certain that
if we were to change the system in that way, we would find out who
outside the BCP relies on the existing behavior. We probably don't want
to find out.
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
