Chapter 10. Designing the Presentation Logic
In this chapter:
In the KanDoIT company, the accounts department has decided that it is very happy with its existing 3270-based applications. So here we describe the background to a 3270 user interface and the design principles behind writing the presentation logic.
This chapter describes the design of the presentation logic of the Accounts system. There are two key stages that you need to consider in your design. They are:
Designing the user interface, including checks for valid data, and the ability for the users to correct their input. There are two sections describing what the presentation logic has to do and another describing the ways to incorporate the CICS design guidelines.
Sending and receiving the information to your appropriate business logic component. This describes how information is sent from the screen to the business logic and also how the data is returned to the screen.
Understanding What the Presentation Logic Component Needs to Do
The basic design behind each of the frontends that we describe in this book is:
To create a clear, easy-to-use screen so that the users can enter their data quickly and easily.
To transfer data to the business logic.
To receive information from the business logic to display on the screen.
The plan to achieve that for this component is to:
Display a customer account record, given the account number.
Add new account records.
Modify existing account records.
Delete account records.
Print a list of the changes made to the account file.
Print a single copy of a customer account record.
Access records by name.
Read and update the stored data using the account business logic component.
First, a little about 3270 terminals, how 3270 data streams work, and how CICS starts transactions. Then we can start thinking about how our application might look to the end user.
IBM 3270 Information Display System
The 3270 information display system is a family of display and printer terminals. Today, most people who require 3270 devices use PCs to emulate them. There were many 3270 device types and models that differed in screen sizes, printer speeds, features (like color and special symbol sets) and manner of attachment to the processor, but they all used essentially the same data format. You need to know a little about this format to understand the Basic Mapping Support (BMS) services that CICS provides to ease the job of communicating with these devices.
The IBM 3278 Display Station Model 2 has a display screen and a keyboard. This device is used for both input and output, and in both cases the screen (or rather a buffer that represents it) was the crucial medium of exchange between the terminal and the processor. The purpose of the keyboard is to modify the screen, in preparation for input, and to signal when that input is ready to be sent to the server.
When your application program writes to a 3278, the server sends a stream of data in the special format used by 3270 devices. Most of the data in the stream is the text that is to be displayed on the screen; the rest of it is control information that defines where the text should go on the screen, whether it can be overtyped from the keyboard later, and so on.
The printers that correspond to the 3278 can use this same data stream, so a stream built for a display device can be used equally well for a printer. More about printers later.
3270 Field Structure
The screen of the 3278 Model 2 can display up to 1920 characters, in 24 rows and 80 columns. That is, the face of the screen is logically divided into an array of positions, 24 deep and 80 wide, each capable of displaying one character, with enough space around it to separate it from the next character.
Each of these 1920 character positions is individually addressable. This means that your COBOL application program can send data to any position on the screen, without having to space it out with space characters to get it into the right location. Your program does not, however, give an address for each character you want displayed. Instead, within your program, you divide your display output into fields. A field on the 3278 screen is a consecutive set of character positions, all having the same display characteristics (high intensity, normal intensity, protected, not protected, and so on). Normally, you use a 3270 field in exactly the same way as a field in a file record or an output report to contain one item of data.
Planning Your 3270 Screen Layout: Using a Menu Screen
You will mainly use the presentation logic component to design the 3270 screen.
For many applications, users need to remember just one transaction identifier. When they want to do any transaction in that application (in our case, create, display, print, and so on) they enter just the one transaction identifier. In response, the screen displays a menu of things that the users can do in this application. The menu has formatted fields for the data items that are required on input and also shows help instructions in case users don’t remember exactly what to do.
The chief advantage of this technique is that the user has to remember almost nothing, a big help if they were infrequent users of our sample application.
There are some other benefits as well: you can diagnose errors in the request input in the same convenient way that we described for the add screen, so that the user gets a good explanation of the problem and has to do a minimum of re-keying to correct the errors. Also, when you complete a transaction such as an add, you can combine your confirmation message with this menu screen. This way, the user knows that the previous entry was successful, and is all ready to enter the next request.
Probably the only disadvantage to this menu technique is that a user has to go through one extra screen for the first transaction of a session, and one extra step (clearing the screen in this case) to escape. The only time this is a serious matter is when users need to mix transactions from different application suites constantly.
Before proceeding much further for our sample application, we should consult the users in the accounts department, showing them the sample screens (hand-drawn if necessary) and asking them to use them. Now let’s consider how a modify transaction will work:
The user keys in the four-character transaction identifier (in our case, NACT ) to get started.
The menu screen is displayed in response (see Figure 10-1).
The user enters M (for modify) for the request type, keys in an account number, and presses Enter.
If there’s a problem, the user sees the same screen with the error fields highlighted and an explanatory message at the bottom saying what’s wrong.
Otherwise, the response displays the record to be modified, ready for the user to change. The user changes the fields to be modified, and then presses the Enter key to send the screen back. If there are errors in the changes, the transaction returns the input with the errors highlighted and a message, if necessary. If (when) the user gets it right, the transaction updates the file, and sends back the menu screen, with a message at the bottom saying that the modification just requested was completed successfully. The user then enters the next request, or clears the screen to quit our application.
Interface Design Principles
In reaching our current idea of how your user interface will look, most of your decisions are based on what is easiest for the user. Indeed, that should be the cardinal rule. Human time has now become so much more valuable than computer time that it’s worth a lot of effort and coding to make the user as productive as possible.
It isn’t always obvious how to do this to the best advantage, and what is best for one user may not be best for another. This applies especially to occasional users of an application. In fact, the style of conversation between users and computers has changed significantly as people have learned more about the human factors of online systems.
Though there are no hard and fast rules, and though there can be many good designs for the user interface, here are five guidelines that we can safely propose:
Make screens easy to understand:
Keep to the rules used in forms design: try to give the screen layout an uncluttered appearance and, to the extent possible, a columnar structure, so that the reader’s eye moves easily from one item to the next and doesn’t have to jump long distances.
Put a title on the screen, so that users know where they are in the current transaction.
Be consistent from screen to screen. If you put the title on the top center of one screen, put it there on all the screens. If you put the messages at the bottom of one screen, put them there on all the screens.
If the user is reading from a form for input to a screen, make the screen look as much as possible like the form. Put the fields in the same order, and use the same placement as much as possible.
Likewise, if a screen is used to display information that the user is accustomed to seeing printed on a form, make the screen resemble the form as much as possible.
Reduce what the user must remember:
If there are more than a few fields to be filled in; use a formatted screen with labels and instructions.
Where possible, put instructions on the screen to show what the user can do next.
Use consistent procedures, both within and across application programs. For example, if the CLEAR key is used to cancel in one transaction, use it that way in all transactions.
Protect users from themselves:
If a user is about to do something that’s hard to undo, such as a file deletion, get the user to confirm that it’s the right action.
Save the user’s time and patience:
Minimize the number of characters that have to be keyed.
Make the user change screens as little as possible.
Make it as easy as possible to correct errors. There are many ways to do this. In our application, for example, we do the following:
Redisplay the user’s input in the same screen in which it was entered.
Diagnose all the errors at once.
Highlight fields that have errors.
If the user misses any required fields, fill with asterisks and highlight.
Place the cursor under the start of the first field in error.
Display an explanatory message if the error may not be obvious.
Minimize the number of times that the users have to skip over fields.
Reassure users:
Give a positive confirmation that a requested action has been done successfully.
When you know a particular response time is likely to be longer than usual (because of the operation being performed) consider sending an intermediate display.
Incorporating CICS Design Guidelines
In addition to the screen design, we need to take into account some features that are common to transaction processing systems. The main one here is to understand the difference between conversational and pseudo-conversational transactions.
Conversational or Pseudo-conversational Transactions?
Now that we’ve established guidelines for design, let’s return to the issue of defining the transactions that make up the sample application. Earlier we described the processing required for the various transaction types that the user sees: add, modify, display, and so on. If we were to define our CICS transactions along these functional lines, we can foresee several problems:
There is much repetitive processing, which suggests that we should at least use common programs for some of the transactions, or combine transactions.
Every transaction involves a wait for the user to enter data, and the update transactions contain two such waits. This means that these transactions will be running for a relatively long time, which is a violation of the guideline to keep program duration short.
The modify and delete transactions will be holding on to a one-user-at-a-time resource during one of the waits, contradicting the guideline to minimize the duration of transactions that use such resources.
Because CICS places no restriction on user input, CICS allows the systems programmer to place a limit on the number of concurrent transactions in each CICS address space internally to stop it becoming flooded and running out of resources. So if you have a conversational transaction open while the end-user goes to lunch, that slot within CICS is wasted and if the transaction is holding onto a lock, anybody else who wishes to access the same resource will have to wait until that user returns from lunch and completes his task.
Take, for example, the modify transaction. If programmed for a 3270 terminal as outlined earlier, the sequence of major events would be as shown in Table 10-1.
In CICS, this is called a conversational transaction, because the programs being executed enter into a conversation with the user. In contrast, a non-conversational transaction processes one input (which was read by CICS and which started the task), responds, and ends (disappears). It never pauses to read a second input from the terminal, so there is no real conversation. The important difference between the two types is transaction duration.
Conversational transactions
Because the time required for a response from a terminal user is much longer than the time required for the computer to process the input, conversational transactions last that much longer than non-conversational transactions. This means that conversational transactions use storage, maintain locks and other resources much more heavily than non-conversational ones because they retain their resources for so long. Whenever one of these resources is critical, you have a compelling reason for using non-conversational (pseudo-conversational) transactions if at all possible.
Pseudo-conversational transactions
This leads to a technique in CICS called pseudo-conversational processing, in which a series of non-conversational transactions gives the appearance (to the user) of a single conversational transaction. In the case we were just looking at, the pseudo-conversational structure is shown in Table 10-2.
Notice that Steps 2 and 6 of the conversational version have disappeared. No transaction exists during these waits for input; CICS takes care of reading the input when the user gets around to sending it.
A word about transactions. If we seem to be using the word in two different ways, well … yes, we are. We defined the word earlier in the way that the user sees a transaction: a single item of business, such as an add, a display operation, and so on. This is a correct use of the word. However, what the user sees as a transaction isn’t necessarily what CICS sees.
To CICS, a transaction is a task that begins (usually on request from a terminal), exists for long enough to do the required work, and then disappears. It may last milliseconds or it may last hours. As we’ve just explained, you can use either one or several CICS transactions to do what the user regards as a single transaction. We’re still deciding what we should define to CICS as transactions to accomplish the user transactions in our example problem. At the moment, the pseudo-conversational approach seems promising; it uses shorter programs (which are desirable in CICS as any other transaction processing system) and although there may be more of them, the programming does not look any more complicated.
The main way one transaction passes data to the next is by using the COMMAREA (for communication area). The same facility is available to pass data between programs within a transaction.
There are other facilities for storing data between transactions. One of these is a CICS facility known as temporary storage, which can be used as an application scratchpad.
Handling Errors
Error handling was discussed in some detail when we developed the COBOL business logic component (see Handling Errors in Chapter 4). The same principles apply here, especially dealing with user errors, invalid input, mismatches in resources and applications, hardware faults, omissions in the code, and so on.
Designing the Functions
This section provides detailed information about the 3270 presentation logic component of our sample application.
The first point to note is that we must always present the user with a “menu” of choices. So we’ll start by displaying this menu and analyzing the request entered on it. The requests may be:
- To exit the application
In this case, we simply end the transaction.
- To display, print, modify, add, or delete an account
In this case, we invoke the appropriate business logic as described in Part II.
- To search the accounts by name
In this case, we invoke the appropriate business logic as described in Part II.
- None of the above
In this case, we send an error message to the user and repeat from the analysis step.
After invoking the appropriate business logic, we must check for errors and inform the user if one has occurred. For successful requests, we must perform the action desired for each request:
- Display requests
We must present the data to the user.
- Print requests
We must schedule the print activity.
- Modify requests
We must lock the account, present the data to the user, accept any changes made to the data, and invoke the update business logic.
- Add requests
We must get an account number, ensure it does not already exist, lock it, solicit input from the user, accept the input data, and invoke the add business logic.
- Delete requests
We must lock the account, present the data to the user, solicit confirmation of the delete, and invoke the delete business logic.
- Searches by name
You must invoke the browse logic and display the results.
You must allow for the user to abandon any of these functions at any time that may require freeing any locks previously obtained. Once an activity has been completed we should display a confirmation message.