Creating the message input for your check
Check messages are the output of your check routine - they communicate
the results uncovered by a check to the user. Your check messages
should:
- Report any exceptions to the values and settings the check is looking for and convey recommendations for actions to take to correct the exception. Depending on what the check is designed to do, an exception message may report risks to system performance, function, availability, or integrity. A check should also report dynamic changes since the last IPL that pose a potential problem, and which might make the next IPL slower or prone to errors.
- Report that the check found no exceptions, if appropriate.
- If the setting the check is looking for conflicts with existing default settings, explain why the check user is getting an exception message for a default setting.
- Create report messages that displays data that the check collects.
This chapter covers how to create a message table for
your check. However, you can also omit the message table and issue
messages directly from the check routine as follows:
- For local or remote checks, use HZSFMSG REQUEST=DIRECTMSG, providing the message text in the HZSFMSG REQUEST=DIRECTMSG request. See HZSFMSG macro — Issue a formatted check message.
- For REXX checks, use HZSLFMSG_REQUEST='DIRECTMSG', providing the message text in the HZSLFMSG_REQUEST='DIRECTMSG' input variables. See Input variables for HZSLFMSG_REQUEST='DIRECTMSG'.
For more information, see our fabulous Redpaper™! For lots of details and experience based information about creating messages for your check, see Exploiting the Health Checker for z/OS infrastructure (REDP-4590-00).
To create a message table for your check, you must do the following:
- Plan your check messages to be easy to understand, use, and automate. See Planning your check messages.
- Create a message table that contains both message texts and explanations for checks. See Creating the message table.
- Optionally create a setup data set customized for your checks. The setup data set contains entries for symbols, frequently used text strings used in messages, and for the books you reference in your message explanation. (Every message must contain a reference to a book for more information.) See Defining your own symbols for check messages
- Generate the messages into a compilable assembler CSECT using a JCL procedure using the HZSMSGEN REXX exec. The HZSADDCHECK exit routine passes the name of the message table for a check to IBM Health Checker for z/OS. See Generating the compilable assembler CSECT for the message table.
- Compile the message CSECT to create the message table module, which you will ship with the compiled check routine and HZSADDCHECK exit routine, if you have one for the check. Make sure that you link edit the message table as reentrant. In addition, Make sure that the message table is in a single separate module, rather than mainline code, to make maintenance and corrections easier. For local and REXX checks, the system loads the message table into IBM® Health Checker for z/OS® private storage. Remote checks must load their message table into their own address space's storage.
- From your check routine:
- Remote checks must load the message table into their own storage.
- Define the variables for your messages. In your check routine, you will define and store message variable data into the HZSMGB data area. See Defining the variables for your messages. You can have up to 20 message variables per message, each used one time only.
- Use the HZSFMSG macro to issue messages . See Issuing messages in your local check routine with the HZSFMSG macro.
The following figure shows how all the parts fit together in the
process of creating a message table:
Figure 1. Inputs and outputs for creating a complete message
table