What is supposed to be at the 4 bytes beginning at the virtual storage address that is X'C12' bytes greater than the contents of R12? The other half of the CLC instruction seems normal, but the L instruction just before it looks suspicious. Your code is loading the full word at address X'208' into R12 before the CLC. This address is part of the Prefixed Storage Area (long ago called "low core"). X'208' is the 31-bit virtual address of the PCCA (Physical CPU Communications Area) on which your program is running. On my test system I just looked at address X'208'; it contains X'0214FD90'. This address contains the following EBCDIC eyeball-readable data: C'PCCA0005xxx etc.' The 0005 are the first 4 hex nybbles of the CPU ID. Why would quikjob care what the CPU ID is on which it is running? Does this all this pass the smell test or sanity check for your installation? The PCCA has been at a 31-bit address for a very long time. Please also display the PSW at the time of ABEND. Bill Fairchild
----- Original Message ----- From: "Rex Pommier" <rpomm...@sfgmembers.com> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, April 9, 2014 1:59:34 PM Subject: S0C4 abend on old assembler program when upgrading to z/OS 1.13 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
