7.70.1 MESSAGE Parameters
Allows up to 80 characters of message text to be specified. This text will be displayed on line 22/24 of the current or next screen format that is displayed to the user. The message text specified should be enclosed in quotes. Use either the MSGTXT parameter or the MSGID/MSGF parameters but not both.
Allows a standard message identifier to be specified as the message that should be displayed on line 22/24 of the current or next screen displayed to the user. Message identifiers must be 7 characters long. Use this parameter in conjunction with the MSGF parameter.
|
Portability Considerations |
If you are relying on receiving specific message identifiers in your application, please note: On IBM i, when messages are routed between RDMLX components or functions and RDML functions, the original message identifier is not retained. Such message are re-issued as text messages with a message identifier of DCM9899. |
Specifies the message file in which the message identified in the MSGID parameter will be found. This parameter is a qualified name. The message file name must be specified. If required the library in which the message file resides can also be specified. If no library name is specified, library *LIBL is assumed.
Use this parameter only in conjunction with the MSGID and MSGF parameters. It specifies from 1 to 20 values that are to be used to replace "&n" substitution variables in the message specified in the MSGID parameter.
Values in this parameter may be specified as field names, an expandable group expression, alphanumeric literals or numeric literals. They should exactly match in type, length and specification order the format of the substitution variables defined in the message.
When a field specified in this parameter has a type of signed (also called zoned) decimal, the corresponding "&n" variable in the message should have type *CHAR (character). This may cause a problem when dealing with negative values. In this case use packed decimal format instead.
When an "&n" variable in the message has type *DEC (packed decimal) the field specified in this message must be of packed decimal type.
When using alphanumeric literals in this parameter, remember that trailing blanks may be significant. For instance, if a message is defined as:
"&1 are out of stock ... reorder &2"
where &1 is defined as (*CHAR 10) and &2 as (*DEC 7 0), then the message will NOT be issued correctly if specified like this:
MSGDTA('BOLTS' #ORDQTY)
or like this
MSGDTA('BOLTS ' #ORDQTY)
To make LANSA aware of the trailing blanks, the parameter must be specified like this:
MSGDTA('''BOLTS ''' #ORDQTY)
When expandable expressions are used, the expanded field list must not exceed the maximum number of substitution variables allowed in the parameter.
Specifies the type of message that is to be issued.
*INFO, which is the default value, causes the message to appear on line 22/24 of the NEXT screen format that is displayed to the user. This message will remain on line 22/24 until the user presses the enter key again.
*STATUS indicates that the message should appear on line 22/24 of the current screen, no matter what it is. The current screen may not even be part of the LANSA system. When the next screen format is presented to the user the status message will be erased from the screen. Typically "status" messages are issued to inform the user that some extended action is in progress and that he/she should wait. See the following examples for more information.
*WINDOW indicates that the message should be presented to the user in a message "window". The window will overlay the current screen format (no matter what it is) and can be positioned at the top, middle or bottom of the screen (see the LOCATE parameter). Once the window has been presented the user must press the enter key before processing is resumed. When processing is resumed the screen is restored to what it was before the message window was displayed. Optionally a reply to the message may be received back into the RDML program (see the REPLY parameter).
*WINDOWBUZ indicates that the message should be presented to the user in a message "window". When it is presented the workstation alarm will sound. (See TYPE(*WINDOW) for more details.)
|
Portability Considerations |
*WINDOWBUZ is interpreted as *WINDOW and a build warning is generated when used in Visual LANSA. |
Specifies the minimum time that a *STATUS message should be displayed on line 22/24 of the current screen. Use this parameter to extend the display time of a status message so that it can be read. If no value is specified for this parameter a default value of 0 seconds is assumed (which will cause the message to flash on the screen briefly). Otherwise specify the minimum display time required in seconds. Note that the user's job will wait (and not perform any useful work) for the number of seconds specified in this parameter.
This parameter can be used to "suspend" a function for a period of time while waiting for some other function to complete.
|
Portability Considerations |
Not supported in the current release of Visual LANSA but will be supported in a future release. A build warning will be generated when used in Visual LANSA. |
Optionally nominates a field that is to receive the user's reply to the message. This parameter is only valid for messages using the TYPE(*WINDOW) parameter.
*NONE, which is the default value, indicates that the user should not be given an option to reply to the message. In this case the message window will only display the message text to the user.
When a field name is specified it must be defined in the LANSA data dictionary or in the function. The field may be alphanumeric or numeric. Where the field is alphanumeric and longer than 20 characters only the first 20 characters may be specified by the user. When the field is numeric it must be an integer (i.e. no decimal positions). When a field name is specified, the message window contains the message text and an input field identified by the string "Reply?" into which the user may enter the required reply to the message.
Specifies for messages of TYPE(*WINDOW) whether or not the message window should be surrounded by a border. The default value is *YES. The only other possible value for this parameter is *NO, which indicates that no border is required.
Specifies for messages of TYPE(*WINDOW) where on the screen the message window should be located.
*BOTTOM, which is the default value, indicates that the window should be positioned at the bottom of the screen.
The other allowable values are *TOP and *MIDDLE, which indicate that the window should be positioned at the top or middle of the screen respectively.