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

Writing Pathway Servers

NonStop TS/MP Pathsend and Server Programming Manual–132500

4-10

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.

There is no comparable mechanism to indicate that a server process coded in TAL,

pTAL, or FORTRAN should 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.

Transaction Deadlocks

An application that uses the TMF subsystem might hold more record locks and hold

them longer than it would without the TMF subsystem because:

•

Implicit locks are held on the keys of deleted records.

•

Implicit locks are held for inserted records.

•

Locks are held until the transaction is either committed or aborted and backed out.

The increased locking could cause new possibilities for transaction deadlock. If

transaction deadlock might become a problem, consider implementing the methods for

coping with deadlock discussed in the Guardian Programmer’s Guide.