40+ Message rules with )MSG * ?

[Steve Ives]

So fairly new at this site and just been exposed to another LPAR, which has 42 Op/MVS rules that specify )MSG *

 

I'm not sure yet what they do, but I know that one of then looks up the message id in an RDF table and if it's there simply suppresses it, others are looking for 4 or 5 particular messages, others checking every message against an RDF table to see if it needs to raise a problem ticket. This one also pulls in snippets of REXX code from the RDF table for some custom processing.

 

This just seems really inefficient - if I can, should I set myself a task to go through these one-by-one an eliminate or re-code them if possible? 

 

Fortunately some of them do try to limit their impact - for example., one has 'FIRELIMIT=60000' coded, so it limits itself to 'only' 1,000 firings/second. Yay. 

 

For example, the ones for message suppression and raising problem tickets - I could read the RDF table at Ops/MVS startup and generate a dynamic rule for each specific message, which I imagine would be more efficient.

 

Thanks for any advice/feedback.

[Carlos Filho]

Hi Steve,

 

Having these catch-all rules is not a good practice. I suggest that you create normal suppression rules instead of reading the RDF table and creating the rules dynamically. Although the creation of normal rules will demand more manual work at first it will save processing at each IPL for the reading of the table and creation of the dynamic rules.

 

Regards,

Mario

[Marcel van Ek]

Yes that seems fairly inefficient.

I wonder how many entries there are in that table.   As we're mainly using MPF for simple suppression, and that member has over 15000 entries (and those include wildcards!).

Would not want to do that with a table , or even dynamic rules ....

 

Marcel

[Steve Ives]

The 'supression' RDF table has 2500 entries...

[Legacy User]

The more )MSG * rules you have, the slower your system will run. This will definitely have an impact on performance.

One of the benefits of looking up an RDF table before deciding what to do is that you can dynamically update the table without doing any new coding. It's usually going to be far more efficient to hard-code individual suppression rules.

We only have one )MSG * rule, with exit points as early in the code as we can manage. It does mean we can get away with NOFIRELIMIT, so nothing is missed. I'd leave that until you're sure it's stable.