Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

MESSAGE - define a UTM message module

The MESSAGE control statement allows you to incorporate user message modules in the configuration. It is possible to use a separate user message module to adapt the message texts and/or the message destinations of individual messages to suit your requirements.

For more information on message modules see also section "UTM messages" in this manual and the openUTM manual ”Messages, Debugging and Diagnostics”.

Generating message modules on BS2000 systems

In order to internationalize the application, it is possible to create several user message modules which output the UTM messages of an application in the appropriate language.

The respective language environment can be defined for a user message module by means of a locale, i.e. a unique pair of language and territorial identifiers. The language-specific message modules are assigned for message output in accordance with the locale defined for the user and LTERM partner.

The German UTM message module KCSMSGS and the standard English UTM message module KCSMSGSE are supplied with openUTM.

MESSAGE

MODULE=name
[ ,LIB=omlname ]
[ ,LOCALE = (lang-id [,terr-id]) ]

MODULE=

name

Name of the user-specific message module up to eight characters in length. This module is created using the KDCMMOD tool (see the openUTM manual “Messages, Debugging and Diagnostics on BS2000 Systems”).

This is a mandatory operand.

The name specified here must be unique within the application.

LIB=

omlname 

Object module library from which the user-specific message module is to be loaded dynamically. omlname can be up to 54 characters in length.

If the user-specific message module is to be loaded dynamically, it must not be linked to the application.

If nothing is specified for LIB= , TASKLIB is assumed. This does not correspond to the SET-TASKLIB command, rather a library named TASKLIB must exist in this case. Dynamic loading of the user message module from the library assigned with SYSFILE-TASKLIB is not supported.

When loading dynamically, the DBL searches for the user message module first in the library that you have assigned in LIB= . If this library does not exist, the DBL aborts the search. If the library exists but the user message module could not be found there, the DBL searches through the alternative libraries. The alternative libraries are those that have been assigned a file link name BLSLIBnn (0<=nn<=99).

LOCALE=

(lang_id, terr_id)

Language environment of the user-specific message modules defined by means of a language identifier and possibly a territorial identifier. By making the appropriate entries in the LOCALE= parameter of the USER or LTERM statement, you can assign a corresponding UTM message module. Messages are then output in the user’s language.

If you issue more than one MESSAGE statement, each statement must contain the LOCALE= parameter. The lang_id and terr_id combination must be unique in each MESSAGE statement for a UTM message module.

    lang_id

Freely selectable language identifier for a UTM message module, up to two characters in length.

There is no default value for lang_id, i.e. this is a mandatory parameter.

    terr_id

Territorial identifier for a UTM message module up to two characters in length. You can also specify blanks for terr_id.

If you specify MESSAGE ...,LOCALE=, you must also define the MAX ...,LOCALE (see "MAX - define UTM application parameters"). The application message module of the UTM application is automatically the message module whose lang_id and  terr_id in the MESSAGE statement match the locale in the MAX statement.
openUTM uses the application message module for messages to SYSLST, SYSOUT and CONSOLE. The message destinations specified in the other message modules have no significance.

The UTM message module whose lang_id and terr_id in the MESSAGE statement are identical to the values entered for LOCALE= in the USER or LTERM statement is used for messages to STATION, SYSLINE and PARTNER.

Specifications relating to the user have priority over those relating to the LTERM partner, i.e. if a user is signed on when a message is output, openUTM uses the UTM message module appropriate for that user. If the UTM message modules are assigned using language and territorial identifiers, the procedure is as follows:

  • If a UTM message module exists with a lang_id and terr_id combination identical to the entries in the USER or LTERM statement, UTM messages are output in this language environment.

  • If an identical combination cannot be found, the UTM message module with the same lang_id but for which no terr_id has been generated is used.

  • If this is not possible, the application message module is used.

Generating message modules on Unix, Linux and Windows systems

On UnixOn Unix, Linux and Windows systems, you can generate exactly one user-defined message module with the MESSAGE statement, i.e. you may only specify the MESSAGE statement once within a single KDCDEF run.

If a MESSAGE statement is not issued, the name of the external C/C++ structure is KCSMSGS. An object module with a C/C++ structure with this name is supplied with openUTM as a file.

On Unix and Linux systems, the file is the object module kcsmsgs.o in the library libwork under the path utmpath /sys.

On Windows systems the module kcsmsgs.obj in the library utmpath /sys/libwork.lib.

MESSAGE

MODULE=name

 MODULE=

name

Name of the external C/C++ structure with which messages are addressed. In the case of a user-specific message module (see the description of the KDCMMOD tool in the openUTM manual “Messages, Debugging and Diagnostics on Unix, Linux and Windows Systems”), the name specified here must match the name of this module. name can be up to eight characters in length.

This is a mandatory operand.