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

call to SERVERCLASS_SEND_) is, in effect, a dialog consisting of a single send operation. Pathway
servers that are coded to be context-free can participate in single-send dialogs with context-sensitive
requesters. 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 70) later in this section.
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, refer to “Writing a
Server to Use the TMF Subsystem” (page 66), later in this section, for a checklist of changes to
make.
One process (usually the requester) 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 requesters and servers is by standard interprocess I/O. The requester
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 process’s current
transaction 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, refer to 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,
refer to the Enscribe Programmer’s Guide.
Servers do not reply to request messages until all work for the request has been completed. The
contents of the reply message indicate 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 requester can commit the transaction. In the second case, the requester can
commit the transaction and then retry it. In both of these cases, the information in the server’s reply
is sufficient to ensure the integrity of the transaction.
Considerations for Servers That Use the TMF Subsystem 65