Order Number: AA-Q88BH-TE

This manual explains how to design and code applications for Reliable Transaction Router (RTR) using the C programming language. It contains full descriptions of the RTR C application programming interface (API) calls, and includes a short tutorial.

Revision/Update Information: This manual supersedes the Reliable Transaction Router Application Programmer's Reference Manual, Version 4.1.

Software Version: Reliable Transaction Router Version 4.2

Hewlett-Packard Company
Palo Alto, California

© 2003 Hewlett-Packard Development Company, L.P.

Microsoft, MS-DOS, Windows, and Windows NT are US registered trademarks of Microsoft Corporation.

Intel is a US registered trademark of Intel Corporation.

UNIX is a registered trademark of The Open Group.

Confidential computer software. Valid license from HP and/or its subsidiaries required for possession, use, or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's commercial license.

Neither HP nor any of its subsidiaries shall be liable for technical or editorial errors or omissions contained herein. The information in this document is provided "as is" without warranty of any kind and is subject to change without notice. The warranties for HP products are set forth in the express limited warranty statements accompanying such products. Nothing herein should be construed as constituting an additional warranty.

Contents

Index

Purpose of This Manual

This manual is the reference source for persons writing application programs using Reliable Transaction Router (RTR) in the C programming language. It completely describes the RTR C application programming interface (API).

Document Structure

This manual contains four chapters and two appendices:

• Chapter 1 introduces the RTR C programming interface.
• Chapter 2 provides a guide to writing RTR applications.
• Chapter 3 describes the RTR C Application Programming Interface (API) showing the syntax and data structures for each RTR call.
• Chapter 4 describes how to compile and link your application.
• Appendix A provides two short RTR C API sample applications and their shared and header files.
• Appendix B provides a short tutorial for the application programmer.

Related Documentation

Table 1 describes RTR documents and groups them by audience.

Table 1 RTR Documents

Document	Content
For all users:
Reliable Transaction Router Release Notes 1	Describes new features, changes, and known restrictions for RTR.
Reliable Transaction Router Getting Started	Provides an overview of RTR technology and solutions, and includes the glossary that defines all RTR terms.
Reliable Transaction Router Commands	A pocket-sized handbook that lists all RTR commands, their qualifiers and defaults.
Reliable Transaction Router Software Product Description	Describes product features.
For the system manager:
Reliable Transaction Router Installation Guide	Describes how to install RTR on all supported platforms.
Reliable Transaction Router System Manager's Manual	Describes how to configure, manage, and monitor RTR.
Reliable Transaction Router Migration Guide 2	Explains how to migrate from RTR Version 2 to RTR Version 3 or 4 (OpenVMS only).
For the application programmer:
Reliable Transaction Router Application Design Guide	Describes how to design application programs for use with RTR, with both C++ and C interfaces.
Reliable Transaction Router C++ Foundation Classes	Describes the object-oriented C++ interface that can be used to implement RTR object-oriented applications.
Reliable Transaction Router C Application Programmer's Reference Manual	Explains how to design and code RTR applications using the C programming language and the RTR C API. Contains full descriptions of the basic RTR API calls.

You can find additional information about RTR, including the Software Product Descriptions, on the RTR website found through http://www.hp.com links to middleware products or at http:://www.hp.com/go/rtr.

Conventions

Table 2 describes the conventions used in this guide.

Table 2 Conventions

Convention	Meaning
boldface	Boldface is used for emphasis.
italic	Italics indicate arguments or variables, and titles of manuals.
rtr_start_tx()	Monospaced font indicates the name of an RTR API call in text, constants, and RTR message types returned by an RTR call.
RTR_STS_OK	Small capitals show RTR commands and return status values in text and examples.
...	Horizontal ellipsis in examples indicates one of the following: Additional arguments in a statement have been omitted. The preceding item can be repeated one or more times. Additional parameters, values, or other information can be entered.
. . .	Vertical ellipsis indicates the omission of items from a code example or command format.
numbers	All numbers in text are decimal, unless otherwise noted. Nondecimal radixes---binary, octal, or hexadecimal---are explicitly indicated.
/* ...*/	Comments in source code.
-	Continuation character in command-line and some programming examples.

