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.
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).
//IEFBR14 JOB ACCT,'DELETE DATASET',MSGCLASS=J,CLASS=A
//STEP0001 EXEC PGM=IEFBR14
//DELDD DD DSN=xxxxx.yyyyy.zzzzz,
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),
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)
From: John Pershing
Date: 25 Jan 88 11:41:42 EST
You can't even necessarily write the null program without encountering problems...
There is an apocryphal story about the large number of attempts that were required 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 system calling conventions, and all it has to do is return successfully.
The first version was something like this:IEFBR14 STARTBR 14 Return addr in R14 -- branch at itEND
First bug: A program indicates its successful completion by zeroing register 15 before returning; this version of the null program "failed" every time. Try it again:IEFBR14 STARTSR 15,15 Zero out register 15BR 14 Return addr in R14 -- branch at itEND
Much better. However, this caused some-or-other problems with the linkage editor, since the END statement didn't specify the primary entry point of the routine. Version three:IEFBR14 STARTSR 15,15 Zero out register 15BR 14 Return addr in R14 -- branch at itEND IEFBR14
At least now, the null program was functionally correct. However, dump analysis was impeded because the program didn't include its own name in the source code, as an "eyecatcher" (this is a time-honored convention). Null program, mark four:IEFBR14 STARTUSING IEFBR14,15 Establish addressabilityBR GO Skip over our nameDC AL1(L'ID) Length of nameID DC C'IEFBR14' Name itselfDS 0H Force alignmentGO SR 15,15 Zero out register 15BR 14 Return addr in R14 -- branch at itEND IEFBR14
The next change had something esoteric to do with save-area chaining conventions -- again, for the sake of conventions and to keep the dump analysis tools happy.
Note that the "null program" has tripled in size: both in terms of the number of source statements and in terms of the number of instructions executed!