Transaction Manager Application Design

This section distinguishes between the following areas in the IMS database and data communication application design process:

• Online program design

• Message Format Service (MFS) design

• Database design

"Online Transaction Processing Concepts" describes some of the concepts that are important to designing application programs that run in IMS TM.

"Online Program Design" on page 292 concentrates on the design of message processing programs (MPPs).

"Basic Screen Design" on page 293 describes some of the concepts of 3270 screen layouts that IMS TM application programs must deal with if the application programs do not use the message format service (MFS). Chapter 17, "Editing and Formatting Messages," on page 297 discusses how MFS provides facilities to deal with 3270 screen layouts and operator interaction.

Although each of the above areas is discussed in separate sections, you need to realize that they depend upon each other. Therefore, an overall system design must be performed initially and an overall system review must follow the design phase of each section

Online Transaction Processing Concepts

In an IMS online environment, a transaction can be viewed from three different points:

• The application, by its processing characteristics and database accesses

• The terminal user

• The IMS system

Each of these views constitutes a set of characteristics. These characteristics are described in the following sections.

Application Characteristics

Generally, applications have two basic characteristics:

• Applications that collect or retrieve data (with no previous database access). This is not a typical IMS application but can be part of an IMS application system.

• Applications that update data. This normally involves database reference and the subsequent updating of the database. Most IMS applications have this characteristic.

In a typical IMS multi-application environment, these application characteristics are often combined. However, a single transaction normally has only one of the characteristics.

Terminal User Characteristics

From the terminal user's point of view, there exist:

• Single-interaction transactions

• Multi-interaction transactions

Single-interaction transactions do not impose any dependencies between an input message, its corresponding output, and the next input message.

Multi-interaction transactions constitute a dialogue between the terminal and the MPPs. Both the terminal user and the message processing rely on a previous interaction for the interpretation and processing of a subsequent interaction.

IMS System Characteristics

From the IMS system point of view, there exist:

• Non-response transactions

• Response transactions

• Conversational transactions

You define these IMS transaction characteristics for each transaction during IMS system definition.

With non-response transactions, IMS accepts multiple input messages (each being a transaction) from a terminal without a need for the terminal to first accept the corresponding output message, if any.

With response transactions, IMS does not accept further transaction input from the terminal before the corresponding output message is sent and interpreted by the user.

Conversational transactions are similar to response transactions, in that no other transactions can be entered from the terminal until the terminal is out of conversational mode. With response mode, the terminal is locked until a reply is received, but not for conversational mode. Another difference between the two is that for conversational transactions, IMS provides a unique scratch pad area (SPA) for each user to store vital information across successive input messages.

Transaction Response Time Considerations

In addition to the application, terminal user, and IMS system characteristics, the transaction response time is an important factor in the design of online systems. The transaction response time is the elapsed time between the entering of an input message by the terminal operator and the receipt of the corresponding output message at the terminal.

In general, two main factors constitute the transaction response time:

• The telecommunication transmission time, which is dependent on factors such as:

  - Terminal network configuration

  - Data communication access method and data communication line procedure

  - Amount of data transmitted, both input and output

  - Data communication line utilization

• The internal IMS processing time, which is mainly determined by the MPP service time. The MPP service time is the elapsed time required for the processing of the transaction in the MPR.

Choosing the Correct Characteristics

Categorize each IMS transaction by one of the previously described characteristics. Some combination of the characteristics are more likely to occur than others. The combinations depend on your application's needs.

Choose which combination is attributed to a given transaction. Selecting the appropriate characteristics is an essential, deliberate part of the design process, rather than determining the characteristics after implementation.

Following are some examples:

• Assume you need to design an inquiry for the customer name and address, with the customer number as input. The most straightforward way to implement this is as a non-conversational response-type transaction.

• The entry of new customer orders could be done by a single response transaction. The order number, customer number, detail information, part number, and quantity all could be entered at the same time. The order would be processed completely with one interaction. This is most efficient for the system, but it might be cumbersome for the terminal user who has to reenter the complete order in the case of an error.

Quite often, different solutions are available for a single application. Choose your solution based on a trade-off between system cost, functions, and user convenience. The following sections will highlight this for the different design areas.

Online Program Design

Online program design is second in importance to database design. In this section, discussion of this broad topic is limited to the typical IMS environment.

The following sections discuss a number of considerations that can influence your program design decisions.

Single versus Multiple Passes

A transaction can be handled with one interaction or pass, or with two or more passes. Each pass bears a certain cost in transmission time and in IMS and MPP processing time. In general, you should use as few passes as possible. Whenever possible, use the current output screen to enter the next input. This is generally easy to accomplish for transactions that query or retrieve data (with no updates), where the lower part of the screen can be used for input and the upper part for output (see "Basic Screen Design" on page 293).

For update transactions, the choice is more difficult. The basic alternatives are:

One-pass update

After input validation, the database updates are all performed in the same pass, which is the most efficient way from the system point of view. However, correcting errors after the update confirmation is received on the terminal requires additional passes or the reentering of data. You must evaluate the expected error rate.

Two-pass update

On the first pass, the input is validated, including database access, and a status message is sent to the terminal. If the terminal operator agrees, the database is updated in the second pass. With this approach, making corrections is generally much simpler, especially when a scratch pad area is used. However, the database is accessed twice.

