Defining your own symbols for check messages

Besides using the predefined system symbols, you can also define symbols specific to the check messages in the message table or setup file. We'll call these local symbols. Keep the following in mind as you plan whether to define local symbols and which ones to define:
  • You should only create a local symbol for a known constant that you use multiple times in the message table.
  • National language support (NLS) variables are not created for check specific symbols, and they do not require special support at execution time.
  • Local symbols can use symbols within symbols. In other words, the symbol substitution text can include other local or system symbols.
Like system symbols, you specify the entity for your local symbol as a name delimited by an ampersand (&) and a semi-colon. For example, you could specify and use local symbols as follows:
  • Create your own symbols for any text you use multiple times in the message table. When you generate the message table, the symbols will resolve to your text value. For example:
    If I insert an entity, or symbol, &newsym;.
    This would resolve to:
    If I insert an entity, or symbol, the symbol resolves to this exciting text.
  • Define your own symbols to make it easier to put accurate book titles in the required <msgitem class="refdoc"> tag for check messages. For example:
    For more information about the recommended settings, see &ieaa100t;.
    This resolves to:
    For more information about the recommended settings, see 
    z/OS MVS Auth Assm Services Reference ALE-DYN.
You can define symbols for your check using <!ENTITY> tags in either:
  • The source message table, before the <msglist> tag. Here's an example of defining symbols in the message table itself:
    <!ENTITY PROD1 "Product ABC"> 
    <!ENTITY PROD2 "Product DEF"> 
    <!ENTITY NA "N/A">
    <msglist xreftext="PRODABC Rules=2">
                        .
                        .
                        .
                 
  • A setup data set, which is a separate data set containing the symbol definitions for your check. This is a handy way to make symbols available for multiple checks. Here's an example of a setup data set with both a copyright statement and some symbols we find very useful for multiple users and multiple checks:
    Figure 1. Example of a setup data set that defines symbols used in the message table
    <!ENTITY cunu100t "z/OS Support for Unicode: Using Conversion Service">   
    <!ENTITY ieaa100t "z/OS MVS Auth Assm Services Reference ALE-DYN">
    <!ENTITY ieaa200t "z/OS MVS Auth Assm Services Reference ENF-IXG">
    <!ENTITY ieaa300t "z/OS MVS Auth Assm Services Reference LLA-SDU">
    <!ENTITY ieae200t "z/OS MVS Initialization and Tuning Reference">
                        .
                        .
                        .
    <!ENTITY act "	The system continues processing.">                  
    <!ENTITY bugmsg "	This message only appears when you are running in debug mode.">
    <!ENTITY repsysp "Report this problem to the system programmer.">
    <!ENTITY lvl2    "Search problem reporting data bases for a fix for the problem.">
    <!ENTITY diagdoc "Provide the messages, the logrec data set record, the SYSLOG output, and dump if one was taken."
    -- The following symbols are defined for routing codes. -- >
    <!ENTITY hisevdc "11 is the default set by this check.">
    <!ENTITY medsevdc "3 is the default set by this check.">   
    <!ENTITY losevdc	"12 is the default set by this check.">
    <!ENTITY success "This check ran successfully and found no exceptions.">

Using either of these methods, the symbols are resolved in the CSECT when you generate the message table.