I was once tasked with debugging a mysterious S0C4 in an old COBOL program. I set a SLIP for the failing job without specifying an abend code. Turned out that the original abend was a garden variety S0C7 that was mishandled by an ancient STAE routine, leading to a wild branch into some PLPA module. Sometimes omitting abend code can be quite illuminating.
. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Binyamin Dissen Sent: Tuesday, July 26, 2016 5:49 AM To: [email protected] Subject: (External):Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes On Tue, 26 Jul 2016 14:29:06 +0200 Peter Hunkeler <[email protected]> wrote: :> :>>It seems that you branched to a location that is fetch protected and not in :>>key 8. :>That would lead to a S0C4-4 not S0C4-11, wouldn't it? Program Unit: Entry: Statement: Offset: -01BE8FAE Machine State: ILC..... 0002 Interruption Code..... 0004 :>>What do you expect to find at 231A7BB8? My guess is that the LE formatter is :>>showing all zeroes since it cannot access it. :>The storage is available, otherwise it would be marked as "inaccessible storage". I don't know what to expect at that address, it is not my application, I was merely asked if I could help debugging what seems to be a storage overlay problem. I don't know how LE plays that game. A SLIP of the 0C4 would have true contents. -- Binyamin Dissen <[email protected]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
