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

subset. You can place the extracted records in a nonaudited scratch file (each server can have its
own scratch file, to avoid conflict among them). If the transaction is aborted and restarted, the
transaction starts writing the scratch file from the beginning and there is no need for the scratch
file to be audited.
Another example is logging all input messages to a server, which allows examination of them after
a failure. It is self-defeating to designate the log file as an audited file; the message that caused
the failure would be backed out.
These restrictions apply to applications that use the TMF subsystem:
• When working with audited files, do not use the COBOL85 feature that provides record
blocking on an unstructured disk file.
• When changing audited files, do not use a server that provides its own record blocking, its
own record caching, or its own form of record locking.
Locking Records
If your application uses the TMF subsystem, your servers must follow the TMF locking rules. Locking
gives the TMF subsystem the control required to ensure that transactions are presented with a
consistent view of the database. With respect to the locking of records, you must consider these
aspects of your application:
• Repeatable reads.
• Errors that result from locks being held by the transaction identifier instead of the process
identifier and OPENID of the file opener.
• Errors that result from reading deleted records.
• Batch updates by a transaction that acquires a large number of locks. You should use file
locks instead of record locks for batch updating.
For details about how to handle these aspects of your application, refer to the HP NonStop
Transaction Management Facility (TMF) Application Programmer’s Guide.
Grouping Transaction Operations
Your application can view the transaction as a logical unit of work; for example, the order header
and all the detail items in a purchase order might be such a work unit. The TMF subsystem, however,
treats the transaction as a physical unit of recovery. When you use the TMF subsystem in your
application, you must consider this difference.
Basically, you need to answer certain questions. What is the logical unit of work that you want to
accomplish within an application? How can the work be divided into a number of transactions
that can be recovered by the TMF subsystem?
Factors that influence the answers to these questions are:
• Concurrency: How long will record locks be held by a transaction?
• Performance: How much server activity and how many display screens are involved in the
choice of one conversion strategy over another?
• Consistency: Are the units of recovery large enough to ensure that your criteria for consistency
will be maintained?
In view of these factors, two guidelines can help you decide how to group the database accesses
made by an application into a single transaction:
• Any group of accesses that together modify the database from one consistent state to another
consistent state should be a single TMF transaction.
• Any group of accesses that require a consistent view of the database should be a single TMF
transaction.
Considerations for Servers That Use the TMF Subsystem 67