Any chance this code is running the PCCA/LCCA chain?  The default was CBLOC 
VIRTUAL24 in V1.11 and is CBLOC VIRTUAL31 in V1.13.  Maybe you need to set the 
CBLOC VIRTUAL24(IHAPCCA,IHALCCA) in your DIAGxx member.

> Hi list,
>
> I'm looking for a pair of virtual eyes to help me with a problem that is 
> perplexing about 4 of us here.  We're running z/OS 1.11 and are attempting to 
> upgrade to 1.13.  Here's the scenario:  we have an ancient version of 
> something called quikjob which is a report writer.  Due to some application 
> limitations, we need to keep running this old thing for the foreseeable 
> future, as it is written in 24 bit assembler (and it calls homegrown 24 bit 
> programs) and any newer versions of quikjob are in 31 bit which causes the 
> called application code to choke.
>
> In preparation for the upgrade, I cloned the relevant 1.11 volumes to a test 
> LPAR, made the changes I needed to for the 1.13 upgrade to PARMLIB VTAMLST, 
> and TCPIP etc. and IPLed 1.13 in the test LPAR.  We ran a full test of the 
> 1.13 system and everything came back clean.  Last weekend we IPLed production 
> on 1.13 and ended up backing it out because the quikjob jobs all failed with 
> S0C4 abends.  While attempting to diagnose the problem, we discovered that 
> the abends are not being caused by quikjob calling other modules, as we 
> "wrote" a 1 line quikjob program consisting of the word "end" and still got 
> the failure.
>
> After we backed out, I re-cloned the production LPAR back to test and made as 
> few changes as I could get by with, but I can't get the quikjob program to 
> fail on test and I couldn't get it to work on prod.
>
> Here is a snippet of the code disassembled by dumpmaster:
>
> 00000000_00009748  -10 4B20 C17A        SH    R2,378(,R12)             
> 00000000_0000974C   -C 9140 2174        TM    372(R2),X'40'            
> 00000000_00009750   -8 4710 C04A        BC    74(,R12)        BO       
> 00000000_00009754   -4 5830 0208        L     R3,520                   
> 00000000_00009758    0 D503 3000 C172   CLC   0(4,R3),370(R12)         
> 00000000_0000975E    6 4770 C02C        BC    44(,R12)        BNE/BNZ  
> 00000000_00009762    A 4100 3007        LA    R0,7(,R3)                
> 00000000_00009766    E 47F0 C0C4        BC    196(,R12)       UNCOND   
>
> The program is failing on the CLC statement right in the middle of the 
> snippet.  Here is a dump of the registers at time of failure.
>
> Program QUIKJOB failed with abend code S0C4                            
>         at address 00000000_00009758, offset 1E30 in Program QUIKJOB   
>                                                                        
> Registers at time of abend.                                            
> 0 00000000_0001369C 1 00000000_00009F60 2 00000000_00FD8158 3 
> 00000000_02AF7A08
> 4 00000000_009D89B0 5 00000000_009FF130 6 00000000_009A7FC8 7 
> 00000000_FD000000
> 8 00000000_00007400 9 00000000_009FF3F0 A 00000000_00007400 B 
> 00000000_00009C00
> C 00000000_0000973E D 00000000_00007B54 E 00000000_5F00C2DA F 
> 00000000_0000973E
>
> For my little pea-brain, it appears as though register 3 contains a 31 bit 
> address.  This is further bolstered by the fact that I took a copy of the 
> quikjob program and zapped it by replacing the CLC command with X'0000' to 
> force an abend.  In this case, by running the code on both the 1.13 test 
> system as well as production 1.11 system, register 3 at the time of the abend 
> was either 00F47008 or 00F4A008.
>
> Any suggestions as to what I have missed in bringing up my 1.13 system on 
> production that would cause this kind of behavior?
>
> TIA
>
> Rex
>
> The information contained in this message is confidential, protected from 
> disclosure and may be legally privileged.  If the reader of this message is 
> not the intended recipient or an employee or agent responsible for delivering 
> this message to the intended recipient, you are hereby notified that any 
> disclosure, distribution, copying, or any action taken or action omitted in 
> reliance on it, is strictly prohibited and may be unlawful.  If you have 
> received this communication in error, please notify us immediately by 
> replying to this message and destroy the material in its entirety, whether in 
> electronic or hard copy format.  Thank you.
>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN

Axios Products, Inc.
[email protected]
800-877-0990

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to