This section only covers using the HZSFMSG macro to issue a message, but a message also consists of a few other ingredients. When your check runs, the system assembles the message from the following:

• The actual text and explanation for your check messages are defined in your message table, see Issuing messages in your local check routine with the HZSFMSG macro.
• The variables for your check messages are defined in the HZSMGB data area from your check routine. See Defining the variables for your messages.

Note that you can omit the message table and issue messages directly from the check routine in one of the following ways:

• For local or remote checks, use HZSFMSG REQUEST=DIRECTMSG. See HZSFMSG macro — Issue a formatted check message.
• For REXX checks, use the REQUEST='DIRECTMSG' subfunction of the HZSLFMSG function. See Input variables for HZSLFMSG_REQUEST='DIRECTMSG'.

You can issue the following kinds of messages in your check routine:

• Exception messages and other check results messages (CHECKMSG or DIRECTMSG request). For an overview of the various message types, see Table 1.
• IBM Health Checker for z/OS messages (HZSMSG request)
• IBM Health Checker for z/OS messages that indicate that the check is stopped (STOP request). If your check routine issues HZSFMSG with the STOP request, it prompts the system to call the delete function code for the check.

You can issue a particular message multiple times in a single iteration of a check - a check routine should always issue an exception message to report an error.

For a remote check, the HZSFMSG macro call must:

• Specify REMOTE=YES
• Specify the handle that identifies the check to IBM® Health Checker for z/OS® on the HANDLE parameter. The system assigns and returns the handle to the remote check when the check issues the HZSADDCHK macro to define the check to the system. See Issue the HZSADDCK macro to define a remote check to IBM Health Checker for z/OS.
• Specify the location of the message table for the check in the MSGTABLE parameter. (Local checks do not have to specify the location of the message table because both the check and the message table are in the IBM Health Checker for z/OS address space.)

  Note that a remote check must also load the message table into storage.

For example, a remote check might issue a check exception message with the following HZSFMSG macro call:

HZSFMSG REQUEST=CHECKMSG,MGBADDR=Addr_Of_MGB1, 
      MGBFORMAT=1,                             
      REMOTE=YES,HANDLE=CK_Handle,             
      MsgTable=Addr_Of_MsgTable,                          
      MF=(E,HZSFMSG_List)                      

Check messages are important because they report the results of the check to an installation. Each check should issue at least:

• One or more messages for any exception found to the setting the check is looking for.
• A message indicating that no exceptions were found, when appropriate.

If an HZSFMSG macro call is incorrect, the system issues system abend X'290' with a unique reason code and creates a logrec error record. The system checks the following for each HZSFMSG call:

• To see that the HZSMGB data area (input to checks describing message identifiers and variables) is complete
• That the message is in the message table
• That the number of inserts provided on the call exactly matches the number required to complete the message
• That each variable definition is between 1-256 characters long

The reason codes for system abend X'290' describe the message error. See z/OS MVS System Codes.

HZSFMSG updates the PQE_Result field in the HZSPQE as follows:

• For a specified severity of HIGH, the system sets the check result to 12
• For a specified severity of MEDIUM, the system sets the check result to 8
• For a specified severity of LOW, the system sets the check result to 4

PQE_Result is set to 0 when the check is called. See Examples.