4.7 A Message for every Situation

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.