Controlling check exception message WTOs and their automation consequences

By default, IBM® Health Checker for z/OS® issues DOM requests to delete any check exception message WTOs left behind from previous check iterations. It does this DOMing before the start of the new check iteration. That means that each time the check generates an exception, it also sends a new exception WTO, which also kicks off any automation actions you've set up for your installation.

So, what if you want more control over check exception WTOs and their automation consequences? For example, let's say you have a check that runs every hour. Now let's say that your check begins generating identical exceptions that you've automated on to prompt a beeper call to your favorite system programmer. You have not yet resolved the exception issue, and the installation policy is to not disable checks generating exceptions. That's just good practice, right? And yet your check might generate a lot of WTOs and beeper calls to that poor system programmer while the issue gets resolved.

That's where DOM control comes in! Starting with z/OS V1R13, IBM Health Checker for z/OS you can use the following functions that help you control whether you want to suppress WTOs and any automation actions they trigger for a check that is generating exceptions:

Add your check to the product using the DOM(CHECK) parameter on the HZSPRMxx and MODIFY hzsproc command. See ADD or ADDREPLACE CHECK parameters in Syntax and parameters for HZSPRMxx and MODIFY hzsproc.
From your check you decide when to DOM WTOs from previous check runs using the HZSFMSG REQUEST=DOM macro (HZSFMSG macro — Issue a formatted check message) or the REXX HZSLFMSG_REQUEST='DOM' function HZSLFMSG function.

Realizing the benefits of this function is all in the timing:

If your check (added with DOM(CHECK)) is generating multiple identical unresolved exceptions, your check can wait to DOM the exception WTO (with HZSFMSG REQUEST=DOM or the REXX HZSLFMSG_REQUEST='DOM' function) until the exception condition is resolved. This way, your check is still running, but the exception WTOs from previous iterations of the check do not get DOMed. That means that exception messages from this check are just recorded in the message buffer and not sent as WTOs that set off automation actions.
If your check is running successfully and is not generating an exception in a check iteration or is generating different check exceptions between iterations, your check should issue HZSFMSG REQUEST=DOM or the REXX HZSLFMSG_REQUEST='DOM' function to DOM WTOs from previous iterations. That way any subsequent exception will be sent as a WTO and will kick off any defined automation actions.

On the other hand, if you always want to delete WTOs for your check, and never wish to suppress duplicate exception WTOs, you will want to specify or default to DOM(SYSTEM) when you add your check, and let the system take care of DOMing of check WTOs for you!