TS/MP 2.5 Pathsend and Server Programming Manual

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 must 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 must 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 must 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 must be implemented as two TMF transactions. The first begins after the data is
accepted and ends (rather than release the locks) after the last record is read. The second begins
after the modifications to the displayed data have been accepted and ends after the last modified
record is written to the database. If the inquiry part of the transaction is just a single read, however,
the first inquiry does not have to be part of a TMF transaction.
Servers as Process Pairs
When you are using the TMF subsystem, you must 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, 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 must insert code into such a server either to recognize this error
and report it as a failure to the requestor, 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.
There is no comparable mechanism to indicate that a server process coded in TAL, pTAL, or
FORTRAN must not run as a process pair. If you have server processes in these languages that are
coded as process pairs, you can either implement a custom PARAM or recode your server.
Considerations for Servers That Use the TMF Subsystem 67