IEFBR14
Ted Rolle
I heard a story that IEFBR14 was written by a temporary employee of IBM
(student on work-study), and started out life as:
IEFBR14 CSECT
BR 15
which wastes a _lot_ of machine cycles <g>.
Ted
Lee Stewart
I remember hearing that too. But IEFBR14 still has the highest number
of errors per kloc in IBM. The original version didn't zero R15....
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Lee A. Stewart 303-673-4955
Software Engineering l...@deathstar.stortek.com
Storage Tek Louisville, Colorado, USA
Mark Hanisco
dragged out to two different APARs.
The first performance improvement would be to change the SR R15,R15 to
an SLR R15,R15. SLR is faster than SR.
Then we could APAR the SLR R15,R15 with an XR R15,R15. XR is faster
than SLR.
Then it would be even more famous as to APARs per lines of code.
<snicker, snicker>
Paul Gilmartin
: I remember hearing that too. But IEFBR14 still has the highest number
: of errors per kloc in IBM. ...
It's an amusing superlative, but can you substantiate it? Who did
the research? What stands in second place? Third, etc.?
What's the average?
For example, I wouldn't be overly surprised if some program, originally
100 lines long, had 101 errors in its life history. Does your authoritative
source exclude such a possibility?
43% of all statistics are simply made up.
-- gil
Jeff Andre
: Lee Stewart (l...@endor.stortek.com) wrote:
Paul,
I don't remember the PTF number but I sort-of remember when it happened. Until
some early release of OS/MVT, around 16 or 17, return codes were not processed
by the initator. Until that time, it didn't matter what the job step returned
because it wasn't used. When IBM added support for return code, the "bug" in
IEFBR14 showed itself. A lot of very large return codes were in user's JCL
listing for a while until it was fixed.
Jeff
--
Jeff_...@stortek.com | Aggressive - adj. - Optimistic
Storage Technology Corporation |
2770 S. 88th Street MS 4232 | "We are developing the next
Louisville, Colorado 80028-4232 | release on a very aggressive
(303) 673-3720 | schedule."
Bill Manry - Oracle Corporation
[...]
> SLR is faster than SR.
>than SLR.
This hasn't been true for a very long time if ever - the
pipeline architecture machines spit out all arithmetic and
logical RR instructions at the same rate.
/b
----------
Bill Manry
Oracle Corp. / Mainframe & Integration Technologies / BMa...@us.oracle.com
#include <disclaimer.usual>
Melvin Klassen
>I always wanted to APAR IEFBR14 for performance reasons.
>It could be dragged out to two different APARs.
>The first performance improvement would be to change the SR R15,R15 to
>an SLR R15,R15. SLR is faster than SR.
Then, I would be forced to ask for a APAR,
since the "condition-code" set by 'SLR R15,R15' is *never* "zero",
while the "condition-code" set by 'SR R15,R15' is *always* "zero".
>Then we could APAR the SLR R15,R15 with an XR R15,R15. XR is faster than SLR.
>Then it would be even more famous as to APARs per lines of code.
Your APAR would be rejected, if you appealed on a "faster" criterium,
since that is processor-dependent, and probably unprovable, anyway.
David Andrews
>
> This hasn't been true for a very long time if ever - the
> pipeline architecture machines spit out all arithmetic and
> logical RR instructions at the same rate.
FWIW, I remember poring over the microcode listings on the /145
a VERY long time ago. SR was (a tiny bit) faster than XR or SLR
on that machine. Go figure.
If you have access to very old issues of SHARE's "CME Compendium",
there were several articles in the early 1980's that talk about
measuring instruction timing. Volume 7 has several of these.
--
David Andrews
d...@redbug.oau.org