ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.

What causes OPS1094J message on a rule?


Article ID: 221999


Updated On:


OPS/MVS Event Management & Automation


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?


Customer using rules with )MSG *  


Release : 13.5

Component : OPS/MVS


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

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.