[EMAIL PROTECTED] wrote:
Why code the special case?
What we have works; why complicate it with special code paths?
Why do anything? DOS 1.0 worked, too.
<chop>
Actually there are alternatives already. IEFBR14 is not the best
choice for data set allocation or deletion in my view,
particularly for scheduled production jobs, and especially for
jobs that others must support. IEFBR14 offers no indication of
success or failure. The condition code set by the SR 15,15 is
always zero. The indication of success or failure thus moves to
a subsequent jobstep or even a subsequent job...if you're
reasonably lucky.
This complicates diagnosis at best and leads to incorrect results
at worst. To me, IDCAMS DEFINE and ALLOCATE, TSO/E ALLOCATE, and
JCL allocation in the same jobstep (at least, for new data sets)
all seem far preferable. If you simply must use IEFBR14,
consider a subsequent IDCAMS step to verify that it did what you
expected. (But hey!, if you're using IDCAMS anyway...you get the
idea. ;-)
A JCL option to return condition code zero while processing DD
statements would do nothing to help the situation; indeed, it
would exacerbate it by encouraging behaviors I'd rather we
discouraged. One that passed an appropriate condition code might
be interesting...but I don't know how much overhead we would
really save after adding all the necessary logic to such new
processing.
Having said all that, I know (I do!) that "The world runs on
IEFBR14." That does nothing to change my opinion, though.
--
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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
