TS/MP Pathsend and Server Programming Manual (G06.24+, H06.03+)

Writing Pathway Servers
NonStop TS/MP Pathsend and Server Programming Manual–132500
4-7
Using Audited and Nonaudited Files
proceed because they are each waiting for the other to release a lock.) One way to
cope with deadlock is to use timeout.
In addition, your requester program must use the necessary transaction-control
procedure calls or statements to begin and end the transaction and to abort or restart the
transaction if necessary.
Using Audited and Nonaudited Files
TMF recovery strategy involves backing out the aborted transaction changes; backing
out those changes enables the transaction to be reexecuted from the beginning (with a
new transaction identifier). This strategy means that if you decide to have a mixture of
audited and nonaudited files in the database, you must be careful: only changes to
audited files are backed out. If a transaction works on a mix of audited and nonaudited
files, the operations on the nonaudited files must be retryable.
A retryable operation is an operation that can be interrupted and repeated an indefinite
number of times without affecting the consistency of the database; for example, all
reading operations are retryable. Whether or not a writing operation (on a nonaudited
file) is retryable depends on your criteria for consistency of the data in the database. If
the transaction changes both audited and nonaudited files, you should analyze the
transaction to determine whether backing it out and reexecuting it affects consistency.
For example, consider a transaction that extracts records from a database, computes
some aggregates like averages or means, and then uses the aggregates to extract a subset
of the extracted records from the database for summary reporting. This transaction can
be implemented by doing the extraction twice, the first time to compute the aggregates
and the second time to extract the 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.
The following 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.
Note. Whenever your server begins work on a new queued message, it must call the
ACTIVATERECEIVETRANSID procedure to change the current transaction identifier, as
described in the NonStop TM/MP Application Programmer’s Guide.