Page History
...
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
| Anchor | ||||
|---|---|---|---|---|
|
Consider the following very simple data entry program: GROUP_BY NAME
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 . . .
Number . . . . _______________
Name . . . . . __________________________________
Address . . . __________________________________
Zip code 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
Input customer details and press enter
Number . . . . _______________
Name . . . . . __________________________________
Address . . . __________________________________
Zip code 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
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 . . .
Number . . . . _______________
Name . . . . . __________________________________
Address . . . __________________________________
Zip code . . . _______________
Enter customer details and press enter
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:
- 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.
| Anchor | ||||
|---|---|---|---|---|
|
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, 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 It reminds the user that the computer is working for them.
| Anchor | ||||
|---|---|---|---|---|
|
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.
...
The following are examples of overlaid message windows which can be easily produced by the MESSAGE command:
Number . . . . A627478 Number . . . . A627478
Name . . . . . ACME ENGINEERING CORPORATION
Address . . . 121 SMITH STREET, ANYTOWN.
Zip code . . . 18475
................................................. Zip code . . . 18475
......................................................
: Confirm this customer is to be deleted (Y or N) Confirm this customer is to be deleted (Y or N) :
: Reply : _ Reply : _ :
:.....................................................................................................:
Enter number of action required : 3
1. Power down the system Enter number of action required : 3 1. Power down the system
2. Perform weekly backup procedures
3. Perform daily backup procedures Perform daily backup procedures
........................................................
......................................................
: Confirm daily backup tape is mounted (YES or NO) :
: Reply Reply : __ __ :
:............................................................................................................:
Produce Customer Summary Report
Produce Customer Summary Report
Print customers in state . . . . . C
Print Zip code range Print customers in state . . . . . C
Print Zip code range . . . . . . . 34859 to 48579
Print only those with orders . . . Y
................................................................ Print only those with orders . . . Y
......................................................
: Confirm Customer Summary Report should be run (Y NConfirm Customer Summary Report should be run (Y N) :
: Reply 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.
| Anchor | ||||
|---|---|---|---|---|
|
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.
...
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
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.
...