OPSLOG is corrupted and unable to allocate OPSLOG2

book

Article ID: 208233

calendar_today

Updated On:

Products

CA OPS/MVS Event Management & Automation

Issue/Introduction

The OPSLOG is corrupted, is no longer rolling, the message envents are not ordered by team, we can see how message events get overwritten, archiving is no longer working.

 

The current BROWSECHECKNUM volume is 2147482983

We attempted to create a new OPSLOG but without success it statyed as PendingActivation in menu 4.13 and could not be changed to Live. We followed the following article:

https://knowledge.broadcom.com/external/article/130384/opsmvs-abend-xc3000-opslog-browsechecknu.html

Later we also re-started OPS/MVS but the issue persisted. Before the re-start we updated the OPSSPA00 at PARMLIB to define a new OPSLOG as:

secondary_OPSLOG_dsn       = 'SYSC.OPSM.'smfid'.OPSLOG2'
secondary_OPSLOG_browsemax = '2950000'                  
address Opsctl                                          
"OPSLOG Define(OPSLOG2) Dsname("secondary_OPSLOG_dsn")",
           "Browsemax("secondary_OPSLOG_browsemax")"    

After the restart we only saw the old OPSLOG defined, and do not see the new OPSLOG2.

 

Environment

Release : 13.0

Component : OPS/MVS

Resolution

n the OPSSPA00 member, comment out the following line if using the secondary OPSLOG.  If as it is below, the secondary allocation is completely skipped by the Signal statement sending the next instruction to the set_common_parms area of the code.  This is documented in the "flowerbox" comments immediately following the line:

 

signal set_common_parms                                                        

                                                                                

allocate_secondary_OPSLOG:                                                      

/*--------------------------------------------------------------------*/       

/* Allocate the secondary OPSLOG. Having a secondary OPSLOG defined   */       

/* and active serves as a 'backup' in the event allocation failures   */       

/* occur for the primary OPSLOG. Additionally, as the primary OPSLOG  */       

/* nears its internal wrap condition, OPSLOG recording can be switched*/       

/* to the secondary or 'backup' OPSLOG to avoid CA-OPS/MVS outages.   */       

/* If a secondary OPSLOG is desired, the 'signal_set_common_parms'    */       

/* REXX statement just prior to this routine must be deleted to allow */       

/* this logic to execute.                                             */