Reading Path

The reading path to follow when using the Reliable Transaction Router information set is shown in Figure 1.

Figure 1 RTR Reading Path

This chapter introduces the Reliable Transaction Router C programming interface. This interface was formerly called the Portable API. RTR concepts and terms are fully defined in Reliable Transaction Router Getting Started.

1.1 RTR Application Programming Interface

The RTR C application programming interface (API) that is provided with Reliable Transaction Router is identical on all hardware and operating system platforms that support RTR. This API is described in the following chapter.

In addition, a web browser and a command line interface (CLI) to the C API are available. The CLI enables you to write simple RTR applications for testing. The RTR CLI is illustrated in Reliable Transaction Router Getting Started and fully described in the Reliable Transaction Router System Manager's Manual.

1.2 C Programming and RTR APIs

The C-programming RTR API was made available in Reliable Transaction Router Version 3. It superseded the OpenVMS API used in Reliable Transaction Router Version 2 for new applications. The RTR C API is available on all platforms on which RTR is supported.

1.2.1 Compatibility Between RTR Versions

Reliable Transaction Router Version 4 interoperates with RTR Version 3 and with RTR Version 2.2 in a DECnet environment using DECnet Phase IV naming. (The same version of RTR must be installed on all routers and backends. See the section on Network Transports in the Reliable Transaction Router System Manager's Manual to find out how to configure your Version 4 nodes.)

Note that the size of an RTR transaction ID was changed in Reliable Transaction Router Version 3 to 28 bytes. (The change ensures that the transaction ID contains a unique node specification.) This remains true for later versions of RTR.

1.2.2 Reasons for a C Programming API

RTR was first developed for use within an OpenVMS environment. Reliable Transaction Router Version 3 extended the applicability of RTR to allow users to create fault-tolerant distributed applications running on networks of heterogeneous machines and platforms.

The OpenVMS API presented some incompatibilities when used on non-OpenVMS platforms as follows:

1. The "$" character contained in all RTR identifiers is not permitted in identifiers in some languages.
2. There was no provision for reformatting user messages passed between machines to account for differing machine representations of particular data types.
3. RTR permits applications to be written to perform multiple concurrent operations, a feature that can be critical for good performance in high-volume transaction processing systems. The notification mechanisms used to indicate completion of such asynchronous operations (event-flag, txsb, completion-AST) were OpenVMS-specific.

The benefits of using the C programming API are:

• Portability over a wide range of language and machine environments
• Simplified handling of concurrency, independent of the type of operating system
• Support for communication between machines with different hardware representations of common data types (little-endian and big-endian, and so forth)
• Interoperability with existing applications using the OpenVMS API
• Features extended above those provided by the OpenVMS API
• Improved performance for commonly-used transaction types
• Support for use within a threaded environment

The C programming API has been designed to:

• Avoid the problem of applications dropping threads.
• Simplify the API.
• Schedule concurrent application operations in the same FIFO manner as is used with AST-driven processing on OpenVMS. This avoids the synchronization worries faced by the application writer when working with ASTs.
• Make it impossible for an application to stall by waiting for one operation to complete and hence being unable to respond to some other event.
• Permit a more efficient implementation. RTR does not have to maintain multiple internal queues.

Table 1-1 compares the OpenVMS and C Programming API calls.

Table 1-1 OpenVMS API (V2) and C Programming API (V3) Compared

OpenVMS API	C Programming API
$dcl_tx_prc()	rtr_open_channel()
$start_tx()	rtr_start_tx() [optional]
$commit_tx()	rtr_accept_tx()
$abort_tx()	rtr_reject_tx()
$vote_tx()	rtr_accept_tx()/rtr_reject_tx()
$deq_tx()	rtr_receive_message()
$enq_tx()	rtr_send_to_server()/ rtr_reply_to_client()/rtr_broadcast_event()
$dcl_tx_prc() (SHUT)	rtr_close_channel()
$get_txi()	rtr_request_info()
$set_txi()	rtr_set_info()
ASTPRM (on asynch calls)	rtr_set_user_handle()
--	rtr_error_text()
--	rtr_get_tid()
--	rtr_set_wakeup()

The term C programming API is used to describe the RTR application programming interface (API) adopted in Reliable Transaction Router Version 3. This API is available on all platforms on which Reliable Transaction Router is supported. This API was formerly called the Portable API, when first made available on several operating systems.

2.1 Transactional Messages

RTR allows the client and server applications to communicate by entering into a dialogue consisting of an exchange of messages between a client application (the dialogue initiator) and one or more server applications.

Each dialogue forms a transaction in which all participants have the opportunity to either accept or reject the whole transaction. When the transaction is complete, all participants are informed of the transaction's completion status: success ( rtr_mt_accepted ) if all participants accepted it, failure ( rtr_mt_rejected ) if any participant rejected it. (For more information on messages, see Section 2.11, RTR Messages.)

2.2 RTR Channels

With RTR, applications can be engaged in several transactions at a time.

To support many in-progress transactions at the same time, RTR lets applications open multiple channels. An application opens one or more channels to RTR, and any transaction is associated with only one channel. The transaction is said to be active on that channel. For example, a client application opens a channel and then sends the first message of a transaction on that channel. All messages sent and received for that transaction are now associated with that channel.

While waiting for a response from the server, the client application can open a second channel and start a new transaction on it. When the transaction on the first channel has completed, the client application may start the next transaction on it, or simply issue the rtr_accept_tx call.

Similarly, a server application may open several channels and, when the first message of a new transaction arrives, RTR delivers it on the first available channel. That channel remains associated with the transaction until it completes.

An application opens a channel before it can send or receive messages; the RTR API call rtr_open_channel is used to do this. The RTR call specifies whether the channel is a client channel or a server channel; it cannot be both. (This restriction helps to simplify application structure, and to deal with the special properties of each channel type.) A single application can, however, open client channels and server channels.

2.3 Broadcast Messages and Events

In addition to transactional messages, client or server programs may broadcast event messages. These are delivered to some subset of the distributed applications, as specified by the event-number and event-name parameters. In contrast to transactional dialogues, no completion status is subsequently returned to the initiator. A message can be from 0 to 64K bytes long.

Both client and server channels receive messages from RTR. A client channel receives event messages only from servers, and a server channel receives event messages only from clients. To enable a client application to receive event/broadcast messages from another client application, the application must be both a client and a server application (open a channel with both CLIENT and SERVER flags), and must be in a facility on a node that is both a frontend and a backend. A broadcast event can be sent as long as the server channel is open. Events are more fully described in Section 2.12, RTR Events.

2.4 C Programming API Calls

The C Programming API calls are shown in Table 2-1, C Programming API Calls. Each call is shown with a brief description and whether it can be used on client channels or server channels or both. Calls are listed in alphabetical order.

Table 2-1 C Programming API Calls

RTR Call	Description	Channel Use
rtr_accept_tx	Accepts a transaction	Client and server
rtr_broadcast_event	Broadcasts (sends) an event message	Client and server
rtr_close_channel	Closes a previously opened channel	Client and server
rtr_error_text	Gets the text for an RTR status number	Client and server
rtr_ext_broadcast_event	Broadcasts (sends) an event message with a timeout	Client and server
rtr_get_tid	Gets the current transaction ID	Client and server
rtr_get_user_context	Gets the user-defined context associated with a channel	Client and server
rtr_open_channel	Opens a channel for sending and receiving messages	Client and server
rtr_receive_message	Receives the next message (transaction message, event or completion status)	Client and server
rtr_reject_tx	Rejects a transaction	Client and server
rtr_reply_to_client	Sends a response from a server to a client	Server only
rtr_request_info	Requests information from RTR	Client and server
rtr_send_to_server	Sends a message from a client to the server(s)	Client only
rtr_set_info	Sets an RTR parameter	Client and server
rtr_set_user_context	Sets the value of the user-defined context for a channel	Client and server
rtr_set_user_handle	Associates a user value with a transaction	Client and server
rtr_set_wakeup	Sets a function to be called on message arrival	Client and server
rtr_start_tx	Explicitly starts a transaction	Client only