Re: S0C4 since z/OS 2.1
>in 2.1, the low 8K is “PSA”, not just 4K. It has been 8K for z/Architecture, not since 2.1 >You can’t update it even if you are key zero. This is not correct for "8K" or "4K". Only a section of the PSA is subject to Low Address Protection which is what prevents modifications even from key 0. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 since z/OS 2.1
Thanks Elardus, all valid thoughts. I am backlevel on Natural, Adabas and EntireX from SAG. Moving back to upgrading EntireX as it also broke under z/OS 2.1 > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Elardus Engelbrecht > Sent: Thursday, July 21, 2016 2:49 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: S0C4 since z/OS 2.1 > > Gibney, Dave wrote: > > >There are unfortunately more than several copies of this module lying > >around here. Someone zapped CSECT NATRUN3 The unzapped version > works under z/OS 2.1. The zapped version does work under z/OS 1.13, but I > have no idea what the environmental change is. > > This is not looking good. What is the reason of that zaps? You should try to > find out. Perhaps comparing any eye-catchers? > > > >Not yet. After all, I'm running Natural 4.2.3 and the current supported > version is what 7.4 or 8.n? > > What software is 7.4 or 8.n? Are you referring to ADABAS? Or Com-Plete? > > > >I also should add that this particular problem seems to only manifest with > Endevor (also backlevel) under TSO/ISPF. > > >I believe I was mistaken in one assumption. Moving from Linklst to Steplib > did fix my first S0C4. > > Ouch. Not ideal solution, but ... > > Just compare all your loadlibs in Linklist and Steplib. Perhaps you're using > incorrect set of load mods or libraries. > > Perhaps a backlevel or incorrected compiled module(s) is a result of your > S0C4. > > Other possibility is that you need to review your exits, modules and custom > application programs and perhaps re-compile them using z/OS v2.1 macros. > > Without zaps of course if you can. > > > >The issue I am not having seems to be that the Endevor Processor has a > STEPLIB which is overriding the STEPLIB that has the linklsted module, so I'm, > falling back on the failing linklsted module. > > >I'd still like to know what is causing the linklsted module to fail > >under z/OS 2.1 when it did not under z/OS 1.13 > > Incompatibility with z/OS v2.1 or JES2? Contact someone who has support > with Software AG and vendor of Endevor. [1] > > I certainly know that you need to upgrade your Software AG software so you > can use it on z/OS v2.1. > > No comment about Endevor, sorry. We're not using that, AFAIK. > > It is a real PITA if you need to have support to resolve your problem, but you > are out of support... > > Good luck! > > Groete / Greetings > Elardus Engelbrecht > > [1] - I think there is a discussion list for SAG software, just like IBM-MAIN, > RACF-L, Assembler-L, etc. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 since z/OS 2.1
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 8000 Traceback: DSA Entry E Offset Statement Load Mod Program Unit Service Status 1 CEEHDSP +4A4C CEEPLPKA CEEHDSP UI90017 Call 2 +00F0 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 +4A4C 20150130 CEL 2 001CD3F8 18C50BC8 18C50BC8 +00F0 3 1898CBCC
Re: S0C4 since z/OS 2.1
Gibney, Dave wrote: >There are unfortunately more than several copies of this module lying around >here. Someone zapped CSECT NATRUN3 >The unzapped version works under z/OS 2.1. The zapped version does work under >z/OS 1.13, but I have no idea what the environmental change is. This is not looking good. What is the reason of that zaps? You should try to find out. Perhaps comparing any eye-catchers? >Not yet. After all, I'm running Natural 4.2.3 and the current supported >version is what 7.4 or 8.n? What software is 7.4 or 8.n? Are you referring to ADABAS? Or Com-Plete? >I also should add that this particular problem seems to only manifest with >Endevor (also backlevel) under TSO/ISPF. >I believe I was mistaken in one assumption. Moving from Linklst to Steplib did >fix my first S0C4. Ouch. Not ideal solution, but ... Just compare all your loadlibs in Linklist and Steplib. Perhaps you're using incorrect set of load mods or libraries. Perhaps a backlevel or incorrected compiled module(s) is a result of your S0C4. Other possibility is that you need to review your exits, modules and custom application programs and perhaps re-compile them using z/OS v2.1 macros. Without zaps of course if you can. >The issue I am not having seems to be that the Endevor Processor has a STEPLIB >which is overriding the STEPLIB that has the linklsted module, so I'm, falling >back on the failing linklsted module. >I'd still like to know what is causing the linklsted module to fail under z/OS >2.1 when it did not under z/OS 1.13 Incompatibility with z/OS v2.1 or JES2? Contact someone who has support with Software AG and vendor of Endevor. [1] I certainly know that you need to upgrade your Software AG software so you can use it on z/OS v2.1. No comment about Endevor, sorry. We're not using that, AFAIK. It is a real PITA if you need to have support to resolve your problem, but you are out of support... Good luck! Groete / Greetings Elardus Engelbrecht [1] - I think there is a discussion list for SAG software, just like IBM-MAIN, RACF-L, Assembler-L, etc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 since z/OS 2.1
I have some more info. It is still a change with z/OS 2.1, but I can duplicate it outside the linklist. There are unfortunately more than several copies of this module lying around here. Someone zapped CSECT NATRUN3 (on day 261 od 2009) in the failing three copies. The zap was the Load Address I-000B00 0DEF 12FF 4780 BB18 49F0 BDDC 47B0 BB18 4110 052F 47F0 BD90 9204 D171 5820 D298 D-000B00 0DEF 12FF 4780 BB18 49F0 BDDC 47B0 BB18 41F0 052F 47F0 BD90 9204 D171 5820 D298 I- BASR LTR BC CH BC LA ^ BC MVIL D- BASR LTR BC CH BC LA ^ BC MVIL The unzapped version works under z/OS 2.1. The zapped version does work under z/OS 1.13, but I have no idea what the environmental change is. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Gibney, Dave > Sent: Wednesday, July 20, 2016 3:04 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: S0C4 since z/OS 2.1 > > Not yet. After all, I'm running Natural 4.2.3 and the current supported > version is what 7.4 or 8.n? > I also should add that this particular problem seems to only manifest with > Endevor (also backlevel) under TSO/ISPF. > > I believe I was mistaken in one assumption. Moving from Linklst to Steplib did > fix my first S0C4. > > The issue I am not having seems to be that the Endevor Processor has a > STEPLIB which is overriding the STEPLIB that has the linklsted module, so I'm, > falling back on the failing linklsted module. > > I'd still like to know what is causing the linklsted module to fail under > z/OS 2.1 > when it did not under z/OS 1.13 > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Steve Beaver > > Sent: Wednesday, July 20, 2016 2:34 PM > > To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU> > > Subject: Re: S0C4 since z/OS 2.1 > > > > Have you talked to Software AG yet? > > > > Steve > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Gibney, Dave > > Sent: Wednesday, July 20, 2016 2:47 PM > > To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.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 8000 > > > > Traceback: > > DSA Entry E Offset Statement Load Mod Program > > Unit Service Status > > 1 CEEHDSP +4A4C CEEPLPKA CEEHDSP > > UI90017 Call > > 2 +00F0 NAT423SH > > Exception > > 3 +18A8E544 > > Call > > 4 +189CA8FA > > Call > > 5 +18A92AFC > > Call > > 6 +1895EBD8 > > Call > > 7 NATMVS -131C16B4 NAT423BA NATMVS > > Call > > > > DSA DSA Addr E AddrPU AddrPU Offset Comp Date Compile > > Attributes > > 1 0019B0C8 056508F0 056508F0 +4A4C 20150130 CEL > > 2 001CD3F8 18C
Re: S0C4 since z/OS 2.1
Not yet. After all, I'm running Natural 4.2.3 and the current supported version is what 7.4 or 8.n? I also should add that this particular problem seems to only manifest with Endevor (also backlevel) under TSO/ISPF. I believe I was mistaken in one assumption. Moving from Linklst to Steplib did fix my first S0C4. The issue I am not having seems to be that the Endevor Processor has a STEPLIB which is overriding the STEPLIB that has the linklsted module, so I'm, falling back on the failing linklsted module. I'd still like to know what is causing the linklsted module to fail under z/OS 2.1 when it did not under z/OS 1.13 > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Steve Beaver > Sent: Wednesday, July 20, 2016 2:34 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: S0C4 since z/OS 2.1 > > Have you talked to Software AG yet? > > Steve > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Gibney, Dave > Sent: Wednesday, July 20, 2016 2:47 PM > To: IBM-MAIN@LISTSERV.UA.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 8000 > > Traceback: > DSA Entry E Offset Statement Load Mod Program > Unit Service Status > 1 CEEHDSP +4A4C CEEPLPKA CEEHDSP > UI90017 Call > 2 +00F0 NAT423SH > Exception > 3 +18A8E544 > Call > 4 +189CA8FA > Call > 5 +18A92AFC > Call > 6 +1895EBD8 > Call > 7 NATMVS -131C16B4 NAT423BA NATMVS > Call > > DSA DSA Addr E AddrPU AddrPU Offset Comp Date Compile > Attributes > 1 0019B0C8 056508F0 056508F0 +4A4C 20150130 CEL > 2 001CD3F8 18C50BC8 18C50BC8 +00F0 > 3 1898CBCC +18A8E544 > 4 18C60168 +189CA8FA > 5 18C5F128 +18A92AFC > 6 1898C698 0010 0010 +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: +00F0 > Machine State: > ILC. 0004Interruption Code. 0004 > PSW. 078D2000 98C50CB8 > GPR0. _ GPR1. _001CD468 GPR2. > _001CD250 GPR3. _0001 > GPR4. _ GPR5. _001CD0C8 GPR6. > _801CD138 GPR7. _001CD3F8 > GPR8. _18C54000 GPR9. _18CCAA54 GPR10 > _1898C578 GPR11 _18C50BC8 > GPR12 _18C844B0 GPR13 _001CD3F8 > GPR14 > _001CD460 GPR15 _4074 > > Storage dump near condition, beginning at location: 18C50CA8 > +00 18C50CA8 58F0F008 B094 4780B0FE 50F01000 B010 > 4780B0FE > 05EF47F0 B10241F0 |.00...0m&000...0 > > Dave Gibney > Information Technology Services > Washington State University > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -
Re: S0C4 since z/OS 2.1
Have you talked to Software AG yet? Steve -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Wednesday, July 20, 2016 2:47 PM To: IBM-MAIN@LISTSERV.UA.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 8000 Traceback: DSA Entry E Offset Statement Load Mod Program Unit Service Status 1 CEEHDSP +4A4C CEEPLPKA CEEHDSP UI90017 Call 2 +00F0 NAT423SH Exception 3 +18A8E544 Call 4 +189CA8FA Call 5 +18A92AFC Call 6 +1895EBD8 Call 7 NATMVS -131C16B4 NAT423BA NATMVS Call DSA DSA Addr E AddrPU AddrPU Offset Comp Date Compile Attributes 1 0019B0C8 056508F0 056508F0 +4A4C 20150130 CEL 2 001CD3F8 18C50BC8 18C50BC8 +00F0 3 1898CBCC +18A8E544 4 18C60168 +189CA8FA 5 18C5F128 +18A92AFC 6 1898C698 0010 0010 +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: +00F0 Machine State: ILC. 0004Interruption Code. 0004 PSW. 078D2000 98C50CB8 GPR0. _ GPR1. _001CD468 GPR2. _001CD250 GPR3. _0001 GPR4. _ GPR5. _001CD0C8 GPR6. _801CD138 GPR7. _001CD3F8 GPR8. _18C54000 GPR9. _18CCAA54 GPR10 _1898C578 GPR11 _18C50BC8 GPR12 _18C844B0 GPR13 _001CD3F8 GPR14 _001CD460 GPR15 _4074 Storage dump near condition, beginning at location: 18C50CA8 +00 18C50CA8 58F0F008 B094 4780B0FE 50F01000 B010 4780B0FE 05EF47F0 B10241F0 |.00...0m&000...0 Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 8000 Traceback: DSA Entry E Offset Statement Load Mod Program Unit Service Status 1 CEEHDSP +4A4C CEEPLPKA CEEHDSP UI90017 Call 2 +00F0 NAT423SH Exception 3 +18A8E544 Call 4 +189CA8FA Call 5 +18A92AFC Call 6 +1895EBD8 Call 7 NATMVS -131C16B4 NAT423BA NATMVS Call DSA DSA Addr E AddrPU AddrPU Offset Comp Date Compile Attributes 1 0019B0C8 056508F0 056508F0 +4A4C 20150130 CEL 2 001CD3F8 18C50BC8 18C50BC8 +00F0 3 1898CBCC +18A8E544 4 18C60168 +189CA8FA 5 18C5F128 +18A92AFC 6 1898C698 0010 0010 +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: +00F0 Machine State: ILC. 0004Interruption Code. 0004 PSW. 078D2000 98C50CB8 GPR0. _ GPR1. _001CD468 GPR2. _001CD250 GPR3. _0001 GPR4. _ GPR5. _001CD0C8 GPR6. _801CD138 GPR7. _001CD3F8 GPR8. _18C54000 GPR9. _18CCAA54 GPR10 _1898C578 GPR11 _18C50BC8 GPR12 _18C844B0 GPR13 _001CD3F8 GPR14 _001CD460 GPR15 _4074 Storage dump near condition, beginning at location: 18C50CA8 +00 18C50CA8 58F0F008 B094 4780B0FE 50F01000 B010 4780B0FE 05EF47F0 B10241F0 |.00...0m&000...0 Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
