Queue Manager Manual

Application Development Steps
Developing Queue Manager Applications
3–4 46517 Tandem Computers Incorporated
If the transaction is aborted during a DEQ operation, consider having the server
process that just dequeued the entry enqueue it back on the Queue.
A TMF transaction should never span a read operation from a terminal. If you
allow a TMF transaction to span a terminal read, the record locks involved in the
transaction might be held for a very long time, delaying access by other users.
Also, if the user leaves the terminal with a TMF transaction still in progress and an
error occurs, audit trails on disk cannot be purged.
If your application includes interfaces to terminals, start the TMF transaction
immediately after completion of the terminal read for any request that requires a
transaction. End this TMF transaction immediately before the next terminal read.
This precaution enhances Queue file availability.
TMF does not allow the audit trail records for a single transaction to span more
than a certain number of audit trail files, as determined by a TMFCOM parameter.
Thus, if a transaction takes so long that several audit trail file switches occur, TMF
aborts the transaction.
Requests that do not involve changes to files on disk do not require a TMF
transaction, for example, a WAITQ UOW.
Note Always abort a transaction when a data file is full or when any error that your program is not prepared to
handle is returned on a file. Always abort a transaction when the BAD-TRANSACTION message is
returned. This indicates a fatal error, such as the transaction itself no longer existing in the system, a
recipient's node going out of service, or some type of system failure.
For additional information on TMF transaction processing, refer to the Transaction
Monitoring Facility (TMF) Management Programming Manual.
Step 7: Planning Low-Level
Implementation
Low-level implementation includes packaging your application in individual modules
and subroutines, breaking the application up into small groups of functions.
Examples of these are COBOL or SCREEN COBOL programs, FORTRAN subroutines,
TAL or Pascal procedures, or C files. This step also involves carefully planning the
interfaces between these modules and subroutines, and deciding what information is
passed between them.
Remember that you can copy UOW data definitions for SCREEN COBOL, COBOL,
FORTRAN, and TAL programs from files supplied by Tandem—but you must write
your own UOW definitions for Pascal or C programs, using the UOW specifications
that appear in this manual.
Plan for various accounting procedures, for collecting usage statistics, and for the
logging of particular events and errors.
Plan also the methods for reporting errors to users. Your application can find out
about errors in several different ways.
Errors in a request, but not specific to a UOW, are reported by Queue Manager in
the reply header. These errors usually indicate programming errors in the