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
