Message Table

Table 1. Description of <msgitem> classes required for all message explanations
Class	Description
"explanation"	Explains the message. Can include message variables, paragraphs and other formatted text - see Special formatting tags for the message table. For an exception message, the explanation should describe the exception condition found and its impact to the system. For the informational report title message, the explanation must include the meaning of the variables used in the message text that are not self-explanatory within the explanation. For example, if you use <mv>`widget`</mv> within the message text, you must then explain what the variable in the explanation, as follows: `widget` An important device you need to buy for your computer. `widget` will be one of the following: widgeta Type a widget widgetb Type b widget
"sysact"	The system action describes what the system, in particular the component that owns the check, is doing as a result of the condition that caused the message to be issued. The system action must be specific - you cannot enter a system action of 'n/a' or 'None'. The system always does something, even if it just continues processing.
"oresp"	Operator response describes the actions an operator should take in response to the message. For exception messages, this should direct the operator to the right person to evaluate the exception. for example, "Contact the system programmer:" For other messages, which do not appear on the operators console, 'n/a' is the correct operator's response. The operator response can also be 'n/a'.
"spresp"	System programmer response describes the actions, if any, the system programmer should take to isolate and correct an error, including diagnostic steps and reporting the problem to the IBM® support center. Include sample syntax and references for changing system parameters or issuing commands. Include a reference to the problem determination category if you're using the probd class for additional information for the system programmer. "Spresp" can also be 'n/a'.
"probd"	Problem determination - communicates additional information or actions that a system programmer, system administrator, security administrator, or database administrator may need to know to further diagnose a problem discussed in the system programmer response, including trace or dump information. Provide cross references (including links to other books) to procedures - different dumps use different allocations, procedures, and resources. Probd can also be 'None'.
"source"	The name of the component, subsystem, or product issuing the message.
"automation"	Automation - Use this section to discuss automation concerns related to the check results. Specify 'n/a' if you have no automation information for a message.
"refdoc"	Use the reference documentation class to reference books that provide additional detail regarding suggested settings or interpreting results. Include the book title, chapter heading, and section heading. Specify 'n/a' if you have no reference information.
"module"	Module identifies the name of the detecting module, the component name, or N/A. This class is not included in the message buffer for an exception message.
"rcode"	Routing code. Specify N/A for this field, because Health Checker for z/OS® does not use a routing code, so this value is always zero unless the installation overrides the value in the HZSPRMxx parmlib member values for the check. Rcode is not included in the message buffer for an exception message.
"dcode"	Descriptor code. For an exception message, document the default descriptor code based on the severity of the check: High severity checks use a descriptor code of 11 Medium severity checks use a descriptor code of 3. Low severity checks use a descriptor code of 12. See Defining your own symbols for check messages. The installation can override the severity and descriptor code in the HZSPRMxx parmlib member. Dcode is not included in the message buffer for an exception message. For a non-exception message specify N/A for this field.