We have received the OPS1094J message on several occasions, indicating the rule took over 45 seconds to execute for a message rule we have that processes all highlighted messages. Usually the rule never takes more than a second to execute otherwise. On all 3 occasions where it ran long, it indicated the processing hung on the same line, which simply contains a variable assignment which includes a TRANSLATE call:
txt = TRANSLATE(txt," ","'")
How cpuld a rule possibly repeatedly timeout on a such a line if it is not in any sort of visible loop?
OPS/MVS R13.5 and newer
Customer using rules with )MSG *
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 continual firing of the rules 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:
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, should accessing an RDF table from a )MSG * rule need to be continued.
Also, ensure that hiper fix LU01174 is applied if running OPS/MVS release 13.5. All other releases should not require any PTFs.