Hi John, (fun old story response to (Semi-humorous post warning.) post.
And sometimes an 'exposure' is also a 'feature'. True story. a 'few' years ago we had a programmer who was a little shaky on disp coding, sometimes coding new,delete,catlg. Programmer had worked many years in a shop where the programmers did not do JCL. Sometimes there would be a special run with a clock time of 15-20 hours, and the most important output dataset coded - yeah, you guessed it :-) So, somebody, usually the programmer, would call me while the job was still running. I would mount the work pack private, and map the drive and remap every time the file took an extent. When the job when to good EOJ, and the file was deleted, I would absolute allocate each extent location with IEFBR14, concat in the extent order, output in one 'piece' and give it back to the programmer. Did that a number of times... On the other hand, there were the applications that allocated all files with IEFBR14 and then did not open the files unless the run was actually going to write to them. The next job in the run would expect to open that dataset, either empty or with application data. Surprise! Left over data! Those were 'fun'. Linda Mooney -------------- Original message -------------- From: John Eells <ee...@us.ibm.com> > Patrick O'Keefe wrote: > > > 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. > > > (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 ---------------------------------------------------------------------- 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
