hp Reliable Transaction Router

hp Reliable Transaction Router

C Application Programmer's
Reference Manual

Order Number: AA-Q88BH-TE


April 2003

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


Preface

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:


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.


1Distributed on software kit.
2Softcopy only.

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



Chapter 1
Introduction

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.

1.2.3 Benefits of the C Programming API

The benefits of using the C programming API are:

The C programming API has been designed to:

1.2.4 Comparison of OpenVMS and C Programming API Calls

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()


Chapter 2
Overview of the C Programming API

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.

Note

In the context of RTR, client and server are always 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


Next Contents Index