The listing indicates the @MEMALOC csect is AMODE 31. The calling program is listed as AMODE 24. Assuming the LINK in the first program is to @MEMALOC, it seems the contents of R2 at the time of the abend is part of some sort of save area passed by the AMODE 24 program, but now interpreted as a 31-bit address. The first program has a link-edit date of 1994 where the load module containing @MEMALOC has a link-edit date of yesterday. Are you sure the new copy of this program has the correct attributes?
-----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Bernd Oppolzer Sent: Tuesday, March 17, 2015 1:30 PM To: [email protected] Subject: Re: S0C4 abend after upgrading to z/OS 1.13 The PSW which is contained in the Fault Analyser Reports shows that the AMODE at the time of error is 31 (see 99... at the leftmost part of the instruction address), so the address in R2 is in fact treated as a 31 bit address. But the main task seems to be at RMODE 24 and was probably AMODE 24. Could it be that the problem is that some intermediate component switched the AMODE to 31 and didn't switch it back to 24 on return? Kind regards Bernd Am 17.03.2015 um 18:01 schrieb John McKown: > The problem is R2: R2: 4F1D6048 (Storage invalid) > If you have a dump that you can actually look at, see if there is > something "reasonable" at 001D6048. Otherwise, you'll need to try to > backtrack where this value came from. If the data at address 001D6048 > "looks reasonable", then you need to figure out how the high order > byte got set ot x'4F'. > > Well, I know nada about that package. The fact that the CSECT names > all start with @MEM is "suspicious". One question would be what > release of z/OS did it last run on successfully? And I have two > entries you could try with _might_ help. But, then again, they might > not. In the DIAGnn member of PARMLIB, try putting in two lines like: > > VSM USEZOSV1R9RULES(YES) > CBLOC VIRTUAL24(IHALCCA,IHAPCCA) > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2E2B0/31.6 > > and, less likely, in IEASYSnn you might try > > CSCBLOC=BELOW > > I've had really old programs blow up when the CSCB is above the line. > But this can have a negative impart on the use of common memory below > the line. Please read up on this. > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2e2b0/54.8.14 > > The first two can be dynamically adjusted by putting them in a DIAGnn > member of PARMLIB and the issuing the command: T DIAG=nn > The latter requires an IPL to change. > > On Tue, Mar 17, 2015 at 11:12 AM, Jerry Criste > <[email protected]> wrote: >> Hello, >> >> We are experiencing an S0C4 abend after upgrading to z/OS 1.13. The >> application is known as KBMS, has been unsupported since 2000, and is >> critical to the business. We are working on a replacement, but full >> implementation is still several months away. >> >> We have experienced problems with the application in previous upgrades, but >> were able to address it by re-linking some of the programs (we do not have >> the source). Unfortunately that approach is not working this time, so I'm >> hoping someone can explain what might be happening and possible solutions. >> >> Thanks in advance for any insight that is provided. >> > <snip> >> Instructions around point of failure: >> >> Offset Hex Instruction >> ------ -------------- --------------------------------------------- >> -10 90C8 C01C STM R12,R8,28(R12) >> -C 18FC LR R15,R12 >> -A 41C0 C050 LA R12,80(,R12) >> -6 18EB LR R14,R11 >> -4 5820 F000 L R2,0(,R15) >> ***** 5870 2005 L R7,5(,R2) >> +4 D203 F014 7001 MVC 20(4,R15),1(R7) >> +A 5860 F004 L R6,4(,R15) >> +E 1876 LR R7,R6 >> +10 4170 0007 LA R7,7 >> +14 1476 NR R7,R6 >> +16 1277 LTR R7,R7 >> >> Program Status Word (PSW) . : 078D2000 9970FB58 >> >> General Purpose Registers: >> R0: 00030000 (651264 bytes of storage addressable) >> R1: 1970FCD8 (Module AICKBMSE CSECT @MEMFREE + X'0') >> R2: 4F1D6048 (Storage invalid) >> R3: 199DE000 (1069056 bytes of storage addressable) >> R4: 00000000 (2048 bytes of storage addressable) >> R5: 00000001 (2047 bytes of storage addressable) >> R6: 00000000 (2048 bytes of storage addressable) >> R7: 00000001 (2047 bytes of storage addressable) >> R8: 00000008 (2040 bytes of storage addressable) >> R9: 104D6000 (Storage invalid) >> R10: 199C6008 (1167352 bytes of storage addressable) >> R11: 1970FB48 (Module AICKBMSE CSECT @MEMALOC + X'0') >> R12: 199C86D8 (1157416 bytes of storage addressable) >> R13: 9970FE80 (Module AICKBMSE CSECT @MEMZER0 + X'20') >> R14: 1970FB48 (Module AICKBMSE CSECT @MEMALOC + X'0') >> R15: 199C8688 (1157496 bytes of storage addressable) >> >> >> Virtual Storage Map >> AREA >> ADDRESS SIZE >> 64-BIT HIGH PRIVATE AREA 0002000000000000 8191P >> 64-BIT SHARED AREA 0000020000000000 >> 510T >> 64-BIT COMMON AREA 000001EF80000000 >> 67583.9M >> 64-BIT LOW PRIVATE AREA 0000000880000000 >> 1948.00G >> 64-BIT JAVA AREA 0000000080000000 >> 30720.0M >> ----------------------- 2 GIG BOUNDARY ----------------------- >> EXTENDED PRIVATE AREA 19700000 >> 1641M >> EXTENDED COMMON SERVICE AREA (ECSA) 09C28000 256864K >> EXT MODIFIED LINK PACK AREA (MLPA) 09C27000 4K >> EXT FIXED LINK PACK AREA (FLPA) 09C24000 >> 12K >> EXT PAGEABLE LINK PACK AREA (PLPA) 05848000 69488K >> EXTENDED SYSTEM QUEUE AREA (ESQA) 01B10000 62688K >> EXTENDED NUCLEUS >> 01000000 11328K >> ---------------------- 16 MEG BOUNDARY ----------------------- >> NUCLEUS >> 00FD3000 180K >> SYSTEM QUEUE AREA (SQA) 00EB7000 >> 1136K >> PAGEABLE LINK PACK AREA (PLPA) 00CF8000 >> 1788K >> FIXED LINK PACK AREA (FLPA) 00000000 >> 0K >> MODIFIABLE LINK PACK AREA (MLPA) 00000000 0K >> COMMON SERVICE AREA (CSA) 00A00000 >> 3040K >> PRIVATE AREA >> 00006000 10216K >> PREFIXED SAVE AREA AND SYSTEM 00000000 >> 24K >> ---------------------------------------------------------------------- ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
