Guessing you are wanting to identify critical or action WTOs/messages issued on the system, ideally to determine if any automation is currently taking place on the 'action' message, or determine if no automation is firing at all. The COLOR OPSLOG field is not going to give you this information, nor is a rule that does anything with the msg.color AOF variable. The msg.color variable is used in a )MSG xxxx rule that you create that would set the color of that xxxx message as you want it to appear in the OPSLOG using the OPSCOLOR function. Thus, if you want xxxx messages to be RED in the OPSLOG you would code a )MSG xxxx rule that does msg.color = OPSCOLOR('RED'). This would then cause xxxx to be RED in the OPSLOG and you could also filter in the OPSLOG using the COLOR field. A red action WTO messages from the system or jobs/STCs on the system, are controlled by the descriptor code of the WTO being generated, specifically DESC codes 1,2 (red,white by default MPF settings). Meaning, the filter of RED in COLOR field will not show these RED WTO system messages. To quickly identify the system action messages that are not being automated with an 'action' (issuing a command, call a REXX,send a WTO,etc) you can use the recently new DEFAULT rules (AOF rule type of )DEF)...Refer to the doc on DEFAULT rules for MSG events for details. There is a sample on a )DEF MSG rule that stores these events in an RDF table, but the logic to me is to 'over the top'. Start with a quick DEFAULT message rule:
)DEF MSG
)PROC
msg.user = 'ACTNMSG'
This enabled rule would set the msg.user field to 'ACTNMSG' for any system action message (red,white,wtor) that does not have any rules doing a valid OPS/MVS action (refer to doc). You can then set the USER field in the OPSLOG profile to filter on the ACTNMSG user fields to quickly show the urgent system WTOs that no actions are occurring. Keep in mind DEF rules will of course identify only events that no action automation is occurring. If you want to begin identifying all urgent WTOs (even ones that have action rules coded on them), then you would need a )MSG * rule to take a peak at the AOF variables (msg.urgent, msg.wtor,msg.immedact) and set the msg.user field. Take a look at the yourOPShlq.CCLXRULS(ACTNMSGS) sample for an idea on this rule. )MSG * rules are completely valid/safe, but you need to limit them (one or two), AND the logic cannot be 'robust' (SQL, some loop, etc).