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 MVI L
D- BASR LTR BC
CH BC LA ^
BC MVI L
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:[email protected]]
> On Behalf Of Gibney, Dave
> Sent: Wednesday, July 20, 2016 3:04 PM
> To: [email protected]
> 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:[email protected]]
> > On Behalf Of Steve Beaver
> > Sent: Wednesday, July 20, 2016 2:34 PM
> > To: [email protected]<mailto:[email protected]>
> > Subject: Re: S0C4 since z/OS 2.1
> >
> > Have you talked to Software AG yet?
> >
> > Steve
> >
> > -----Original Message-----
> > From: IBM Mainframe Discussion List [mailto:[email protected]]
> > On Behalf Of Gibney, Dave
> > Sent: Wednesday, July 20, 2016 2:47 PM
> > To: [email protected]<mailto:[email protected]>
> > 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
> >
> >
> > ----------------------------------------------------------------------
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to [email protected]<mailto:[email protected]> with the
> > message: INFO IBM-MAIN
> >
> > ----------------------------------------------------------------------
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to [email protected]<mailto:[email protected]> with the
> > message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> [email protected]<mailto:[email protected]> with the message:
> INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
