S106 SVC Dump in OPS/MVS Main task

Products

• OPS/MVS Event Management & Automation

Issue/Introduction

Same as subject, got dump will attempt to send.  Noticed a few other dumps being taken for CICS issues shortly before and afterwards, but do not know if it's related in any way.

Environment

Release : 13.5

Component : OPS/MVS

Resolution

Your OPSMAIN proc looks ok. 

Your OPSLOG shows the OPSMAIN address space was running out of storage, according to these OPSLOG messages: 
=======
before the DUMP was captured, there were many instances of these messages between the time 09:50:38 and 09:51:38, for example, :
09:50:38 8008 OPM3202W GET OF 1048608 BYTES IN SUBPOOL X'E6' ERROR RC=X'00000004' REQUESTED BY   OPRXAO+X'0030B2' 
09:50:38 8048 OPM4301S GETMAIN - RXIN FAILED, RC=4        

then the dump was taken: 

09:51:50 IEW4000I FETCH FOR MODULE OPSAEX   FROM DDNAME -LNKLST- FAILED BECAUSE INSUFFICIENT STORAGE WAS AVAILABLE.    
09:51:50 IEF196I IEW4000I FETCH FOR MODULE OPSAEX   FROM DDNAME -LNKLST- FAILED                                        
09:51:50 IEF196I BECAUSE INSUFFICIENT STORAGE WAS AVAILABLE.  
09:51:50 CSV031I LIBRARY ACCESS FAILED FOR MODULE OPSAEX  , RETURN CODE 14, REASON CODE 26110021, DDNAME *LNKLST*      
09:51:50 IEF196I CSV031I LIBRARY ACCESS FAILED FOR MODULE OPSAEX  , RETURN CODE                                        
09:51:50 IEF196I 14, REASON CODE 26110021, DDNAME *LNKLST*                                                             
09:51:50 CSV028I ABEND106-14  JOBNAME=AOPOMAIN  STEPNAME=AOPOMAIN                                                      
09:51:50 IEF196I CSV028I ABEND106-14  JOBNAME=AOPOMAIN  STEPNAME=AOPOMAIN                                              
09:51:50 IEA045I AN SVC DUMP HAS STARTED AT TIME=09.51.50 DATE=10/29/2020
09:51:50 FOR ASID (0024)                                  
09:51:50 ERROR ID = SEQ37077 CPU00 ASID0024 TIME09.51.50.4
09:51:50 QUIESCE = NO                                     
==========

According to your Local Storage Map in your dump, the free Extened Storage was 471040 bytes.

While it requested more than available according to the message at 09:50:38; also the size of OPSAEX 1866880 bytes is also bigger than available. 

If you have allocated OPSEXEC for your TSO section,  you can go to OPSV =4.1.6 to simulate how your parm setting will affect your storage usage.  The parameters: PROCESS, AOFMAXQUEUE, and AOFSIZE heavily affect the total storage used.

You may consider to reduce the number of process blocks, or the storage that is allocated by all the process blocks. The number of process blocks you specify may use so much virtual storage that CA OPS/MVS fails to function correctly. You can reference this link : https://techdocs.broadcom.com/us/en/ca-mainframe-software/automation/ca-ops-mvs-event-management-and-automation/13-5/best-practices/best-practices-configuration-and-tuning/process-blocks.html

 
The AOFSIZE parameter determines the size of the AOF workspace (used to store REXX variables).
Using several new CA OPS/MVS parameters (AOFWSHIGHUSED, AOFWSHIGHUSEDPGM, AOFWSHIGHUSEDRULE, AOFWSHIGHUSEDDATE, and AOFWSHIGHUSEDTIME), you can trace the maximum amount of workspace that rules have used since CA OPS/MVS was last started. After tracing the levels of workspace use, you may wish to decrease the value of the AOFSIZE parameter if it is set larger than the value of the AOFWSHIGHUSED parameter. You can reference this link : https://techdocs.broadcom.com/us/en/ca-mainframe-software/automation/ca-ops-mvs-event-management-and-automation/13-5/reference-information/parameter-reference/parameters-for-facilities/aof-parameters.html#concept.dita_d5d6042a569245527d10bae661d71b598a58aab3_AOFMAXQUEUEParameter