KDCMMOD recognizes the following control statements:
CONSTANT | Define constants |
END | Terminate input of control statements |
ENDMSG | Terminate message definition |
GEN | Generate messages for a function unit |
MODMSG | Modify messages |
MSGBASE | Select message group: |
OPTION | Specify name of the message definition file |
Observe the following rules regarding sequence of KDCMMOD control statements:
If used, the OPTION statement must be the first control statement.
The CONSTANT statement must be in the input file before a text definition can refer to it.
The GEN statement must appear in the input file before any associated MODMSG/ENDMSG control statements.
The MSGBASE statement affects all subsequent MODMSG statements.
The END statement must be at the end of the input file.
If an error occurs in a statement for KDCMMOD, the incorrect statement is ignored following output of a corresponding error message (K6xx). This does not terminate the program run.
CONSTANT statement
The CONSTANT statement defines a constant which then can be used in the text definitions of messages.
Operation | Operands |
|
|
constant-name | Denotes the name of a constant and can be up to 8 characters long. Mandatory operand. |
constant-value | Assigns a value to a constant. The value must be specified either in the hexadecimal format (X’......’) or in the printable format ’...’. The maximum length is 50 characters. Mandatory operand. |
Several constants are already contained in the message definition file (see also "Constants of the standard message definition file"). You can find further logical control characters in the VTCSET macro.
END statement
The statements for KDCMMOD are terminated with the END statement. END must be entered as the last statement.
Operation | Operands |
|
Without operands.
ENDMSG statement
A message text definition must be terminated with the ENDMSG statement.
Operation | Operands |
|
Without operands.
The ENDMSG statement must always be on a separate line.
GEN statement
The GEN statement specifies the functional unit for which the messages are to be generated as well as the language in which they are to be generated. The GEN statement may be given only once per program run and must appear before any MODMSG statements.
Operation | Operands |
|
|
function-unit | Name of the function unit for which the messages are to be generated. |
LANG=language-id | |
notes the natural language for which the message texts are to be generated. A language identifier must be specified for which message texts are contained in the message file. Default: GB | |
MODULE=object-module-name | |
Denotes the name of the message module. It corresponds to the MODULE name in the MESSAGE statement of the KDCDEF tool (see openUTM manual “Generating Applications”). Mandatory operand. | |
MODMSG statement
You use the MODMSG statement to modify a message in the functional unit that was specified in the GEN statement. The modifications can be made to the text, the insert and the message destinations. Only those modifications which are permitted under the general framework definition are possible (see section “Destinations of UTM messages”).
Operation | Operands |
|
|
1The operands of the MODMSG statement must be separated by commas. If there are continuation lines in a MODMSG statement, the comma must always appear as the last character in the preceding line (as the continuation character).
3The line prior to [text] must not be terminated by a comma.
msg-no | Indicates which K or P message is to be modified. The message number must be in the message number range of the function unit specified in the GEN command. The message number must be given without the K or P prefix. Mandatory operand. |
BEL= | Indicates whether an audible signal is given when the message is output to the destination STATION or SYSLINE. |
YES | an acoustic signal is triggered. |
NO | no acoustic signal is triggered. Default: NO |
COMPRESSION= | |
YES | Superfluous blanks are removed from the message.YES only takes effect for message outputs that issue message texts. |
NO | Superfluous blanks remain in the message.The default value varies for the different messages. To find out the value set as the default for the individual messages, refer to section "Destinations of UTM messages". Default: framework definition |
EXTEND= | |
YES | The message text is to be output in extended line mode. YES only makes sense for messages that the message destination STATION or SYSLINE is assigned to. |
NO | The message text is not to be output in extended line mode. The default value varies for the different messages. To find out the value set as the default for the individual messages, refer to section "Destinations of UTM messages". |
Message destinations CONSOLE, MSGTAC etc. | |
denotes the message destination to which the message is to be sent (YES) or not sent (NO). Only destinations that are ’permitted’ (+) or declared ’Default’ (D) in the framework definitions may be specified (see table in chapter Destinations of UTM messages. The basic definitions apply to all message destinations that are not specified in the MODMSG command. To assign the user-specific message destinations USER-DEST-1,..., USER-DEST-4 to the concrete message destination, you have to use the KDCDEF statement MSG-DEST. You will find detailed descriptions of the various message destinations on "Message module, message definition file". | |
text | In the MODMSG statement, a new message text can be defined. If no new text is defined, then the text as described in the chapter "UTM messages" applies. A new message text is defined in one or more lines. It consists of a series of text elements separated either by commas or end-of-line characters. Text = text-element,text-element,..... The first text element must always occur in a new line. Length restrictions The message text, including the message number and any inserts which may be present, must not exceed 512 characters in length. For the lengths of the inserts, refer to the table "Message inserts". If the text is longer than 512 characters, KDCMMOD rejects it with message K686. The message definition is not then updated. Message texts having the message destination SYSLINE (=systemline) must not exceed 80 characters in length. If the text is longer than 80 characters, KDCMMOD gives a warning with message K687. On output, longer messages are limited to 80 characters and the excess is truncated. |
The following text elements can be used:
Literal | A literal is a character string enclosed in single quotes. Double quotes in a literal are used to designate a single quote in the literal. |
Insert | The text element insert is the name of a field (insert) in the message text that is preceded by the "&" character. Only field names (inserts) that are specified in the framework definition of the corresponding message may be used in the text. These field names are listed in section “Destinations of UTM messages”. Insert fields are parts of the message texts into which actual values are inserted before the message is output. |
Constant | The text element constant is the name of a constant which is preceded by the "#" character. |
| Built-in function | |
The text element built-in function is a function that is executed at the point in question. The following built-in function is available: MSGID This function returns the character string for the message identifier which corresponds to the message number. | |
Each MODMSG command must be terminated with an ENDMSG statement.
MSGBASE statement (only for FU SYS)
openUTM makes a distinction between two message groups within FU SYS: Messages of the UTM group, which start with the letter K, and messages of the XAPTP group, which start with the letter P.
The MSGBASE statement allows you to select the message group to which subsequent MODMSG statements are to apply within the SYS functional unit.
Operation | Operands |
|
|
UTM | Default; select the UTM message group (K messages). |
XAPTP | Select the XAPTP message group (P messages). |
OPTION statement
The OPTION statement is used to define the name of the message definition file which the KDCMMOD tool is to process.
Operation | Operands |
|
|
filename | Name of the message definition file to be processed. |
If the OPTION statement is omitted, the file SYSMSH.UTM.070.MSGFILE in used.
Example 1
The user wishes to assign the destination MSGTAC for message K006 but otherwise retain the unchanged messages with English texts.
The following procedure provides the ASSEMBLER source file for the desired user-specific message module where the message definition file is called SYSMSH.UTM.070.MSGFILE and the KDCMMOD is contained in the SYSLNK.UTM.070.UTIL library:
/BEGIN-PROCEDURE LOGGING=N /ASSIGN-SYSDTA TO=*SYSCMD /ASSIGN-SYSLST TO=LIST.KDCMMOD /START-EXECUTABLE-PROGRAM FROM-FILE=*LIB-ELEM(LIB=SYSLNK.UTM.070.UTIL,ELEM=KDCMMOD) OPTION MSGFILE=SYSMSH.UTM.070.MSGFILE GEN SYS,LANG=D,MODULE=KCSMSGSD MODMSG 6, MSGTAC=YES ENDMSG END /ASSIGN-SYSDTA TO=*PRIMARY /ASSIGN-SYSLST TO=*PRIMARY /END-PROCEDURE
As a result of the procedure, the KDCMMOD tool generates the ASSEMBLER source file SRC.ASSEMB.KCSMSGSD. This file must be assembled, the result of the assembly being an object module with the name KCSMSGSD, which contains the user-specific messages.
In order for a user-specific message module to be used, the statement MESSAGE MODULE=KCSMSGSD, LIB=... must be included in the generation with KDCDEF.
Example 2
In the example below the message destination, a message property, and the message text of message K070 are modified.
GEN SYS,LANG=GB,MODULE=KCSMSGSD MODMSG 070, COMPRESSION = NO, SYSOUT = YES MSGID, ' User signed off: ', &USER, ', CPU-time: ', &CPTM ENDMSG END