Re: Broken Brancher (was Re: Best IEFACTRT)
In hdemimhlcnkiedehaemekejfaoac.wmhbl...@comcast.net, on 10/02/2009 at 05:07 PM, William H. Blair wmhbl...@comcast.net said: 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. My recollection is that IBM created the eyecatcher APAR without customer input. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Broken Brancher (was Re: Best IEFACTRT)
Shmuel Metz explains: 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. My recollection is that IBM created the eyecatcher APAR without customer input. I just remember it showing up, but figured it was just a release change (hence, no APAR to instigate it whatsoever). Sure did cause a lot of trouble for (what should have been just a) 2-instruction module. -- WB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Broken Brancher (was Re: Best IEFACTRT)
Many years ago the company I worked for had a 3031. We added the AP to it. Soon after, we started experiencing random 0Cx abends that made no sense when the dump was examined. The abends were in user and IBM code. CEs could find no problem so it had to be software. The PSR agreed that the data in the dump was valid. There were even samples where registers were wrong (did not match the storage that they were loaded from). HW started looking again. The problem did not occur with the AP offline. The problem was narrowed down to the TLB, with it off all was good. Replaced TLB. Still failed. An old CE came in with a data scope. The problem - the TLB was receiving the here's data signal 1.5ms ahead of the data, causing the TLB to load with all 1 bits. There was an optional EC that reduced a section of tri-lead by 18 inches. The EC fixed the problem. Dennis Roach GHG Corporation Lockheed Martin Mission Services Facilities Design and Operations Contract NASA/JSC Address: 2100 Space Park Drive LM-15-4BH Houston, Texas 77058 Mail: P.O. Box 58487 Mail Code H4C Houston, Texas 77258 Phone: Voice: (281)336-5027 Cell: (713)591-1059 Fax:(281)336-5410 E-Mail: dennis.ro...@lmco.com All opinions expressed by me are mine and may not agree with my employer or any person, company, or thing, living or dead, on or near this or any other planet, moon, asteroid, or other spatial object, natural or manufactured, since the beginning of time. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bruce Richardson Sent: Thursday, October 01, 2009 12:54 PM To: IBM-MAIN@bama.ua.edu Subject: Broken Brancher (was Re: Best IEFACTRT) Are you sure your code didn't suffer the same fate as IEFBR14? 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. Your code without the second BR 14 is just 6 bytes! On Tue, 29 Sep 2009 21:34:13 -0500, William H. Blair wmhbl...@comcast.net wrote: Edward Jaffe asks: Which is the best IEFACTRT? I am dying to know what you meant exactly by that question. But I'll offer my candidate (in case this is a contest): IEFACTRT CSECT IEFACTRT AMODE 31 IEFACTRT RMODE ANY R1 EQU 1 R14 EQU 14 R15 EQU 15 SRR1,R1 Write SMF termination record SRR15,R15JOB processing is to continue BRR14Return to INITiator BRR14(just in case the brancher's broke * when it executes that first BR) END And, yes, at one point, I had a machine where the brancher was broke. I had to code a Bx immediately after every Bx in case the first Bx ended up at a certain offset in a page, else the box ignored the Bx as if it were a NOP[R] and went on to whatever followed, unless it was an invalid opcode, in which case it threw an ABEND S0C4 on the Bx even if the branch address was, in fact, good. No, the CE didn't believe me. Nobody believed me for a week or so until some special CE diagnostic tape flown in by IBM from POK failed to run, red lighting the box. The hardware guys kept telling everyone it was a software problem, but the IBM software guys kept saying what they saw in the dumps was impossible, so it had to be a hardware problem. (IBM pointing fingers at itself.) Took 2 weeks to find it. Meanwhile, everything ran fine except _my_ code, which had the BR that elicited the error (an IEFACTRT exit, in fact), and the odd application here and there (which the operators just recovered and restarted on the other machine). I remembered the incident because a frequent complaint from some of the less experienced application programmers working on Assembler programs (when the PSW ended up somewhere they didn't think it should ever have gotten to) was that the brancher was broke. It always gave us lots of good laughs. Well, for at least once in this world, it really was broke. -- WB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send
Re: Broken Brancher (was Re: Best IEFACTRT)
In listserv%200910011253458520.0...@bama.ua.edu, on 10/01/2009 at 12:53 PM, Bruce Richardson bruce.richard...@arcelormittal.com said: Are you sure your code didn't suffer the same fate as IEFBR14? 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. However, there was an APAR to add an eye catcher; I believe that the eye catcher was eventually removed. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Broken hardware was Re: Broken Brancher (was Re: Best IEFACTRT)
3 incidents come to mind. The first was a 2821 print controller that blew up error recovery by sending back Device End and Busy. Despite MVT being in its last days, we were the site of first discovery. The second was on a mod 65 where the CSW was getting stored x'40' or x'48' from a 256K boundary. We were finally able to force it by On 2 Oct 2009 06:05:52 -0700, in bit.listserv.ibm-main you wrote: Many years ago the company I worked for had a 3031. We added the AP to it. Soon after, we started experiencing random 0Cx abends that made no sense when the dump was examined. The abends were in user and IBM code. CEs could find no problem so it had to be software. The PSR agreed that the data in the dump was valid. There were even samples where registers were wrong (did not match the storage that they were loaded from). HW started looking again. The problem did not occur with the AP offline. The problem was narrowed down to the TLB, with it off all was good. Replaced TLB. Still failed. An old CE came in with a data scope. The problem - the TLB was receiving the here's data signal 1.5ms ahead of the data, causing the TLB to load with all 1 bits. There was an optional EC that reduced a section of tri-lead by 18 inches. The EC fixed the problem. Dennis Roach GHG Corporation Lockheed Martin Mission Services Facilities Design and Operations Contract NASA/JSC Address: 2100 Space Park Drive LM-15-4BH Houston, Texas 77058 Mail: P.O. Box 58487 Mail Code H4C Houston, Texas 77258 Phone: Voice: (281)336-5027 Cell: (713)591-1059 Fax:(281)336-5410 E-Mail: dennis.ro...@lmco.com All opinions expressed by me are mine and may not agree with my employer or any person, company, or thing, living or dead, on or near this or any other planet, moon, asteroid, or other spatial object, natural or manufactured, since the beginning of time. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bruce Richardson Sent: Thursday, October 01, 2009 12:54 PM To: IBM-MAIN@bama.ua.edu Subject: Broken Brancher (was Re: Best IEFACTRT) Are you sure your code didn't suffer the same fate as IEFBR14? 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. Your code without the second BR 14 is just 6 bytes! On Tue, 29 Sep 2009 21:34:13 -0500, William H. Blair wmhbl...@comcast.net wrote: Edward Jaffe asks: Which is the best IEFACTRT? I am dying to know what you meant exactly by that question. But I'll offer my candidate (in case this is a contest): IEFACTRT CSECT IEFACTRT AMODE 31 IEFACTRT RMODE ANY R1 EQU 1 R14 EQU 14 R15 EQU 15 SRR1,R1 Write SMF termination record SRR15,R15JOB processing is to continue BRR14Return to INITiator BRR14(just in case the brancher's broke * when it executes that first BR) END And, yes, at one point, I had a machine where the brancher was broke. I had to code a Bx immediately after every Bx in case the first Bx ended up at a certain offset in a page, else the box ignored the Bx as if it were a NOP[R] and went on to whatever followed, unless it was an invalid opcode, in which case it threw an ABEND S0C4 on the Bx even if the branch address was, in fact, good. No, the CE didn't believe me. Nobody believed me for a week or so until some special CE diagnostic tape flown in by IBM from POK failed to run, red lighting the box. The hardware guys kept telling everyone it was a software problem, but the IBM software guys kept saying what they saw in the dumps was impossible, so it had to be a hardware problem. (IBM pointing fingers at itself.) Took 2 weeks to find it. Meanwhile, everything ran fine except _my_ code, which had the BR that elicited the error (an IEFACTRT exit, in fact), and the odd application here and there (which the operators just recovered and restarted on the other machine). I remembered the incident because a frequent complaint from some of the less experienced application programmers working on Assembler programs (when the PSW ended up somewhere they didn't think it should ever have gotten to) was that the brancher was broke. It always gave us lots of good laughs. Well, for at least once in this world, it really was broke. -- WB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Broken Brancher (was Re: Best IEFACTRT)
-snip--- Many years ago the company I worked for had a 3031. We added the AP to it. Soon after, we started experiencing random 0Cx abends that made no sense when the dump was examined. The abends were in user and IBM code. CEs could find no problem so it had to be software. The PSR agreed that the data in the dump was valid. There were even samples where registers were wrong (did not match the storage that they were loaded from). HW started looking again. The problem did not occur with the AP offline. The problem was narrowed down to the TLB, with it off all was good. Replaced TLB. Still failed. An old CE came in with a data scope. The problem - the TLB was receiving the here's data signal 1.5ms ahead of the data, causing the TLB to load with all 1 bits. There was an optional EC that reduced a section of tri-lead by 18 inches. The EC fixed the problem. unsnip--- We had a similar problem on a 158 w/AP at Trailer Train, many moons ago. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Broken Brancher (was Re: Best IEFACTRT)
-snip- Are you sure your code didn't suffer the same fate as IEFBR14? 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. However, there was an APAR to add an eye catcher; I believe that the eye catcher was eventually removed. --unsnip IIRC, there was also an APAR to mark IEFBR14 RENT, REUS,REFR as well. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Broken hardware was Re: Broken Brancher (was Re: Best IEFACTRT)
Clark, Something ate the last half of your post. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Clark Morris Sent: Friday, October 02, 2009 10:29 AM To: IBM-MAIN@bama.ua.edu Subject: Broken hardware was Re: Broken Brancher (was Re: Best IEFACTRT) 3 incidents come to mind. The first was a 2821 print controller that blew up error recovery by sending back Device End and Busy. Despite MVT being in its last days, we were the site of first discovery. The second was on a mod 65 where the CSW was getting stored x'40' or x'48' from a 256K boundary. We were finally able to force it by On 2 Oct 2009 06:05:52 -0700, in bit.listserv.ibm-main you wrote: -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Broken hardware was Re: Broken Brancher (was Re: Best IEFACTRT)
Something ate the last half of your post. Cookie monster. (5 points to anyone that understands that reference). -- Will -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Broken hardware was Re: Broken Brancher (was Re: Best IEFACTRT)
Sesame Street? William Donzelli wdonze...@gmail.com 10/2/2009 12:22 PM Something ate the last half of your post. Cookie monster. (5 points to anyone that understands that reference). -- Will -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Broken Brancher (was Re: Best IEFACTRT)
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
Broken hardware was Re: Broken Brancher (was Re: Best IEFACTRT)
I'll try not to send the message before its time (reference to an old wine commercial) this time. And to Scott, Sesame Street should have called it the Cookie-eating Monster (and I resemble that). 3 incidents come to mind. The first was a 2821 print controller that blew up error recovery by sending back Device End and Busy. Despite MVT being in its last days, we were the site of first discovery. The second was on a mod 65 where the CSW was getting stored x'40' or x'48' from a 256K boundary. We were finally able to force it by using an IEBCOPY unload with IEBCOPY brought back from SVS thanks to the MICHMODS MVT tape. We called in the third party memory CEs who came in and proved it wasn't their problem by some process that I forget even though I was the person watching this for the company. I then called IBM and the CE came in. He checked for the problem after I showed the symptoms thinking it wasn't an IBM problem and turned up a 250 nano-second delay card in the channel that wasn't delaying things for 250 nano-seconds. The last was under MVS when we lost an indexed VTOC on a 3380. After rebuilding it, I checked EREP to see what was happening at the time and found a large number of temporary write errors to the drive at the time. The CE checked it out and found a loose card in the controller. Reseating the card ended the problem. Interestingly both the wacko 2821 and the loose controller card resulted in PTFs because of the inadequate handling of error conditions. On 2 Oct 2009 06:05:52 -0700, in bit.listserv.ibm-main you wrote: Many years ago the company I worked for had a 3031. We added the AP to it. Soon after, we started experiencing random 0Cx abends that made no sense when the dump was examined. The abends were in user and IBM code. CEs could find no problem so it had to be software. The PSR agreed that the data in the dump was valid. There were even samples where registers were wrong (did not match the storage that they were loaded from). HW started looking again. The problem did not occur with the AP offline. The problem was narrowed down to the TLB, with it off all was good. Replaced TLB. Still failed. An old CE came in with a data scope. The problem - the TLB was receiving the here's data signal 1.5ms ahead of the data, causing the TLB to load with all 1 bits. There was an optional EC that reduced a section of tri-lead by 18 inches. The EC fixed the problem. Dennis Roach GHG Corporation Lockheed Martin Mission Services Facilities Design and Operations Contract NASA/JSC Address: 2100 Space Park Drive LM-15-4BH Houston, Texas 77058 Mail: P.O. Box 58487 Mail Code H4C Houston, Texas 77258 Phone: Voice: (281)336-5027 Cell: (713)591-1059 Fax:(281)336-5410 E-Mail: dennis.ro...@lmco.com All opinions expressed by me are mine and may not agree with my employer or any person, company, or thing, living or dead, on or near this or any other planet, moon, asteroid, or other spatial object, natural or manufactured, since the beginning of time. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bruce Richardson Sent: Thursday, October 01, 2009 12:54 PM To: IBM-MAIN@bama.ua.edu Subject: Broken Brancher (was Re: Best IEFACTRT) Are you sure your code didn't suffer the same fate as IEFBR14? 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. Your code without the second BR 14 is just 6 bytes! On Tue, 29 Sep 2009 21:34:13 -0500, William H. Blair wmhbl...@comcast.net wrote: Edward Jaffe asks: Which is the best IEFACTRT? I am dying to know what you meant exactly by that question. But I'll offer my candidate (in case this is a contest): IEFACTRT CSECT IEFACTRT AMODE 31 IEFACTRT RMODE ANY R1 EQU 1 R14 EQU 14 R15 EQU 15 SRR1,R1 Write SMF termination record SRR15,R15JOB processing is to continue BRR14Return to INITiator BRR14(just in case the brancher's broke * when it executes that first BR) END And, yes, at one point, I had a machine where the brancher was broke. I had to code a Bx immediately after every Bx in case the first Bx ended up at a certain offset in a page, else the box ignored the Bx as if it were a NOP[R] and went on to whatever followed, unless it was an invalid opcode, in which case it threw an ABEND S0C4 on the Bx even if the branch address was, in fact, good. No, the CE didn't believe me. Nobody believed me for a week or so until some special CE diagnostic tape flown in by IBM from POK failed to run, red
Re: Broken hardware was Re: Broken Brancher (was Re: Best IEFACTRT)
Sesame Street? One of Cookie Monster's early appearances, before Sesame Street, was in an IBM training film, called Coffee Break Machine. Here is a 1967 performance of the same skit, on the Ed Sullivan show: http://www.dailymotion.com/video/x1tmko_coffee-break-machine_business -- Will -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Broken Brancher (was Re: Best IEFACTRT)
Are you sure your code didn't suffer the same fate as IEFBR14? 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. Your code without the second BR 14 is just 6 bytes! On Tue, 29 Sep 2009 21:34:13 -0500, William H. Blair wmhbl...@comcast.net wrote: Edward Jaffe asks: Which is the best IEFACTRT? I am dying to know what you meant exactly by that question. But I'll offer my candidate (in case this is a contest): IEFACTRT CSECT IEFACTRT AMODE 31 IEFACTRT RMODE ANY R1 EQU 1 R14 EQU 14 R15 EQU 15 SRR1,R1 Write SMF termination record SRR15,R15JOB processing is to continue BRR14Return to INITiator BRR14(just in case the brancher's broke * when it executes that first BR) END And, yes, at one point, I had a machine where the brancher was broke. I had to code a Bx immediately after every Bx in case the first Bx ended up at a certain offset in a page, else the box ignored the Bx as if it were a NOP[R] and went on to whatever followed, unless it was an invalid opcode, in which case it threw an ABEND S0C4 on the Bx even if the branch address was, in fact, good. No, the CE didn't believe me. Nobody believed me for a week or so until some special CE diagnostic tape flown in by IBM from POK failed to run, red lighting the box. The hardware guys kept telling everyone it was a software problem, but the IBM software guys kept saying what they saw in the dumps was impossible, so it had to be a hardware problem. (IBM pointing fingers at itself.) Took 2 weeks to find it. Meanwhile, everything ran fine except _my_ code, which had the BR that elicited the error (an IEFACTRT exit, in fact), and the odd application here and there (which the operators just recovered and restarted on the other machine). I remembered the incident because a frequent complaint from some of the less experienced application programmers working on Assembler programs (when the PSW ended up somewhere they didn't think it should ever have gotten to) was that the brancher was broke. It always gave us lots of good laughs. Well, for at least once in this world, it really was broke. -- WB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
