Your story about the broken brancher reminded me of an event I experienced many years ago.
We had installed a new CEC for a new workload we were bringing into the shop, and I was tasked with bringing up VM and VSE on the box. I had just installed maintnenance for VM and IPLed. Did not notice right away, but there were some things that did not come up that should have, but the kicker was that VSE would not IPL. Like all good sysprogs, I had a backoff for my maintenance, so I backed off my changes. VSE still failed, and when I looked more closely I found that everything that used a certain VM function failed. Since I had backed off to a level that had worked the day before, I concluded that it must be hardware, so we called our 3rd party hardware support guys. The first reaction was "yeh, right. You put on maint and it failed, so it must be hardware." Still, they ran diagnostics and after several hours, they got a failure. After they looked at the results of their diagnostics, they ran some additional diagnostics that led them to a hard failure in the handling of divide overflow. The condition code was not being set properly when that occurred, and for reasons I never looked into, that was causing the VM function in question to fail. They replaced the board with the defective processor and I was off and running. On Tue, 29 Sep 2009 21:34:13 -0500, William H. Blair <[email protected]> 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 [email protected] 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 [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
