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

These examples demonstrate how you might apply these guidelines.
Example 1
Some logical transactions do not have to be identified as TMF transactions. For example, a logical
transaction locates a single record and displays the record contents. Because this transaction
changes nothing in the database, it does not affect consistency and does not have to be a TMF
transaction.
Example 2
A data-entry transaction with a group of accesses that insert new data into the database should
be a TMF transaction. For example, a logical transaction records receipt of some items for a
stockroom by accepting the stock codes and quantity received from a data-entry operator and then
updates the records (in an audited file) for the items.
Because the first guideline applies, you should arrange to begin a TMF transaction after the data
is accepted and to end the transaction after the last record is updated. The TMF subsystem ensures
that all changes resulting from the one operator entry either are permanent or are backed out in
case the transaction aborts. Note that because any change to an audited file requires a transaction
identifier, this example is also true if the transaction inserts only one record in the file.
Example 3
An update transaction should be a TMF transaction. For example, assume a logical transaction:
1. Accepts a specification from the operator
2. Performs the equivalent of an inquiry operation to find the data that will be updated
3. Releases the locks obtained for the inquiry
4. Displays the data for the operator
5. Accepts modifications to the displayed data (saving a copy of the original displayed data)
6. Performs the inquiry a second time
7. Verifies that the results of the first inquiry and the second inquiry are the same
8. Writes the modified record to the database
The transaction should be implemented as two TMF transactions. The first should begin after the
data is accepted and should end (rather than release the locks) after the last record is read. The
second should begin after the modifications to the displayed data have been accepted and should
end after the last modified record is written to the database. If the inquiry part of the transaction
is just a single read, however, there is no need for the first inquiry to be part of a TMF transaction.
Servers as Process Pairs
When you are using the TMF subsystem, you should not write your server processes as fault-tolerant
process pairs. The additional programming and functional overhead required to do so is
unnecessary. If your servers are already coded as process pairs, however, it is not usually necessary
to change them back to ordinary servers. For such servers, note that if the primary server process
fails, the backup process (on takeover) does not have a current-transaction identifier. This means
that the server process receives error 75: NO CURRENT-TRANSACTION IDENTIFIER on the first
I/O request to an audited file. You should insert code into such a server either to recognize this
error and report it as a failure to the requester, or to terminate when it receives this error.
Because the COBOL85 run-time library recognizes the PARAM named NONSTOP, you can prevent
a COBOL85 server from running as a process pair by having a PARAM NONSTOP OFF in effect
when the server is started. For Pathway servers, you can accomplish this task by including PARAM
NONSTOP OFF with the parameters in the definition of the server class during PATHMON
configuration. When PARAM NONSTOP OFF is in effect when the server is started, the COBOL85
run-time library ignores the STARTBACKUP and CHECKPOINT verbs and stores the successful
completion code in the PROGRAM-STATUS special register.
68 Writing Pathway Servers