Pathway/iTS TCP and Terminal Programming Guide

Designing Your Application

Compaq NonStop™ Pathway/iTS TCP and Terminal Programming Guide—426751-001

2-6

Protecting Transactions

After listing and grouping the components of the Enter Sales transaction, you protect the

integrity of each transaction, and ultimately the consistency of the database, with the

TMF subsystem. The following pages outline how to integrate the TMF subsystem with

your business transactions.

For details about TMF programming in SCREEN COBOL requesters, see Section 5,

Managing Transactions With the TMF Subsystem For information about the overall

features of the TMF subsystem, including database file recovery and audit trails, refer to

the Introduction to NonStop™ Transaction Processing.

Defining TMF Transactions

From a systems perspective, a transaction includes all the steps necessary to transform a

database from one consistent state to another. A TMF transaction must be constructed

as a logical unit of work: that is, all parts of a transaction, which usually consists of

multiple operations, must be handled as a single entity. If any parts of a TMF

transaction are not successfully completed or applied to a database, then none of the

transaction parts are applied to the database. By forcing all components of a transaction

to be handled as a single unit of work, the TMF subsystem prevents inaccurate or partial

updates to the database and protects database consistency.

At the application level, a TMF transaction is defined by special procedure calls or

statements that specify the beginning and end of a transaction. For example, in

SCREEN COBOL, a transaction begins with a BEGIN-TRANSACTION statement and

ends with an END-TRANSACTION or ABORT-TRANSACTION statement. The

procedure calls that define TMF transactions act as brackets; that is, the statements are

placed before and after the add record, update record, and delete record procedures in

your requester program.

Database Consistency and Concurrency

Potentially, all operations that alter the database are candidates for TMF protection. But

before you can apply TMF protection to your transactions, you need to determine:

•

When to begin a TMF transaction

•

Whether all of the database update operations have to happen together in the same

TMF transaction or whether they can be parts of different transactions

To answer these issues, you have to establish your criteria for database consistency and

decide how much processing concurrency you can achieve in the application. For

example, the Enter Sales transaction affects several pieces of information: order data,

inventory data, shipping data, customer credit, and receivables. Upon examination of

this transaction, you will see that it is possible to make one general assertion about order

processing and about the Enter Sales transaction in particular: An order is not complete

until every piece of information associated with the order is recorded in the \REG,

\CORP, and \WHS databases.

To illustrate this assertion, consider a situation where a transaction fails after it changes

the customer’s balance, records the order information, and records the order invoice, but

before it records the shipping information. In this scenario, the customer is going to be