OPSMVS : ABEND S0C4 in module OPINMA starting the product

Products

• OPS/MVS Event Management & Automation

Issue/Introduction

In the CA OPSMVS Installation Guide it is documented that there are two CA OPS/MVS® Event Management and Automation (CA OPS/MVS) load libraries:

- the CCLXLOAD that contains the majority of the product modules. By default, this is a standard PDS and must always be APF authorized.
- the CCLXPLD that contains those load modules that must reside in a PDSE. This load library must also be APF authorized if the Switch Operations Facility (SOF) is used. It is recommended anyway to make also this loadlib APF authorized  regardless of the features that are currently installed.

It can happen that, trying to start OPSMAIN task, it abnormally ends with code S0C4 in module OPINMA, with the following messages: 

IEF403I OPSMAIN - STARTED - TIME=07.43.31 
IEF196I IEFA111I OPSMAIN IS USING THE FOLLOWING JOB RELATED SETTINGS: 
IEF196I SWA=BELOW,TIOT SIZE=32K,DSENQSHR=DISALLOW,GDGBIAS=JOB 
IEF196I IEF236I ALLOC. FOR OPSMAIN OPSS 
IEF196I IGD103I SMS ALLOCATED TO DDNAME SYSPROC 
IEF196I IGD103I SMS ALLOCATED TO DDNAME SYSEXEC 
IEF196I IGD103I SMS ALLOCATED TO DDNAME 
IEF196I IGD103I SMS ALLOCATED TO DDNAME 
IEF196I IEF237I DMY ALLOCATED TO SYSTSIN 
IEF196I IGD101I SMS ALLOCATED TO DDNAME (SYSTSPRT) 
IEF196I DSN (SYS18172.T074331.RA000.OPSMAIN.TEMP.H01 ) 
IEF196I STORCLAS (SCWORK) MGMTCLAS ( ) DATACLAS ( 
IEF196I ) 
IEF196I VOL SER NOS= PWK008 
IEF196I IEF237I DMY ALLOCATED TO OPSAEX 
IEF196I IEF237I DMY ALLOCATED TO CAHBEXCL 
IEF196I IEA995I SYMPTOM DUMP OUTPUT 
IEF196I SYSTEM COMPLETION CODE=0C4 REASON CODE=00000004 
IEF196I  TIME=07.43.31 SEQ=31176 CPU=0000 ASID=0245 
IEF196I  PSW AT TIME OF ERROR 078C2000 A71020D6 ILC 6 INTC 04 
IEF196I    ACTIVE MODULE ADDRESS=00000000_27100000 
IEF196I    OFFSET=000020D6 
IEF196I    NAME=OPINMA 
IEF196I    DATA AT PSW 271020D0 - D503C318 5000A784 003CD507 
IEF196I    AR/GR 0: 00000000/00001C48 1: 00000000/7F6C1898 
IEF196I          2: 00000000/00006F80 3: 00000000/223F0830 
IEF196I          4: 00000000/223F1060 5: 00000000/00000810 
IEF196I          6: 00000000/009E1FC8 7: 00000000/00F76880 
IEF196I          8: 00000000/009FC900 9: 00000000/009FEA08 
IEF196I          A: 00000000/27104000 B: 00000000/7F6C16A4 
IEF196I          C: 00000000/2710201C D: 00000000/7F6C16C8 
IEF196I          E: 00000000/A7102166 F: 00000001/00000000 
IEF196I  END OF SYMPTOM DUMP 
00281 IEA995I SYMPTOM DUMP OUTPUT 415 
...

Is it possible to make any correction in the product setup in order to have OPSMAIN task starting correctly? 
 

Environment

Z/OS - OPSMVS 

Resolution

Looking at the OPSMAIN complete joblog messages, the following can be researched and evidenced:
... 
0 IEF196I XX* 
0 IEF196I 11 XXOPSAEX DD DUMMY 
0 IEF196I USING OPSAEX FROM LPA 
0 IEF196I 12 XXCAHBEXCL DD DUMMY 
... 
IEF196I IEF237I DMY ALLOCATED TO OPSAEX 
IEF196I IEF237I DMY ALLOCATED TO CAHBEXCL 
IEF196I IEA995I SYMPTOM DUMP OUTPUT 
IEF196I SYSTEM COMPLETION CODE=0C4 REASON CODE=00000004 
IEF196I  TIME=07.43.31 SEQ=31176 CPU=0000 ASID=0245 
IEF196I  PSW AT TIME OF ERROR 078C2000 A71020D6 ILC 6 INTC 04 
IEF196I  ACTIVE MODULE ADDRESS=00000000_27100000 
IEF196I  OFFSET=000020D6 
IEF196I  NAME=OPINMA 
IEF196I  DATA AT PSW 271020D0 - D503C318 5000A784 003CD507 
IEF196I  AR/GR 0: 00000000/00001C48 1: 00000000/7F6C1898 
IEF196I        2: 00000000/00006F80 3: 00000000/223F0830 
IEF196I        4: 00000000/223F1060 5: 00000000/00000810 
IEF196I        6: 00000000/009E1FC8 7: 00000000/00F76880 
IEF196I        8: 00000000/009FC900 9: 00000000/009FEA08 
IEF196I        A: 00000000/27104000 B: 00000000/7F6C16A4 
IEF196I        C: 00000000/2710201C D: 00000000/7F6C16C8 
IEF196I        E: 00000000/A7102166 F: 00000001/00000000 
IEF196I  END OF SYMPTOM DUMP 
00281 IEA995I SYMPTOM DUMP OUTPUT 415 
.... 

So, in OPSMAIN task procedure the ddname

//OPSAEX DD DUMMY 

is specified and this is telling OPSMAIN to look in LPA for module OPSAEX to be used. 
This is documented in The Installing Guide section: 

LPA Usage Efficiency 

To achieve the most benefit from LPA usage, copy CA OPS/MVS module OPSAEX into an LPALST library. By doing this, you are enabling OPSVIEW and all of the CA OPS/MVS command processors to execute more quickly and to share common code. This can reduce the overall demand for real storage and paging. 
If you decide to place the OPSAEX load module in the LPA, you can allow the main address space to share many of the modules that OPSAEX contains. If you choose to do so, add the following DD card to the OPSMAIN JCL: 

//OPSAEX DD DUMMY 

Doing this reduces the amount of ECSA used by the main product address space by approximately 400 KB when OPSAEX resides in the LPA. If you omit this ddname, then the main address space makes no attempt to share OPSAEX, even if it resides in the LPA. 

An abend S0C4 in module OPINMA with the above setup, can occur if there is a library defined in LPALSTxx that contains a version of OPSAEX module that is different from the one eventually present in the OPSMVS loadlib (usually in LNKLSTxx) of the task that has abended and this can happen if the  module has been changed due to maintenance or new release installation.
To simply check if this is the case, it is possible to restart the failing task removing the ddname 

 //OPSAEX DD DUMMY

and check that now it goes up correctly because the task will use the OPSAEX module present in its loadlib and not the one loaded in LPA.

If this solves the problem then it will be necessary to update the LPALSTxx to reflect the new loadmodule version actually in the OPSMVS loadlib and plan an IPL to refresh the environment correctly.
 
In any other case in which this suggestion doesn't solve the problem, Please collect the appropriate log and system dump and open a case with Broadcom Support.