4 7 A Message for every Situation

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:

• An information message (type *INFO). The message is issued and the program continues executing, but the message does not appear until the next DISPLAY or REQUEST command is processed (even if it is not in the program which issued the message).

• A status message (type *STATUS). The message is issued, appears immediately on the bottom of the screen (no matter which program presented the screen), and the program continues execution. When the next DISPLAY or REQUEST command is processed the message disappears.

• A window message (type *WINDOW). The message is issued immediately and appears in a "window" which overlays what is currently on the screen (no matter what program presented the screen). The program then stops executing and waits for the user to press the enter key. A reply may be entered to the message. The reply is then made available for processing by the RDML program.

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:

 

The programmer may then use the screen design facility to modify the screen to include "instructions" to the user, such as:

 

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:

 

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:

• Less time spent by programmers arbitrarily inserting instructions on the screen.

• Consistency in all applications.

• Instructions (which are usually superfluous to experienced end users) will always appear on the message line.

• The ability to issue multiple lines of instructions by executing multiple MESSAGE commands.

• The message is generally more conversational (or at least easier to make conversational) than a piece of static instruction on a screen.

• If a message from a message file is used (rather than just text as in the previous example), then the user has the option to place the cursor on the "instruction" message and press HELP.

   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:

• In an online report production program.

   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.

• In any online task that takes an extended time.

   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:

 

 

 

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 data dictionary 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.