Oppolzer - Informatik / Blog

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 J.M.:
> 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, J.C. 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 listserv@listserv.ua.edu with the message: INFO IBM-MAIN