I think Darrell is on the right track. The value at 001CD468 is 4074. I think possible (Sag code does it frequently) that the intent was to cause an 0C1, but with z/OS 2.1 the target isn’t valid for code and thus an 0C4 occurred.
In any case, by my earlier note, I have things working for now. And, of course, my long term hope is to eventually get most or all of my many products back up to supported levels. It’s just a long several projects with effectively only one person doing most of the planning, work and archeology. ☺ From: Software AG Discussion List [mailto:sa...@listserv.uark.edu] On Behalf Of Davenport, Darrell (DRS) Sent: Thursday, July 21, 2016 6:36 AM To: sa...@listserv.uark.edu Subject: Re: S0C4 since z/OS 2.1 The branch 8 bytes earlier is conditional, not absolute, so it is possible it did not branch. If the value at 001CD468 is 4074 (the same as R15), it probably got that way from the STORE statement just before the abend. If it is NOT 4074, then Pieter is right, it branched directly to 18C50CB0. Because R15 is so unusual, and because it is convention to use R15 as the return code, my bet it that 4074 is the return code from the branch Pieter mentioned. It probably got stored, then was used to cause an intentional S0C1. So if you figure out where it just came back from, using the trace back map in the dump, then see if you can find a meaning for error 4074 from whatever module it came back from, you likely have the reason it died. From: Software AG Discussion List [mailto:sa...@listserv.uark.edu] On Behalf Of Pieter Wiid Sent: Wednesday, July 20, 2016 1:10 PM To: sa...@listserv.uark.edu Subject: Re: S0C4 since z/OS 2.1 Yep; in 2.1, the low 8K is “PSA”, not just 4K. You can’t update it even if you are key zero. Thing is, this is not sufficient info. You would need the full dump to trace the instructions backward in order to determine how GPR15 got set. Also, going by the preceding instructions, I would say there was a branch directly to address 18C50CB0, else you would have had the abend 8 bytes earlier. Pieter From: Software AG Discussion List [mailto:sa...@listserv.uark.edu] On Behalf Of Gibney, Dave Sent: 20 July 2016 21:47 To: sa...@listserv.uark.edu Subject: S0C4 since z/OS 2.1 I upgraded my Development LPAR from z/OS 1.13 to z/OS 2.1 about 2 weeks ago now. And for the most part, all is well. But, I am now getting S0C4 abends in a couple of Linklsted modules. I was able to alleviate one of these by moving to STEPLIB access. But, this other isn’t cooperating as well. I remember some talk about “better” loading of linklisted module with z/OS 2.x, but I thought the default was still to follow the old rules. This is an older version of an ISV module and I am currently out of support with SAG. I’d appreciate any help or thoughts. So far, I only have the CEEDUMP. The first S0C4 were happening in the NAT423SH (Shared part of the Natural Nucleus) The value in R15 below is not good ☺ Information for enclave NATMVS Information for thread 8000000000000000 Traceback: DSA Entry E Offset Statement Load Mod Program Unit Service Status 1 CEEHDSP +00004A4C CEEPLPKA CEEHDSP UI90017 Call 2 +000000F0 NAT423SH Exception 3 +18A8E544 Call 4 +189CA8FA Call 5 +18A92AFC Call 6 +1895EBD8 Call 7 NATMVS -131C16B4 NAT423BA NATMVS Call DSA DSA Addr E Addr PU Addr PU Offset Comp Date Compile Attributes 1 0019B0C8 056508F0 056508F0 +00004A4C 20150130 CEL 2 001CD3F8 18C50BC8 18C50BC8 +000000F0 ******** 3 1898CBCC 00000000 00000000 +18A8E544 ******** 4 18C60168 00000000 00000000 +189CA8FA ******** 5 18C5F128 00000000 00000000 +18A92AFC ******** 6 1898C698 00000010 00000010 +1895EBD8 ******** 7 0019B030 1895DBC8 1895DBC8 -131C16B4 20070620 ASM Condition Information for Active Routines Condition Information for (DSA address 001CD3F8) CIB Address: 0019B798 Current Condition: CEE0198S The termination of a thread was signaled due to an unhandled condition. Original Condition: CEE3204S The system detected a protection exception (System Completion Code=0C4). Location: Program Unit: Entry: Statement: Offset: +000000F0 Machine State: ILC..... 0004 Interruption Code..... 0004 PSW..... 078D2000 98C50CB8 GPR0..... ********_00000000 GPR1..... ********_001CD468 GPR2..... ********_001CD250 GPR3..... ********_00000001 GPR4..... ********_00000000 GPR5..... ********_001CD0C8 GPR6..... ********_801CD138 GPR7..... ********_001CD3F8 GPR8..... ********_18C54000 GPR9..... ********_18CCAA54 GPR10.... ********_1898C578 GPR11.... ********_18C50BC8 GPR12.... ********_18C844B0 GPR13.... ********_001CD3F8 GPR14.... ********_001CD460 GPR15.... ********_00004074 Storage dump near condition, beginning at location: 18C50CA8 +000000 18C50CA8 58F0F008 BFFFF094 4780B0FE 50F01000 BFFFF010 4780B0FE 05EF47F0 B10241F0 |.00...0m....&0....0........0...0 Dave Gibney Information Technology Services Washington State University ________________________________________ This email has been checked for viruses by Avast antivirus software. www.avast.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
