We have a REXX that kicks off to swap the OPSLOG whenever the log approaches wrap condition message is generated. On occasion we get a RC=144 from this process.
OPS3445O OPSLOG message number approaching "wrap" condition
OPS3724T TSO MSG.OPS3445O Sent CMD=OI SWOPSLOG
OPS3092H OI SWOPSLOG
OPS1370H OPSOSF X'0000' X'0000' X'0000' NONE 300 AUTOLG01 OPSLOG
AUTOLG01 OPSLOG - Log Name is: OPSLOG status is L
OPS1370H OPSOSF X'0000' X'0000' X'0000' NONE 300 AUTOLG01 OPSLOG
AUTOLG01 OPSLOG - Log Name is: OPSLOG2 status is N
OPS3092H RC = 0
OPS1370H OPSOSF X'0000' X'0000' X'0000' NONE 300 AUTOLG01 OPSLOG
OPS3724T TSO SWOPSLOG Sent CMD=OI APEMAIL K 128
AUTOLG01 OPSLOG - Command RESET issued to OPS Log: OPSLOG2
OPS3092H OI APEMAIL K 128
OPS3092H RC = 144
OPS1370H OPSOSF X'0000' X'0000' X'0000' NONE 300 AUTALERT Problem
OPS3724T TSP FORMALRT Sent CMD=PUTALERT K@19431
OPS3092H PUTALERT K@19431
OPS/MVS
The 144 error indicates " A SETLIVE command failed because of an internal lock failure."
This can be caused by issuing the SETLIVE(opslog) before the RESET(opslog) command has completed. Depending on the size of the log the RESET command can take several seconds. The recommendation is, therefore, to add an OPSWAIT in between the RESET and the SETLIVE commands. The format is:
a=OPSWAIT(n) where n is a time value in seconds.
In the OPS/MVS Event Management sample member **.CCLXSAMP(OPS34450) the OPSWAIT value is set to 30 seconds.
Once an event such as this has occurred, verify that the secondary OPSLOG is still active via the OPSLOG Control Panel (=4.13). The following commands can be used to activate and make live the secondary OPSLOG:
A - Activate a defined OPSLOG
C - Create and allocate a defined OPSLOG
D - Delete a defined OPSLOG
I - Deactivate a currently active OPSLOG
L - Make a currently active OPSLOG the "live" OPSLOG
N - Create a new OPSLOG definition
R - Reset an active OPSLOG.
S - Select an OPSLOG definition for detail display