True in a Nutshell Appendix: IEFBR14: Clarification

11th August 2005

Date: Tue, 9 Aug 2005 17:14:15 -0400
From: David Bagwell <dbagwell@chartertn.net>
To: yath@yath.eu.org, mike@miketaylor.org.uk
Subject: IEFBR14

Greetings Mike and Sebastian,

As one of the co-authors of the program IEFBR14, I was intrigued to find your discussion of our program [on your] web site. I would like to comment on some aspects of the development of IEFBR14, and solicit any further information you may know about its history and development.

1. As one of the IBM programmers involved in the development and integration of OS/360 in Poughkeepsie, NY, in 1965-1967, I assure you it was our understanding that the three-letter prefix to module names used in the operating had no ``meaning''. The prefix identified the system component to which the module belonged. E.g., IEB: Dataset Utilities; IEH: System Utilities; IEW: Linkage Editor; IEF: Scheduler; etc. In the course of time some prefixes did derive from acronymes (e.g. CLR: Control Library Environment And Resources), but not many. I guess some people might conjure up a meaning, but I doubt it was ``official''.

2. To say ``IBM forgot to set the return register ... in the past'', and ``later added [the fix]'' is not quite accurate. I beleive the first release of IEFBR14 that I saw in OS/360 was fully functional in this regard. Another commentary on IEFBR14 I saw some time ago stated that ``upon initial release there were two bugs in the program: the return code was not set to 0, and it was not linked as `load and keep resident'.'' Actually, the return code problem was detected on the first compile and fixed on the second, long before release. Some months later, when ``load and keep resident'' functionality was added to the system, IEFBR14 was not in the first cut of programs so linked, but was added later.

3. A caveat here: I do not know who put my module in the system. To my knowledge, IEFBR14 was not speced and implemented as other elements of OS/360, but was added to the system as an afterthought. I do not believe it was documented in any of the early user guides or manuals. My claim to authorship stems from the fact that I wrote my version of it some weeks after OS/360's customer release, and I naturally shared my program with my coworkers. I did not have authority or access to add it to the system; some of them did. When it suddenly appeared in a maintenance release of the system, I tried to find out who put it in, but no one claimed it. If you know of anyone else that claims authorship, I would like to communicate with them. Perhaps (read that ``probably'') there is more to the story than I know. It was probably written by any number of people prior to its inclusion in the system. You either had to write IEFBR14 or execute IEBUPDTE or some other massive program, providing it with no input to process, simply to achieve some simple DD function. That was offensive to my programmers pride.

4. I read a rant some time ago about how IBM used ``inefficient code'' in IEFBR14 in order to sell more machine time. Absurd. It was written in early 1966 for the S/360 Model 40. There were three possible instructions that could be used to zero R15: ``Clear Register R15'', ``Subtract Register R15,R15'', and ``Exclusive Or Register R15,R15''. All three required the same memory and processing cycles. They were equal and interchangeable. Whether or not future hardware favored one implementation over another I do not know, but if we had wanted to sell more machine time, IEFBR14 would never have been written. Besides, who could possible have forseen the man-hours and machine time chewed up discussing the selection of one instruction in the entire set of OS/360-370-380(?)-390 instructions. I used to be embarassed to admit that I actually spent the time to research the performance of the candidate instructions to select the most efficient one.

Regards,
David Bagwell
IBM Retiree, Programmer Consultant

Feedback to <mike@miketaylor.org.uk> is welcome!