On 05/05/2015 09:28 AM, Scott Ford wrote: > All, > > Since I started this "question", so how is "one" to check for the existence > of datasets if we can't really trust IEFBR14 ? Yeah, I can write an > Assembler routine, by why, when BR14 is supposed to work...I have staging > datasets we use to build our product, my first step is the IEFBR14 , to > delete these datasets if they exist, if not fine give me a return code I > can test for and proceed on with the other steps. > > Regards, > > Scott > > On Tuesday, May 5, 2015, Elardus Engelbrecht <[email protected]> > wrote: > >> John Eells wrote: >> >>> 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." >> >> ... and also in the history of MVS and OS/390. >> >> and Lizette Koehler said really really tongue in cheek this (and confusing >> a person who replied on her post): >> >> "And IEFBR14 is more that return on R14. It does stuff. Just look how >> big it is." >> >> and I said earlier: 'IEFBR14 is just a lazy program setting a RC=00 and >> nothing else.' >> >> Hmmm, I *always* ( ;-D ) wanted to sign IEFBR14 with a (program) digital >> certificate with RACF, but PDS datasets (at least the SYS1.LINKLIB) are not >> supported for this stunt. <grin> >> >> Has a patent been taken out on IEFBR14 (or its queer position in MVS, >> OS390, z/OS)? If not, I want to register it, but I am too broke. ;-D >> >> Groete / Greetings >> Elardus Engelbrecht >> ... A trivial two-instruction program like IEFBR14 that is totally unaware of any data sets can obviously not set different return codes based on the status of some data set. You can always trust IEFBR14 to do what it was designed to do -- nothing except setting a RC of 0. That IEFBR14 as a job step program ever appears to do something more than that is an illusion and purely an artifact of Initiator actions before passing control to the job step program and Initiator actions after the job step program sets its return code and completes. Those other effects are an effect of the job step and its JCL as a whole, not some effect of IEFBR14. By design, if a job step return code exists it is based solely on the job step program results (trivial in case of IEFBR14) and not on any pre-step or post-step actions done by the initiator.
For the purpose of setting a job step RC based on data set status (existence, size, whatever), we always used a Batch TSO step that would run an installation REXX EXEC with a data set name parameter, letting the REXX Exec check internally on status of the data set in some way (LISTDSI, LISTC, etc.) and based on that status set a return code that would become the job step RC. Such an EXEC is fairly trivial for an installation to set up and document. Writing Assembler code to get this functionality would IMO be considerable overkill. -- Joel C. Ewing, Bentonville, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
