Edward Jaffe wrote:
<snip>
Such assumptive, non-canonical, lazy programming seems to work in most
cases, but can lead to failure and confusion in others. I eliminate it
whenever I can. I regard such code as inelegant, yet convenient,
short-cuts that work most of the time. "Kludge".
I fear we're losing the forest for the trees. Here's the problem.
Say I'm in a large production shop. We have production JCL that runs to
hundreds of thousands or perhaps millions of lines spread across myriad
batch jobs. Jobs often stall due to recalls before data sets are
deleted; once in a while I blow a batch window because of this. I know
how to change the jobs to eliminate the problem, and I do it when I
must. But every change to every production job is moderately
labor-intensive:
- A change control record must be opened, and the change justified and
approved.
- The change has to be made, tested, and documented.
- The documentation has to be reviewed and accepted by production control.
- The job has to be changed in the production control system.
The probability of error rises with the complexity of the change. While
I think prior posts have shown how I think about the use of IEFBR14 as a
"data set allocation and deletion 'utility'," the fact is that many
hundreds or perhaps thousands of jobs that use it that way might exist
in a large installation. For each of them, the process above--designed,
to be fair, to assure production batch quality--must be followed. If I
wanted to change them all, programmer and administrator months (or
years!) would be consumed.
In an ideal world with infinite resource, I'd bravely bear the cost and
defenestrate every single use of IEFBR14 for this purpose, replacing it
with a real utility (and appropriate control statements) that will,
among other things, provide a return code to indicate success or failure
and isolate failures to the actual failing step to simplify diagnosis
and restart.
In the real world, this ain't gonna happen. Large-scale production JCL
changes are an anathema. I want a "magic wand" to make the problem go
away (and I want it *NOW*). Hence the customer requests for this function.
So, naturally without any guarantee that we'll ever do anything...how
would those of you who dislike our solution solve the problem while
meeting the implied requirement for avoiding JCL changes?
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
