If you have worked on mainframe, I’m pretty sure that you would have come across the S0C4 abends in your system. When the S0C4 occurs during a file processing, jcls execution etc, its rather easy to spot and correct, as most of these will be for the way the file is accessed, spaces allocated or with file type itself. However when it comes to an IMS transaction or IMS database call it might be a little tricky to find the abend source. So hopefully with this blog I can help you out on where to look for when a S0C4 abend occurs during a IMS call.
Always stick with the thumb rule for S0C4, i.e “the program is trying to access an unobtainable/unallocated/restricted area”. Most of the abends that my team reports are occurring while executing a CBLTODLI call to retrieve a segment from the IMSDB or while switching transaction using CHNG/ISRT/PURG etc. Here the CEEDUMP(dump) that the MPP jobs creates can give you most of the information that you need to find the source of the abend but unfortunately most of us refrain to use the dump and rather go with SYSOUT. In the dump please find for the PCB names used in the DLI call and check if any of the PCB data is displayed as “Invalid address” or “Restricted area”. The PCB’s with such an error will be culprit here. (an example below)
Now check the PSB definition of the program/transaction (You may have to decode the PSB using the decoder utilities that’s available to your organization). Once the PSB is decoded compare the PCB definition with the program’s DLI call. Ensure the number of PCB defined in the PSB is matching with the DLI calls linkage, ensure all the segment accessed by the program is defined in PCB and also check for the PROCOPT for the PCB’s defined and ensure you are using the appropriate ones as needed by the program. In my example above, the S0C4 occurred since PCB for the transaction was trying to access a segment which was not defined in the PSB! Hope this helps.