OPSLOG is corrupted and unable to allocate OPSLOG2
Article ID: 208233
Updated On:
Products
Issue/Introduction
The OPSLOG is corrupted, is no longer rolling, the message events 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 stated as Pending Activation in menu 4.13 and could not be changed to Live. We followed the following article:
OPS3781S ABEND X'000C3000' occurred at OPINBO at various OFFSETs
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
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 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. */
Feedback
