TMF Application Programmer's Guide (G06.24+)

Designing Single-Threaded Processes
HP NonStop TMF Application Programmer’s Guide—522419-004
2-13
WRITEREAD to Another Server
abortion: a requester cannot commit a transaction until all servers doing work under
the transaction identifier have issued replies.
There are some types of interprocess messages—notably status messages sent by
the operating system—that do not require a reply. Because there is no way to know in
advance what type of message is in $RECEIVE, TMF servers must always use
READUPDATE to accept incoming messages. If a particular message does not require
a reply, the server completes the READUPDATE by issuing a REPLY call containing
no parameters.
WRITEREAD to Another Server
A server can also subcontract work to other servers. The server does so in the same
way as a requester: open the subordinate server, send a work request, and eventually
close the server.
If a server is communicating with subordinate servers by using nowait WRITEREAD
calls, however, the server must not reply to its own requester until all subordinate
servers have issued their replies. If a server tries to issue a reply before having
received replies from all of its subordinate servers, the file system rejects the REPLY
call with a condition code of CCL and an error number 81 (nowait I/O pending).
The server’s current transaction, if not preset to the nil state, is passed with the work
request to the subordinate server. Note that a server sets its current transaction to the
nil state exactly as a requester does—by issuing a RESUMETRANSACTION (0) call.
Unlike requesters, however, a server restores the current transaction to the transaction
identifier of an active transaction by issuing an ACTIVATERECEIVETRANSID (tag)
call, where tag is the value obtained by using the LASTRECEIVE system procedure.
The Use and Implications of ABORTTRANSACTION
At any time after doing a READUPDATE of $RECEIVE and before issuing a
corresponding reply, a server can abort the current transaction by issuing an
ABORTTRANSACTION call.
ABORTTRANSACTION backs out all of the changes that were made to audited files
on behalf of the aborted transaction. ABORTTRANSACTION also prevents any further
changes from being made to audited files on behalf of the aborted transaction (or at
least guarantees that any such changes will be undone shortly after occurring).
A server can abort the transaction even if there are subordinate servers that still have
work in progress on behalf of the transaction.
ABORTTRANSACTION returns control to the server immediately. Even though the
server has aborted the transaction, the server must still reply to its requester. A call to
ABORTTRANSACTION merely aborts the current transaction; it does not complete the
requester’s WRITEREAD call, which is waiting for a reply.
A call to ABORTTRANSACTION automatically resets the server’s current transaction
to the nil state.