Patrick O'Keefe wrote:
<snip>
At the very least, unexpected directions should prompt questions.
Why?
What is the efffect of following the directions?
What is the effect of NOT following the directions?
With HZSAIEOF I would definitely wonder what its effect is on
other than Health Checker.
<snip>
(Semi-humorous post warning.)
I have had nothing to do with Health Checker design or development and
have never seen the code for nor heard anyone say exactly what HZSAIEOF
does. So I can comment and speculate freely (grin), and maybe provide
some context and maybe not since I've no clue what the program actually
does.
First off, I must note that IEFBR14 holds several records of dubious
value. On our side, we have all read about how many APARs it's had,
that it's likely that it might be one of very few modules whose size
ever doubled as the result of an APAR and we have all (IBMers and
everyone else) had any number of good laughs about the misadventures
related this poor, humble module with its mere 2 lines of code
(nowadays, anyway).
On the other side, though, it's probably the most misused program we
ever shipped to anyone in the entire history of MVS, OS/390, and z/OS.
Yes, I said "misused." Meant it, too. There! I feel better!
Using IEFBR14 to allocate data sets is sort of like playing Russian
roulette and betting you will always win. It might work out in your
favor the very first time. It might not. Sooner or later, it won't.
Unlike Russian roulette, though, a bad result will not be instantly
apparent--and happily it won't be nearly as messy or permanent.
'BR14's return code will always be zero--that's what that, um, second
instruction in it does--whether the jobstep for which it runs creates
the data sets specified on DD statements or not, and whether they get
cataloged or not. (No, we're not going to recode and retest all our
samples and examples that use it to allocate data sets. It's too late
for us to mend our ways in that regard, IBMers, customers, and vendors
all, I suspect.)
In addition to that, simple JCL allocation without an OPEN--this is what
you get with 'BR14--does not write EOF for a new sequential DASD data
set. From the very name of HZSAIEOF, and the penchant of good
programmers to pick meaningful names when possible, I will speculate
that it might perhaps, just maybe, stand for Allocate (data set)
Indicating End-Of-File. You guys didn't see this? Need more coffee
today...? Where's that Craddock guy when you need him, anyway?
(Oh, no! Now I've done it. Next time they name a program like this,
they'll probably use a random character generator. Or maybe they'll name
it something misleading instead. If that isn't what happened this time,
that is. And we're not telling.)
But no matter what HZSAIEOF actually does do (and I ain't tellin' even
if I do find out at some point), it's no surprise to me that someone
would reasonably want you to use a program other than IEFBR14 to create
a data set, just so you would know immediately if the operation failed
and the data set would be in a known state for a program to process if
the operation succeeded.
And--honest!--nobody would have written a useless program, tested it,
and shipped it just for fun. If the directions say you should use it,
you should, even if you don't know why. At least, you should use it if
you expect us to support you when there is a problem. Sometimes you've
just got to trust us, at least this much. (Heck, when you think about
it, you trust us with lots more than that, right?)
OK, back to IBM-MAIN's regular programming. I dunno what got into me.
I promise to be better from now on. ;-)
--
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
