TRANSFER Programming Manual

Planning High-Level Transactions
Developing TRANSFER Applications
8–12 40970 Tandem Computers Incorporated
Your application should abort TMF transactions whenever a server detects an
error that would make the database inconsistent. An example of such a TMF
transaction is one in which one item is being attached to, or detached from,
another. This involves changing both the PARENT-COUNT of the component
item and the COMPNT-COUNT of the parent item; an error occurring between
these changes would leave the TRANSFER database inconsistent.
Caution Always abort a transaction when a data file is full or when any error that your program is not prepared to
handle is returned on a file. Always abort a transaction when the BAD-TRANSACTION message is
returned. This indicates a fatal error, such as the transaction itself no longer existing in the system, a
recipient's node going out of service, or some type of system failure.
In addition to this information, you should be aware of the following points that relate
specifically to TRANSFER applications:
If the TRANSFER database is audited exactly as recommended in the TRANSFER
Installation and Management Guide, the TRANSFER delivery system makes the
following guarantees:
The TRANSFER delivery system delivers every successfully submitted
package within the time window specified for the package or notifies the
sender of its failure to deliver that package. The TRANSFER delivery system
delivers a package only once to each recipient. If a failure to deliver a package
occurs, the TRANSFER delivery system delivers its failure notification only
once.
If a TMF rollforward operation is performed and the program that rebuilds the
TRANSFER scheduler queues is run following a catastrophic (multipoint)
failure, all submit and cancel operations in progress at the time of the failure
will be performed again to completion.
All active (usable) data in the TRANSFER database will remain consistent at
all times.
While servicing a request, the TRANSFER delivery system might perform many
input/output operations on the TRANSFER database. Under TMF transactions,
these updates require record locking to ensure database consistency and integrity.
The maximum number of locks that can be acquired for each partition of a file in
any database is limited. Transactions might be affected by the lock limits of TMF
in some cases. To prevent difficulties imposed by these locking limits, keep the
number of records per item, items per folder, recipients per distribution list, or
recipients per package to moderate levels.