IEFBR14

IEFBR14 is an IBM mainframe utility program. It runs in all IBM mainframe environments derived from OS/360, including z/OS. It is a placeholder whose purpose is to do "nothing". As it turned out, over the years, it would have problems correctly doing nothing and would sometimes fail in the task.

Purpose

On OS/360 and derived mainframe systems, most programs never directly specify files (usually called datasets) directly, but instead reference them indirectly through the Job Control Language (JCL) statements that invoke the programs. These data definition (or "DD") statements can include a "disposition" (DISP=...) parameter that indicates how the file is to be managed — whether a new file is to be created or an old one re-used; whether the file should be deleted upon completion or retained; "etc".

IEFBR14 was created because while DD statements can create or delete files easily, they cannot do so without a program to run. The program used in the JCL does not actually need to use the files to cause their creation or deletion — the DD DISP=... specification does all the work. Thus a very simple do-nothing program was needed to fill that role.

IEFBR14 is used to create or delete a PDS (Partitioned DataSet) or PS (Physical Sequential) from JCL.

Naming

The "IEF" derives from a convention on Mainframe computers that programs supplied by IBM were grouped together by function or creator and that each group shared a three-letter prefix. In OS/360, the first letter was almost always "I", and the programs produced by the scheduler group (including IEFBR14) all used the prefix "IEF". Other common prefixes included "IEB" for dataset utility programs, "IEH" for system utility programs, and "IEW" for program-linkage and -loading.

As explained below, "BR14" was the essential function of the program, to simply return back to the operating system. This portion of a program name was often mnemonic — for example, IEBUPDTE was the dataset utility (IEB) that applied updates (UPDTE) to source code files, and IEHINITT was the system utility (IEH) that initialized (INIT) magnetic tape labels (T).

Usage

Example JCL would be :

//IEFBR14 JOB ACCT,'DELETE DATASET',MSGCLASS=J,CLASS=A //STEP0001 EXEC PGM=IEFBR14 //DELDD DD DSN=xxxxx.yyyyy.zzzzz, // DISP=(MOD,DELETE,DELETE),UNIT=DASD

To create a Partioned Data Set:

//TZZZ84R JOB NOTIFY=&SYSUID,MSGCLASS=X //STEP01 EXEC PGM=IEFBR14 //DD1 DD DSN=TKOL084.DEMO,DISP=(NEW,CATLG,DELETE), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=80,DSORG=PO), // SPACE=(TRK,(1,1),RLSE), // UNIT=SYSDA

It consisted initially as a single instruction a "Branch to Register" 14. The mnemonic used in the IBM Assembler was BR and hence the name: IEF BR 14.

It didn't set the return code and hence a second instruction had to be added to clear the return code so that it would exit with the correct status.

The machine code for the modified program is:

SR R15,R15 put zero into register 15 (return code) BR R14 branch to the address in register 14 (return to scheduler)

History from the RISKS Digest

Here is an article contributed by John Pershing to the RISKS Digest [cite web|url=http://catless.ncl.ac.uk/Risks/6.14.html#subj1|first=John|last=Pershing|title=Safe programming languages|publisher=RISKS Digest|date=1988-01-25|accessdate=2006-10-12] that explains some of the history of IEFBR14: [This code is in error. The final version contains the instruction BR GO, however GO is an instruction label, not a register. The correct code would be B GO.]

From: John Pershing Date: 25 Jan 88 11:41:42 EST

You can't even necessarily write the null program without encounteringproblems...

There is an apocryphal story about the large number of attempts that wererequired in order to produce a "correct" version of MVS's null program,IEFBR14 (this was done back in the days when MVS was still called OS).As with all MVS programs, IEFBR14 is called using the standard systemcalling conventions, and all it has to do is return successfully.

The first version was something like this:

IEFBR14 START BR 14 Return addr in R14 -- branch at it END

First bug: A program indicates its successful completion by zeroingregister 15 before returning; this version of the null program "failed"every time. Try it again:

IEFBR14 START SR 15,15 Zero out register 15 BR 14 Return addr in R14 -- branch at it END

Much better. However, this caused some-or-other problems with the linkageeditor, since the END statement didn't specify the primary entry pointof the routine. Version three:

IEFBR14 START SR 15,15 Zero out register 15 BR 14 Return addr in R14 -- branch at it END IEFBR14

At least now, the null program was functionally correct. However, dumpanalysis was impeded because the program didn't include its own name inthe source code, as an "eyecatcher" (this is a time-honored convention).Null program, mark four:

IEFBR14 START USING IEFBR14,15 Establish addressability BR GO Skip over our name DC AL1(L'ID) Length of name ID DC C'IEFBR14' Name itself DS 0H Force alignment GO SR 15,15 Zero out register 15 BR 14 Return addr in R14 -- branch at it END IEFBR14

The next change had something esoteric to do with save-area chainingconventions -- again, for the sake of conventions and to keep the dumpanalysis tools happy.

Note that the "null program" has tripled in size: both in terms of thenumber of source statements and in terms of the number of instructionsexecuted!

ee also

*"This page is intentionally left blank"
*/dev/null
*/bin/true

References

External links

* [http://www.miketaylor.org.uk/tech/oreilly/iefbr14.html True in a Nutshell Appendix: IEFBR14]
* [http://www.miketaylor.org.uk/tech/oreilly/more-iefbr14.html True in a Nutshell Appendix: IEFBR14: Clarification]