Talk:IEFBR14

	This article is within the scope of WikiProject Software, a collaborative effort to improve the coverage of software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.SoftwareWikipedia:WikiProject SoftwareTemplate:WikiProject Softwaresoftware
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Computing.

Talk

There is apocryphal information regarding an initial bug in this program. I am new and don't no how you would attribute this. The bug was in the first statement. It wasn't there and depending on the current contents of register fifteen (R15) the program would fail. —Preceding unsigned comment added by Spaceyankee (talk • contribs) 13:23, 8 September 2005

Refutation of reports of the uncleared registers bug

This page (http://www.miketaylor.org.uk/tech/oreilly/more-iefbr14.html) features an email from the alledged author of IEFBR14, David Bagwell, who refutes the reports of the 'uncleared registers' bug.

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. —Preceding unsigned comment added by 203.97.50.115 (talk • contribs) 23:39, 9 October 2005

See John Pershing's note, added to the article by 62.93.174.79 on 26 November 2005. Pershing is (or by now, probably "was") a well respected IBM researcher and was around in the early days of OS/360. If he confirms the story, I'd recommend you believe it. This can be easily verified if we can find someone who has a copy of the OS/360 microfiche. Yes, even in the 1960s, you got the source code of your operating system! RossPatterson 20:58, 9 May 2006 (UTC)[reply]

In a classic example of irony, it seems you can't even discuss the null program without encountering problems! Today's update by 72.1.218.129 fixes an error in John Pershing's source code. I couldn't believe it (although the fix is clearly correct), so I checked the original email and its wrong there. In the process, I added the RISKS note as a reference. Caveat programmator, eh? RossPatterson 03:31, 12 October 2006 (UTC)[reply]

I've reverted this change as noted below. RossPatterson 00:19, 30 March 2007 (UTC)[reply]

IEFBR14 in IBM's z/OS version 1.7

The test command in z/OS TSO allows one to load a program into memory, examine it, change it, and run it. Here's what the IEFBR14 program looks like in IBM's z/OS version 1.7, which is a current version of z/OS as of January 2, 2007:

test 'sys1.linklib(iefbr14)'
 TEST
list +0 x length(8)
        +0  1BFF07FE 00000000                                        00000000
 TEST
list +0 i length(4)
        +0    SR    R15,R15                                          00000000
        +2    BCR   15,R14
 TEST
end
 READY

The Branch Register (BR) instruction as shown in the "History of IEFBR14" is generated by the Assembler as a Branch Conditional Register (BCR) instruction with all the condition bits set on, or a "Branch on any condition".

There is no eye catcher and there are no instructions implementing saveara chaining, so apocryphal is certainly the appropriate adjective to use in describing the story.

Pwalukewicz 19:38, 2 January 2007 (UTC)[reply]

Verbatim copy of John Pershing's message in the article

As noted by RossPatterson above, the copy of John Pershing's message to the RISKS Digest has been altered by an anonymous user with IP address 72.1.218.129 to fix a mistake in the original. This was certainly done it good faith, and at a time when the changed text was not clearly marked as a citation. However, it makes me wonder if it is a good idea to include the message in the article at all instead of just referencing it. It is, after all, an original source about the history of IEFBR14, and its contents, if they are to remain in the article, must not be changed. —Tobias Bergemann 16:13, 9 January 2007 (UTC)[reply]

Good point. I've reverted 72.1.218.129's change. It was a valid correction, but we are talking about quoting somebody here, and the quote should stand even as written, if it was written badly. RossPatterson 00:18, 30 March 2007 (UTC)[reply]

John W. Kennedy just made the same change, and I reverted it for the same reason. But I've added a reference to document the error so we don't go through this again. RossPatterson 00:26, 24 August 2007 (UTC)[reply]

I trashed the section. It's got a few problems. First off, it's a blatant copyright violation. Secondly, John's own note makes the evolution out to be apocryphal, which raises a question as to whether it should be here at all. It's interesting, but probably not encyclopedic. K_arunamon ^Talk 20:43, 26 December 2016 (UTC)[reply]

Just from memory...

I worked on MVS/XA back in '89-'92 and have a definite recollection of the senior systems programmer telling me the tale, but he told me that there were only two APARs against IEFBR14.

The first fix used an SLR instruction to zero the register, but that failed if the carry bit was set so it was changed to the SR that we know today.

Or was it the other way around? OK, I'll give up now, as I have neither access to the SMP/E database to look up the APARs nor my old IBM assembler reference summary to check SLR vs SR. ClickRick (talk) 22:30, 7 May 2009 (UTC)[reply]