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

Designing Multithreaded Processes

HP NonStop TMF Application Programmer’s Guide—522419-005

3-3

Nowait ENDTRANSACTION Calls

Because multithreaded requesters are designed to work on multiple transactions in an

interleaved fashion, the requesters must be designed to use both nowait I/O and

nowait ENDTRANSACTION calls. When the requester issues a nowait

ENDTRANSACTION call, TMF does not suspend the requester but rather allows it to

continue working on other transactions as the ENDTRANSACTION processing

proceeds.

The current transaction identifier remains unchanged until the ENDTRANSACTION call

completes successfully. Under certain circumstances governed by timing, nowaited

READ operations executed immediately following ENDTRANSACTION calls can

incorrectly report transaction id errors. To ensure correct behavior and error reporting,

you should always issue a RESUMETRANSACTION(0d) call immediately after each

ENDTRANSACTION call.

The requester uses the AWAITIO procedure to recognize completions of its nowait

requests. Besides ENDTRANSACTION, the nowait requests can include WRITEREAD

requests to servers, interprocess communication with other processes, and perhaps

even updates to Enscribe database files.

When an AWAITIO call completes, it returns two pieces of information that identify the

nowait call with which the completion is associated: values for filenumber and tag.

For WRITEREADs to servers, filenumber is returned by the OPEN procedure when

the requester opened the particular process. For updates to Enscribe database files,

filenumber is returned by OPEN when the requester opened the particular file.

For ENDTRANSACTION calls, however, filenumber is returned by OPEN when the

requester opened its TFILE.

The tag value returned by AWAITIO identifies the particular transaction associated with

the completed nowait operation; it is the same value that was returned by the

BEGINTRANSACTION call that initiated the transaction.

Checkpointing Strategy

To describe the proper placement of checkpoints within multithreaded TMF requesters,

the topics that follow examine the general flow of control within the sample requester

illustrated in Figure 3-1, Figure 3-2 and Figure 3-3.

The sample requester accepts input from a set of terminals. The requester does that

by displaying a data entry form on each terminal and then issuing nowait READ calls,

one per terminal. After filling in the applicable fields on the form, the terminal operator

presses a function key causing an AWAITIO completion and the initiation of a new

transaction.

The sample requester responds to all error conditions by aborting the transaction and

refreshing the READ to the affected terminal. The requester does not try to determine

what type of error occurred or to make any decisions based on the error condition.