Вряд-ли вы точно знаете что внутри самой знаменитой программы.
From: John Pershing <PERSHNG@ibm.com> 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 START BR 14 Return addr in R14 -- branch at it END
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 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 linkage editor, since the END statement didn't specify the primary entry point of 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, 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 START USING IEFBR14,15 Establish addressability B 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 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!
