OPS/MVS - IGF513I message - MESSAGECURRENT was over the MESSAGEMAX.

Products

• OPS/MVS Event Management & Automation

Issue/Introduction

Encountered an issue that OPS/MVS was down due to MESAGECURRENT was over the MESSAGEMAX.   Why some messages were counted as displayed by OPS/MVS. 

 

 

As shown on the OPSLOG, someone issued a SWAP command on this LPAR (1) via the OPSVIEW =1 panel of another LPAR (2).  However, the command wasn't successful and some IGF* messages were flooding to the system.  And these high amount of messages eventually caused OPS/MVS shutdown itself due to MESSAGECURRNET hit the MESSAGEMAX.  And in fact, no more IFG513I was displayed once OPS/MVS was down.  Why those messages were counted as displayed by OPS/MVS.

 

Please check and advice.   

Environment

Release : 14.0

Component : OPS/MVS

Resolution

Looks like it is related to a looping automation. 

The first IGF513I message is issued by MASTER jobname, this causes GSSMSG.IGF513I rule to fire that invokes a REXX exec named IGF500I, this exec executes and issues the same IGF513I message (text was passed as an argument) which then causes the GSSMSG.IGF513I rule to fire and start the same process over and over: 

OPSS0A00 OPS1370H OPSOSF   X'0000' X'0000' X'0000' NONE  300 IGF513I  
OPSS0A00 IGF513I DEVICE F502 INVALID FOR SWAP - DEV LIB MISMATCH      
OPSOSF   OPS3724T TSO GSSMSG.IGF513I Sent CMD=OI IGF500I IGF513I OPSOS
OPSS08DC OPS3092H OI IGF500I IGF513I OPSOSF N/A DEVICE F502 INVALID FO
OPSS0A00 OPS3092H READY                                               
OPSS08DC OPS1370H OPSOSF   X'0000' X'0000' X'0000' NONE  300 IGF513I  
OPSS08DC IGF513I DEVICE F502 INVALID FOR SWAP - DEV LIB MISMATCH      
OPSOSF   OPS3724T TSO GSSMSG.IGF513I Sent CMD=OI IGF500I IGF513I OPSOS
OPSS0A00 OPS3092H OI IGF500I IGF513I OPSOSF N/A DEVICE F502 INVALID FO
OPSS08DC OPS3092H READY                  

The OPSLOG did not include any Emergency Product Shutdown messages nor the restart of OPS/MVS (which will also indicate what caused an EPS) so we can not determine exactly - but by the pattern in OPSLOG it does appear that the looping automation was the problem. 

Perhaps the IGF513I rule should check the jobname before invoking the REXX OR just change the MSGID of re-issued messages.