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 > > SR R1,R1 Write SMF termination record > > SR R15,R15 JOB processing is to continue > > BR R14 Return to INITiator > > BR R14 (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 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
