TS/MP 2.5 Pathsend and Server Programming Manual

requestors. However, if these servers check for system messages, you must modify them so that
they recognize Pathsend dialog abort system messages, as described under “Writing
Context-Sensitive Servers” (page 69) later in this chapter.
Considerations for Servers That Use the TMF Subsystem
If you are writing a Pathway server that uses the TMF subsystem for transaction management, a
number of additional programming considerations apply, related to these topics:
• Recommended application structure
• Writing a server to use the TMF subsystem if your application does not follow the recommended
structure
• Using audited and nonaudited files
• Record locking
• Grouping transaction operations
Recommended Structure for Applications
The recommended structure for applications that use the TMF subsystem is described in this
subsection. If your current or planned application has these characteristics, programming the
application to use the TMF subsystem is relatively straightforward; otherwise, see “Writing a Server
to Use the TMF Subsystem” (page 65), later in this chapter, for a checklist of changes to make.
One process (usually the requestor) coordinates all the work required to do a single TMF transaction;
this process identifies the beginning and ending points of each transaction. Additionally, if the
server replies to a request message by indicating that it failed to complete all the changes, this
process can either abort and abandon the transaction or abort and retry the transaction.
The communication between requestors and servers is by standard interprocess I/O. The requestor
does the send operation, and the server does the READUPDATE call for $RECEIVE and the REPLY
call. Each request message and the server’s reply to the message is for a single transaction.
Any disk I/O request is for a single transaction. The TMF subsystem appends the current transaction
of the process identifier to each disk-request message so that the audit trails can include the identity
of the transaction responsible for each database change.
How concurrency control is performed depends on which RDBMS is being used. If the SQL/MP
RDBMS is used, concurrency control is done by means of SQL/MP access options. Use of the
access options causes SQL/MP software to generate the appropriate TMF transactions as required;
therefore, servers that use SQL/MP databases are not required to include TMF procedure calls or
statements. For information about use of the SQL/MP access options, see the NonStop SQL/MP
Reference Manual. For servers that use the Enscribe database record manager, concurrency control
is done by using the Enscribe locking facilities, and you must program the transactions by using
TMF procedure calls or statements. For information about use of the Enscribe locking facilities, see
the Enscribe Programmer’s Guide.
Servers do not reply to request messages until all work for the request is completed. The contents
of the reply message indicates the outcome of the request, which is one of these:
• All the work for the request was completed successfully.
• None of the work for the request was completed.
• The work for the request was only partially completed.
In the first case, the requestor can commit the transaction. In the second case, the requestor can
commit the transaction and then retry it. In both of these cases, the information in the reply of the
server is sufficient to ensure the integrity of the transaction.
However, if the transaction work was only partially completed, as in the third case, the server
needs to ensure that the transaction is not committed so that the incomplete work can be backed
64 Writing Pathway Servers