Gerhard Postpischil wrote:
> The first version of IEFBR14 did not clear R15, making for
> interesting condition code test results in subsequent steps.
You have a great memory.
Ed Finnell wrote:
> IIRC there were APARs to BR14.
There were five or six just after it first shipped. Then
they botched it again in the next three or four releases
because they didn't pull in the changes for the existing
prior release PTFs. That battle was waged for years, and
we had to explain over and over to the next set of folks
who just did not seem to get it why it was broken again.
But when was that? Release 9 or 14? If I could remember
whether or not IEFBR14 was in MVT, that would tell me.
> No eye catcher, ALIGNMENT something, maybe RENT
I remember those, too, but they are relatively recent
bugs, much later than all those in the initial round.
All this was BEFORE it finally settled down in I think
Release 18 of OS/360. (The RENT problem came up first
in Release 17, if I remember correctly.)
When they first added the eyecatcher, they broke it
(S0C1 ABEND). At least one alignment problem was due
to the fact that they stuck a DS 0something before
the SR, and that caused the assembler to generate a
number of hex zeros. They tried to fix that by adding
a B[ranch] at the very beginning, but forgot to setup
the base register. Then they fixed that, but changed
the base to R15, thereby destroying the zero that had
already been put there. They finally got it right but
you know how programmers are: they just can't leave
well enough alone, and OS/VS provided new opportunity
to break it again, which they did.
When this was happening, PTFs came in the mail to the
branch office on cards (as object decks, literally).
Of course, the object deck for IEFBR14 was so small
that the cards were bent when they shrink wrapped
them in that heavy plastic. The CE asked them to
simply (re)mail them, and the next one arrived with
staples that attached the cards to the cover letter,
no doubt an over-eager secretary/mail room attendant.
He had to punch a new object deck by hand; the 2540
refused to read cards with staple holes correctly.
The RENT battle was interesting and took a long time.
It literally took months for them to understand that
anybody would even want to LOAD EP=IEFBR14 as opposed
to just "// EXEC PGM=IEFBR14". This made the battle
to get them to make it RENT frustratingly difficult.
I don't think I had even thought about INCLUDE-ing a
copy of IEFBR14 after a CHANGE, which would have, of
course, made the resulting load module NORENT. That
sort of thing came later, by which time it was RENT.
> and it was left out of JBB4410
That I do not remember, but I'm not surprised.
> Seems like eye catcher has gone away again.
You are correct:
TCB#10 RB#1 ---------------------------------- z/XDC TPUT INTERFACE ----
XDC ===>
_ 00000000_00E05000 0s (A.S.XXXXXXX) --- IEFBR14+0, @R15+0, PLPA+214000
_ +0 0s 1BFF07FE 00000000 47F0F018 12C9C4C1 *.........00..IDA*
*************** Top of Data ******************************
AMASPZAP INSPECTS, MODIFIES, AND DUMPS CSECTS OR SPECIFIC
DATA RECORDS ON DIRECT ACCESS STORAGE.
DUMPT IEFBR14 ALL
**CCHHR- 0630000D13 RECORD LENGTH- 000008
MEMBER NAME IEFBR14 CSECT NAME IEFBR14
000000 1BFF 07FE
SR BCR
AMA113I COMPLETED DUMP REQUIREMENTS
AMA100I AMASPZAP PROCESSING COMPLETED
************** Bottom of Data *******************
That's OK. IEFBR14 really doesn't need anything more
than what's there. At one point -- I think around the
timeframe when IBM hatched the "Restricted Materials"
fiasco (IBM had requested that GUIDE post folks at the
door for IBM presentations where "Restricted Materials
of IBM Corporation" were to be presented to ensure that
only GUIDE attendees who worked for companies that had,
in fact, licensed the [get this] _NOT YET AVAILABLE_
release of MVS/whatever to be discussed were allowed in;
their lawyers never seemed to understand the logical
impossibility of doing that) -- IBM embedded a gigantic
COPYRIGHT constant in IEFBR14, dramatically increasing
its size. I think it was Keith Moe who pointed out to
IBM (in both a presentation and a Requirement) that IBM
could save boatloads-KB of below-the-line storage (and
enable that much VSCR, painlessly) merely by removing
the duplicate (usually identical) copyright eyecatchers
from JUST the modules that HAD to be loaded into PLPA
by MVS.
I remember when I met the IBM POK programmer at GUIDE who
had worked on most of the early IEFBR14 APARs (she wasn't
the original author). She told me IEFBR14 had more APARs,
per line of code, than any other element in OS/360. There
were so many that it caused their program that calculated
the statistics and sorted the results high-to-low to blow
up - literally ABEND - because there were more APARs than
lines of code, a situation that the coders of the program
had never anticipated even being possible. We had a great
time remembering all the problems. I had told some of the
youngsters about the IEFBR14 saga, but I know many didn't
believe me. Right there in front of us was the programmer
that fixed most of those early problems. We made a list,
and it was incorporated into some task force report which
we were working on at the time (I have no clue which). It
made good theatre at the time. When she retired from IBM,
I wrote in her "book" about the valuable contributions to
world peace and IBM's bottom line she had made, simply by
saving generations from the hated scourge of IEFBR14 bugs.
--
WB
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
