What causes OPS1094J message on a rule?

book

Article ID: 221999

calendar_today

Updated On:

Products

CA OPS/MVS Event Management & Automation

Issue/Introduction

We have on 3 occasions received the OPS1094J message indicating the rule took over 45 seconds to execute for a message rule we have that processes all highlighted messages. As far as we are aware the rule never takes more than a second to execute otherwise. On all 3 occasions it has has indicated the processing hung on the same line, which simply contains a variable assignment which includes a TRANSLATE call:

txt = TRANSLATE(txt," ","'")

How can a rule could possibly repeatedly timeout on a such a line if it is not in any loop structures?

Cause

Customer using rules with )MSG *  

Environment

Release : 13.5

Component : OPS/MVS

Resolution

In the associated OPSLOG, at 45 seconds prior to the OPS1094J, there were several IEA989I messages about an X33E slip trap that matched on the same jobname.  If that ASID was having 'trouble' and the )MSG * rules were firing on it, it's possible that is what caused longer than normal rule processing, although the IEA989I is issued from MASTER.  This may be hard to pinpoint as a )MSG * rule is firing on every WTO.

Please note the following comment from the Best Practices/Using manual, which states:

  • Use )MSG * rules only if absolutely necessary - REMEMBER:  EVERY MESSAGE WILL BE PROCESSED BY THIS RULE

https://techdocs.broadcom.com/us/en/ca-mainframe-software/automation/ca-ops-mvs-event-management-and-automation/14-0/best-practices/best-practices-using.html

The way this is designed, it is understandable that sometimes one instance requires more time to complete.  At this point our recommendation is to add OPTIONS “NOMAXSECONDS” to the rule, and ensure that hiper fix LU01174 is applied for release 13.5, should access an RDF table from a )MSG * rule continue.