Except for the SPA, no correlation exists between successive interactions from a terminal. So the database can be updated by another user and the MPP can process a message for another terminal between the two successive passes.

Multi-pass update

In a multi-pass update, each pass partially updates the database. The status of the database and screen is maintained in the SPA. Take this approach only for complex transactions. Also, remember that the terminal operator experiences response times for each interaction. You also must consider the impact on database integrity. IMS backs out only the database changes of the current interaction in the case of project or system failure.

An IMS emergency restart with a complete log data set repositions the conversation. The terminal operator can proceed from the point at the time of failure. When a conversational application program terminates abnormally, only the last interaction is backed out, so the application must reposition the conversation after correction. For complex situations, IMS provides the Conversational Abnormal Termination exit routine (DFSCONE0). For more information about this exit routine, see IMS Version 9: Customization Guide.

Conversational Transactions versus Non-Conversational Transactions

Conversational transactions are generally more expensive in terms of system cost than non-conversational ones. However, conversational transactions give better terminal operator service. Use conversational transactions only when required. Also, with the proper use of MFS, the terminal operator procedures sometimes can be enhanced to almost the level of conversational processing.

Transaction or Program Grouping

As the program designer, it is your choice how much application function is implemented by one transaction or program. The following considerations apply:

• Inquiry-only transactions should be simple transactions and normally should be implemented as non-conversational transactions. Also, simple transactions can be defined as "non-recoverable inquiry-only". If, in addition, the associated MPPs specify read without integrity (PROCOPT=GO) in all their database PCBs, no dynamic enqueue and logging will be done for these transactions and reading is without integrity.

• Limited-function MPPs are smaller and easier to maintain. However, a very large number of MPPs costs more in terms of IMS resources, such as control blocks and path lengths.

• Transactions with a long MPP service time involving many database accesses should be handled by separate programs.

As mentioned in "Message Switching" on page 285, IMS TM provides a program-to-program message switch capability. You can split transaction processing in two or more phases by using message switches. The first (foreground) MPP does the checking and switches a message (and, optionally, the SPA) to a background MPP in a lower-priority partition. The background MPP performs the lengthy part of the transaction processing, thus making the foreground MPP available to service other terminals. Also, if no immediate response is required from the background MPP and the SPA is not switched, the terminal is more readily available for entering another transaction.

Basic Screen Design

When you design 3270-type screen applications that use MFS, you need to understand basic screen design, which is described in this section. For more information about screen design and MFS, see:

• IMS Version 9: Administration Guide: Transaction Manager

• IMS Version 9: Application Programming: Transaction Manager

Generally, a screen can be divided into five areas, from top to bottom:

1. Primary output area: contains general, fixed information for the current transaction. The fields in this area should generally be protected.

2. Detail input/output area: used to enter or display the more variable part of the transaction data. Accepted fields should be protected (under program control) because fields in error can be displayed with high intensity and unprotected to allow for corrections.

3. MPP error message area: In general, one line is sufficient. The MPP error message area can be the same line as a system message field.

4. Primary input: the requested action or transaction code for next input, and the primary database access information.

5. System message field: used by IMS to display system messages and by the terminal operator to enter commands.

For readability, separate the screen areas by at least one blank line. IBM recommends that you develop a general screen layout and a set of formats that can be used by incidental programs and programs in their initial test, which can significantly reduce the number of format blocks needed and simplify maintenance.

Installation standards should be defined for a multi-application environment.

General Screen Layout Guidelines

Observe the following performance guidelines when you design screen layouts:

• Avoid full-format operations. IMS knows what format is on the screen. If the format for the current output is the same as the format that is on the screen, IMS need not retransmit all the literals and unused fields.

• Avoid unused fields, such as undefined areas on the screen. Use the attribute byte (non-displayed) of the next field as a delimiter, or expand a literal with blanks. Each unused field causes 5 additional control characters to be transmitted across the line during a full-format operation. Weigh the cost of transmitting the 5 additional control characters against the benefits of user convenience.

Including the Transaction Code in the Format

IMS requires a transaction code as the first part of an input message. With MFS, this transaction code can be defined as a literal. In doing so, the terminal operator always enters data on a preformatted screen. The initial format is retrieved with the /FORMAT command.

To allow for multiple transaction codes in one format, part of the transaction code can be defined as a literal in the message input descriptor (MID). The rest of the transaction code can then be entered by using a DFLD statement in the format. This method is very convenient for the terminal operator, who does not have to be aware of the actual transaction codes.

General IMS TM Application Design Considerations

Keep the following points in mind when you design IMS TM applications that use MFS:

• A conversation is terminated (a blank transaction code is inserted in the SPA) after each successfully completed transaction. This termination is transparent to the terminal operator because the output format is linked to a MID that contains the transaction code, so the operator does not need to reenter the transaction code.

• Each output message should contain all the data (except the literals that are defined in the message output descriptor) to be displayed. Do not rely on already existing data on the screen because a clear screen operation or a restart operation might have destroyed the data.

• Using secondary indexing can significantly increase the accessibility of online databases. Therefore, a wider use of this facility is discussed in "Secondary Index Databases" on page 77.