Distributed Name Service (DNS) Management Programming Manual

Using SPI to Build Commands and Decode Responses
SPI Programming Considerations for DNS
3–10 46958 Tandem Computers Incorporated
TMF Considerations Any update request must have a valid TMF transaction ID. If not, the name manager
replies with a return code of ZDNS-ERR-NOTRANSID. When an error occurs in an
update transaction, it is the requester’s responsibility to call ABORTTRANSACTION.
Similarly, if an update command completes successfully, it is the requester’s
responsibility to call ENDTRANSACTION.
A requester may make multiple requests to the name manager as part of the same
TMF transaction. In these cases, you should take note of the following:
The name manager single-threads updates to the DNS database by locking the name
file; hence, most requests by other requesters are suspended for the duration of the
transaction. Since updates to the DNS database are expected to be infrequent, this
implementation should not impose a severe performance penalty.
Delete and copy operations may result in a large number of record or key locks being
held by the transaction. Each delete or copy operation should be a separate TMF
transaction. This is why the DELETE and COPY commands do not allow sets of
names to be specified; these commands operate only on a single name. You can
implement set-oriented delete and copy operations by using ZDNS-CMD-INFO
together with ZDNS-CMD-COPY or ZDNS-CMD-DELETE.
Most TMF servers are opened with SYNCDEPTH = 0 to inhibit automatic path failure
retry by the file system. The name manager, however, does accept opens that specify
SYNCDEPTH = 1. In this case, if the primary name-manager process fails during an
update operation, the file system automatically routes the request to the former
backup using the same SYNCID. The former backup detects this duplicate request
and responds with ZSPI-TKN-RETCODE = ZDNS-ERR-TAKEOVER, signaling the
requester to abort the transaction.