Pathway/iTS TCP and Terminal Programming Guide

Managing Transactions With the TMF Subsystem
Compaq NonStop™ Pathway/iTS TCP and Terminal Programming Guide—426751-001
5-12
TCP Checkpointing Strategy
the transaction is automatically aborted by the file system. In such a case the requester
program discovers that the transaction was aborted when it subsequently attempts to
update the database (with another SEND statement) or issues an END-TRANSACTION
statement.
TCP Checkpointing Strategy
In a PATHMON environment with the TMF subsystem running, the TCP uses the
following checkpointing strategy:
•
At the BEGIN-TRANSACTION statement, a full copy of the task’s context is made
to a secondary area (slot 1) in the extended data segment, and a checkpoint to the
backup is performed.
•
At the END-TRANSACTION statement, a full-context checkpoint is performed.
•
At the SEND statement with the SET SERVER TMF parameter defined as OFF, a
checkpoint is performed before and after the SEND statement when the SCREEN
COBOL program is outside of transaction mode.
Any time a SEND operation is performed outside of a transaction boundary and the
server attempts to lock or update a record in an audited file, the operation fails with
a Guardian file-system error 75.
•
At the SEND statement with the SET SERVER TMF parameter defined as ON, no
checkpoints are performed, whether or not the SCREEN COBOL program is in
transaction mode. Therefore, SEND requests to TMF protected servers that operate
on audited files require fewer checkpoints than SEND requests to servers that do not
operate under TMF protection.
TCP checkpointing requirements can be reduced significantly if Pathway applications
that use the TMF subsystem have the servers read outside of transaction mode before
updating the database.
You can improve the performance of a Pathway application by taking advantage of the
TCP checkpointing strategy for TMF protected servers, as follows:
•
Do not use transaction mode for a server with read-only access to a database if the
requester displays the data before any attempt is made to change the data. In the
event of a failure, the requester can retry the read operations and fault-tolerant
operation is maintained.
•
Do not use transaction mode for a server that writes to an entry-sequenced logging
file in which duplicates are acceptable. In the event of a failure, the requester can
retry the write operations, so there is no need to back out the write. In contrast, a
key-sequenced file requires a backout; otherwise, the transaction fails when the
second write is attempted at the same location.
Caution. If a SEND request outside of transaction mode is sent to a TMF protected server that
operates on nonaudited files, data might be lost because the TMF subsystem is not invoked,
and the TCP performs fewer checkpoints.