Evaluating check output and resolving exceptions

The best way to use IBM Health Checker for z/OS is to run it continuously on your system. But you must also evaluate check output, and resolve check exceptions. The check exceptions will give you both the reason for the exception and the steps to take to correct it. In the course of evaluating exceptions, you may need to review the exception with a number of different people in your installation with the expertise in the appropriate field. Resolving check exceptions will be an installation-specific process, and you'll need to develop efficient ways to respond. See also Approaches to automation with IBM Health Checker for z/OS.

Once you have evaluated a check exception, you can resolve it in one of the following ways:

Update your system as suggested by the check exception message, which is the recommended approach. Then you will no longer receive the exception message when the check runs again. You can verify that you have resolved the exception by running the check again (R action character in SDSF or F hzsproc,RUN,CHECK=(checkowner, checkname) and then looking at the output in the message buffer. The check exception message will be gone from the output if you have resolved the exception.
Evaluate the parameters specifying the value or values that the check is looking for. If a parameter is not appropriate for your system, update it so that you will no longer receive an inappropriate exception message when the check runs. You will also want to evaluate and possibly update the severity of the check to make sure it is appropriate for your installation. See Managing checks.
Ensure that the check will not run and produce exceptions by either:
- Putting the check into the Inactive state
- Deleting the check
See Understanding check state and status

It is very important that you resolve exception messages, so that when checks run at their specified intervals, they will report only exceptions that require attention. Otherwise, your IBM Health Checker for z/OS output may contain a mixture of messages that you regularly ignore and those reflecting a new potential problem. This might make it more likely that you could miss a key exception message.

Messages for individual checks will be documented in the component or product owning the message. For information about checks, including the name of the document where a check's messages are documented, see IBM Health Checker for z/OS checks.