TS/MP Pathsend and Server Programming Manual (H06.05+, J06.03+)

records are locked too early, other transactions cannot access them and the application’s
concurrency (its ability to process many transactions at the same time) suffers.
As the Enter Sales transaction demonstrates, all the data collection and validation operations can
happen before you begin the TMF transaction—although some revalidation may be done again
as part of the transaction. Assembling the order header and assembling the order involve reading
records in the database but not changing the records. The rest of the operations change the
database and should all be done within a TMF transaction.
As a general rule, you should design the application’s transactions to maintain consistency under
all circumstances. After the application is installed and running successfully, you can look for ways
to improve its concurrency.
Aborting Transactions
If the requester or the server program detects a problem during the processing of a TMF transaction,
the requester or server causes the transaction to be aborted with a special procedure call or
statement (for example, a call to ABORTTRANSACTION in a Pathsend program). For requesters,
the statement that aborts a transaction is executed in lieu of the statement that ends a transaction;
for example, in a Pathsend program the requester either completes the transaction with a call to
ENDTRANSACTION or causes it to be backed out, because of an error, with a call to
ABORTTRANSACTION.
In the past, program designs typically assigned the task of aborting transactions to requesters.
Current program design often assigns that task to servers. Servers abort transactions and inform
the requesters of those actions, therefore ensuring protection of data. The aborting of transactions
by servers is described further under “Designing Server Programs” (page 43), later in this section.
The TMF subsystem backs out aborted transactions by using information contained in the TMF
audit-trail files. For more information about transaction backout and audit-trail files, refer to the HP
NonStop Transaction Management Facility (TMF) Application Programmer’s Guide.
Designing the Database
The next step in developing a Pathway application is to design the database that will be accessed
and updated by the application. Designing the database, which is a highly specialized activity
typically performed by experienced database administrators, involves:
• Precisely identifying the meaning and use of the data as it exists in your business and specifying
the database files and records that will store this data. This step is referred to as logical design.
• Choosing file types and keys for the records. This step is referred to as physical design.
In addition to completing a logical and physical design of your database, you must also select a
database manager product and ensure that your server programs can interface with that database
manager.
Logical Design
During the logical design process, you determine which classes of data must be maintained by
your application and identify the relationships that exist between the classes. Each class of data
names something that the database will store information about. For example, in an application
that processes sales orders, orders is a class of data and order-items is a relationship between
a particular order and the inventory items within the order. These data classes and relationships
generally become records in files accessed by the application.
After specifying data classes, you list the attributes (data items) for each class of data. For example,
some of the attributes are order-ID, cust-ID, and order-total. These attributes become
fields in the records of the database. After specifying attributes for data classes, you diagram the
34 Designing Your Application