OPSMVS : ABEND S0C4 in module OPINMA starting the product
Article ID: 103067
Updated On:
Products
CA 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?
- 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 CA Support.
...
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 CA Support.
Feedback
Powered by
