Bruce Richardson asked:
> ... sure your code didn't suffer the same fate as IEFBR14?
Yes. The entire routine needed two base registers. But that
would not have mattered anyway: IEFACTRT was loaded in LPA.
Our friend Shmuel (Seymour J.) Metz contributed this to us:
> Bruce Richardson said:
>
>> The story (Urban Legend?) I heard, was that IEFBR14 was
>> originally just a "BR 14", but that code was APAR'd to
>> add a "SR 15,15" before the "BR 14" to set the return
>> code to zero. But then along came a problem with the
>> loader, it seems that the minimum program length has
>> to be 8 bytes, so another APAR was opened to add two
>> NOPRs to the code.
>
> The first is true; I don't believe the second.
I agree, Shmuel. The second part sounds like urban legend.
> However, there was an APAR to add an eye catcher;
I know one got put in there, but I didn't know it got put
there because some customer(?) asked for it to be put in.
I thought it was because of the lawyers. But more on that
issue, just below.
> I believe that the eye catcher was eventually removed.
That is correct. But more on that issue, too, just below.
Rick Fochtman later added:
> IIRC, there was also an APAR to mark IEFBR14 RENT,
> REUS, REFR as well.
Yes, you recall correctly. But I think that was before MVS.
/ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /
For what it's worth, I was the submitter of at least three of
the apparently very famous IEFBR14 APARs against the original
IEFBR14 (in OS/360 Release 14 CMR) -- a fact acknowledged by
Eileen Sassman of IBM Poughkeepsie at GUIDE years ago. Of all
of these various tall tales, war stories, and claims-to-have-
been-the-one-that-did-it that I have heard and read about on
this list (in particular) as well as other places, virtually
nobody has ever got the story right, yet. This is how I know
that all such posters are [editorial description deleted for
a family-friendly mail list archive]-ers.
You did get this part right:
> IEFBR14 was originally just a "BR 14", but that code was
> APAR'd
But not this part:
> to add a "SR 15,15" before the "BR 14" to set the return
> code to zero.
It took IBM three tries to get it right. PTFs arrived on card
decks in the mail then, shrink-wrapped in plastic. So, we are
talking weeks here to add a single instruction, and not break
something else in the process, of course.
There was another APAR or series of APARs that either Eileen
or somebody else from IBM POK told me about (ones which I did
NOT submit) related to some maroon putting an eyecatcher into
IEFBR14, back when IBM was getting anal about copyrights and
the like. This was back when Keith Moe of Amdahl added up all
the bytes occupied by all the (obviously redundant) copyright
eyecatchers in all the CSECTs in all the load modules in LPA
at the time. It was a huge number, an astonishing percentage
of the then-typical 2.5-3 MB that LPA below the line required
(because they were putting copyright eyecatchers into every
CSECT, not just every load module like most software vendors).
IBM adding the eyecatcher would not have been a problem, had
both IBM and vendors been using IEFBR14 only in // EXEC PGM=
statements for its original intended purpose. The problem was
that both IBM and OEM software vendors had a habit of doing
things like this in a linkage editor step:
//LINKLIB DD DISP=SHR,DSN=SYS1.LINKIB
INCLUDE vendor-things
CHANGE IEFBR14(other_name)
INCLUDE LINKLIB(IEFBR14)
INCLUDE vendor-thing-that-calls-other_name
NAME vendor-load-module(R)
In other words, everybody and his uncle were INCLUDE'ing
IEFBR14, renaming it(s CSECT) something else (which other
code in the load module was calling), instead of providing
their own "dummy" do-nothing (BR R14) code. When IEFBR14 was
just eight bytes long that was perfectly fine, but when IBM
added a 100+ byte copyright notice, the sometimes carefully-
crafted sizes (and page alignments) of load modules changed.
Besides, everybody felt it was completely asinine that
IBM thought they needed a copyright notice on a piece of
code whose NAME immediately suggested its entire CONTENTS
to anyone who knew Assembler, which meant that customers
(at least their minds) would be violating the recently-
introduced IBM software license provision against "reverse
assembly" of "Restricted Materials of IBM." In other words,
it effectively looked like IBM thought police had taken
over (even if it was clear that IBM didn't really mean that
to be the end result) .
I don't remember how long it took to get that copyright
notice removed from IEFBR14. I didn't try to APAR it, and
was not aware than anybody else did (nor even that its
presence in the first place was in response to a customer
APAR, which seems astonishing). I do remember all the OEM
software vendors stumbling all over themselves with sets
of fixes to supply their own xxxBR14 CSECT. Most were just
8 bytes long, but some idiots [not to be named here, now]
didn't quite grok the original problem, so the replacement
included their own "standard" -- even longer than IBM's --
copyright eyecatcher! Go figure. Lawyers everywhere!
Some IBMers years later told me that it was this specific
incident that got upper management in Poughkeepsie to see
that what they had been saying about the IBM lawyers taking
over and getting in the way was, in fact, exactly correct.
IBM was literally paranoid about the OEM hardware vendors,
and getting very suspicious of the OEM software vendors.
Things weren't pretty at the time. That's when we got OCO.
--
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
