The LANSA RDML language is very good at issuing and handling messages.
Three different types of messages can be issued by any RDML function via the MESSAGE command. These are:
Significant productivity and design benefits can be achieved by implementing the standardized use of messages in all sorts of situations. Review the examples provided.
Example 1: Information Messages - Instructions to the User
Example 2: Status Messages - Keeping the User Informed
Example 3: Window Messages - Confirming User Actions
Example 4: Information Messages - Batch Programs
Example 1: Information Messages - Instructions to the User
Consider the following very simple data entry program:
GROUP_BY NAME(#CUSTOMER) FIELDS(#NUMBER #NAME #ADDRESS #ZIP)
BEGIN_LOOP
REQUEST FIELDS(#CUSTOMER)
INSERT FIELDS(#CUSTOMER) TO_FILE(CUSMST)
CHANGE FIELDS(#CUSTOMER) TO(*NULL)
END_LOOP
The automatically designed data entry screen would probably look something like this:
Number . . . . _______________
Name . . . . . __________________________________
Address . . . __________________________________
Zip code . . . _______________
The programmer may then use the screen design facility to modify the screen to include "instructions" to the user, such as:
Input customer details and press enter
Number . . . . _______________
Name . . . . . __________________________________
Address . . . __________________________________
Zip code . . . _______________
However, a faster and more consistent alternative to the continual insertion of "instructions" on LANSA designed screens is to use the MESSAGE command.
For example, if the RDML program was altered as follows:
GROUP_BY NAME(#CUSTOMER) FIELDS(#NUMBER #NAME #ADDRESS #ZIP)
MESSAGE MSGTXT('Input customer details and press enter')
BEGIN_LOOP
REQUEST FIELDS(#CUSTOMER)
INSERT FIELDS(#CUSTOMER) TO_FILE(CUSMST)
CHANGE FIELDS(#CUSTOMER) TO(*NULL)
MESSAGE MSGTXT('Customer accepted ... enter next customer')
END_LOOP
then the initial screen presented to the user would look like this:
Number . . . . _______________
Name . . . . . __________________________________
Address . . . __________________________________
Zip code . . . _______________
Enter customer details and press enter
After details of the first customer have been successfully input, the screen is effectively cleared and a message indicating that the "customer was accepted and that the next customer's details should be input" will appear.
There are some significant advantages in using messages for user instructions. These include:
The second level text of the message will then appear. This facility allows a full page of "extended instructions" to be displayed to the user.
Overall, there are not many situations in which the "instructions" which are so often placed onto screen formats cannot be replaced by messages.
Example 2: Status Messages - Keeping the User Informed
Status messages can add to the "user friendliness" of any system by keeping the user informed of what is going on. Some examples of where they could be used are:
For instance, the user requests that a particular customer report is to be produced (online). It is a nice touch if a message such as ."Customer report being produced .... please wait" immediately appears.
For instance, processing and validating a large batch of general ledger transactions online can be made more "friendly" if a message such as the following one appears after every 20 transactions are processed "nn G/L transactions processed. nn accepted. nn rejected" It reminds the user that the computer is working for them.
Example 3: Window Messages - Confirming User Actions
Very often, it is necessary to get an end user to confirm a request. Typically, this will involve things like deletion confirmation, or confirming that a tape is mounted, or that a large batch report run should really be submitted, etc.
Usually a special purpose built screen can be displayed for user confirmation. However, it is more productive - and often more aesthetic - to use a "message window".
The following are examples of overlaid message windows which can be easily produced by the MESSAGE command:
Number . . . . A627478
Name . . . . . ACME ENGINEERING CORPORATION
Address . . . 121 SMITH STREET, ANYTOWN.
Zip code . . . 18475
......................................................
: Confirm this customer is to be deleted (Y or N) :
: Reply : _ :
:....................................................:
Enter number of action required : 3
1. Power down the system
2. Perform weekly backup procedures
3. Perform daily backup procedures
......................................................
: Confirm daily backup tape is mounted (YES or NO) :
: Reply : __ :
:....................................................:
Produce Customer Summary Report
Print customers in state . . . . . C
Print Zip code range . . . . . . . 34859 to 48579
Print only those with orders . . . Y
......................................................
: Confirm Customer Summary Report should be run (Y N):
: Reply : _ :
:....................................................:
A message window has the advantage that it overlays the current display (no matter what program originally presented the screen) and can be positioned to overlay the top, middle or bottom of the screen. Thus you can ensure that the user can see just what they did to cause the window to appear.
Example 4: Information Messages - Batch Programs
Most programmers quickly realize that the message handling facilities within LANSA can improve the appearance and friendliness of online applications, as well as reducing programming time and maintenance costs.
LANSA messages can also provide significant benefits in batch programs - particularly those that perform data validation and/or produce reports.
Consider the following section of a batch program for processing name and address details which have arrived on the system via magnetic tape:
DEFINE FIELD(#ERRTXT) TYPE(*CHAR) LENGTH(100) LABEL('Error :')
DEF_LINE NAME(#NAME) FIELDS(#CUSTNO #ADDRESS1 #ADDRESS2 #ZIPCODE)
DEF_LINE NAME(#ERROR) FIELDS(#ERRTXT) IDENTIFY(*LABEL)
SELECT FIELDS(#NAME) FROM_FILE(TAPEINP)
PRINT LINE(#NAME)
INSERT FIELDS(#NAME) TO_FILE(NAMES) VAL_ERROR(*NEXT)
IF_STATUS IS_NOT(*OKAY)
MESSAGE MSGTXT('Details of this name not added to database')
USE BUILTIN(GET_MESSAGE) TO_GET(#RETCODE #ERRTXT)
DOWHILE COND('#RETCODE = OK')
PRINT LINE(#ERROR)
USE BUILTIN(GET_MESSAGE) TO_GET(#RETCODE #ERRTXT)
ENDWHILE
ENDIF
ENDSELECT
The above program reads all name and address details from a name and address tape input file called TAPEINP. Each name and address processed is printed onto a report in a line called #NAMES.
The program then attempts to add each name to a name and address file called NAMES. File NAMES has been set up with many dictionary or file level validation checks, so the INSERT command will fail if they are not met.
When such a validation error occurs, a general purpose message will be issued indicating that the name and address just printed onto the report was NOT added to the database file NAMES.
Then the Built-In Function GET_MESSAGE will "read" all messages from the program message queue and print the text in a line called #ERROR. All the repository and file level validation errors will be printed before the final message issued by this program is printed.
By using the MESSAGE command and the GET_MESSAGE Built In Function together, it is possible to produce entire reports by issuing, and then "re-processing", messages.
By using predefined messages from a message file and message substitution variables, it is possible to create and manipulate complex variable text strings for reporting purposes.
