June, 1999 Reliable Transaction Router (RTR) is an open client/server middleware for continuous computing.

RTR Engineering is pleased to announce that RTR Version 3.2 is now available.

Operating System and Version: Windows NT Version 4.0
Windows 95, Windows 98
Compaq Tru64 UNIX (formerly DIGITAL UNIX) Version 4.0D, 4.0E, 4.0F
Sun Solaris Version 2.5, 2.5.1, 2.6, 7
IBM AIX Version 4.2, 4.3
Hewlett-Packard HP-UX Version 10.20
OpenVMS Version 6.2, 7.1, 7.2

Software Version: Reliable Transaction Router Version 3.2

Compaq Computer Corporation
Houston, Texas

COMPAQ COMPUTER CORPORATION SHALL NOT BE LIABLE FOR TECHNICAL OR EDITORIAL ERRORS OR OMISSIONS CONTAINED HEREIN, NOR FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES RESULTING FROM THE FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL. THIS INFORMATION IS PROVIDED "AS IS" AND COMPAQ COMPUTER CORPORATION DISCLAIMS ANY WARRANTIES, EXPRESS, IMPLIED OR STATUTORY AND EXPRESSLY DISCLAIMS THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR PARTICULAR PURPOSE, GOOD TITLE AND AGAINST INFRINGEMENT. This publication contains information protected by copyright. No part of this publication may be photocopied or reproduced in any form without prior written consent from Compaq Computer Corporation.

Copyright ©1999 Digital Equipment Corporation

The software described in this guide is furnished under a license agreement or nondisclosue agreement. The software may be used or copied only in accordance with the terms of the agreement.

Compaq and the Compaq logo are registered in the United States Patent and Trademark Office.

The following are trademarks of Compaq Computer Corporation: AlphaGeneration, AlphaServer, AlphaStation, Compaq Internet Personal Tunnel, DEC, DECconnect, DECdtm, DECnet, DIGITAL, OpenVMS, PATHWORKS, POLYCENTER, Reliable Transaction Router, TruCluster, Tru64 UNIX, VAX, and VMScluster.

The following are third-party trademarks:

AIX and IBM are registered trademarks of International Business Machines Corporation.
Encina is a registered trademark of Transarc Corporation.
Hewlett-Packard and HP-UX are registered trademarks of Hewlett-Packard Company.
Intel is a trademark of Intel Corporation.
Microsoft, Microsoft Access, Microsoft SQL Server, Internet Explorer, :MS--DOS, Visual Basic, Visual C++, Windows, Windows 95, Windows 98, and Windows NT are trademarks or registered trademarks of Microsoft Corporation.
Netscape, Netscape Communicator, and Netscape Navigator are registered trademarks of Netscape Communications Corporation.
Oracle, ORACLE7, PL/SQL, SQL*Net, AND SQL*Plus are trademarks or registered trademarks of Oracle Corporation.
Solaris, SPARCstation, SUN, SunOS, and Sunlink are trademarks or registered trademarks of Sun Microsystems, Inc.
UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company, Ltd.

Contents

Purpose of these Release Notes

This document provides information for Reliable Transaction Router, V3.2.

Intended Audience

These Release Notes are intended for all users of Reliable Transaction Router. Please read all of this document before using the product.

Document Structure

• Section 1 provides information applicable to all platforms.
• Section 2 provides information for Compaq Tru64 UNIX systems.
• Section 3 provides information for OpenVMS systems.
• Section 4 provides information for AIX systems.
• Section 5 provides information for SUN Solaris systems.
• Section 6 provides information for HP-UX systems.
• Section 7 provides information for Windows NT systems.
• Section 8 provides information for Windows 95 systems.

Related Documentation

• Reliable Transaction Router Installation Guide
• Reliable Transaction Router Application Programmer's Reference Manual
• Reliable Transaction Router System Manager's Manual
• Reliable Transaction Router Migration Guide
• Reliable Transaction Router Application Design Guide

Conventions

In this manual, every use of Alpha VMS means the OpenVMS Alpha operating system, every use of VAX VMS means the OpenVMS VAX operating system, and every use of VMS means both the OpenVMS Alpha operating system and the OpenVMS VAX operating system.

The following conventions are used to identify information specific to OpenVMS Alpha or to OpenVMS VAX:
The Alpha icon denotes the beginning of information specific to Alpha VMS.
The VAX icon denotes the beginning of information specific to VAX VMS.
The diamond symbol (<>) denotes the end of a section of information specific to Alpha VMS or to VAX VMS.

The following conventions are also used in this manual:

Convention	Meaning
boldface text	Boldface text represents the introduction of a new term or the name of an argument, an attribute, or a reason. Boldface text is also used to show user input in online versions of the manual.
italic text	Italic text emphasizes important information, indicates variables, and indicates complete titles of manuals. Italic text also represents information that can vary in system messages (for example, Internal error number), command lines (for example, /PRODUCER= name), and command parameters in text.
UPPERCASE TEXT	Uppercase text indicates a command, the name of a routine, the name of a file, or the abbreviation for a system privilege.
user input	This bold typeface is used in interactive examples to indicate typed user input.
system output	This typeface is used in interactive and code examples to indicate system output.

1 General Information Applicable to all Platforms

This chapter describes the new features, corrections, workarounds, and restrictions in Reliable Transaction Router, Version 3.2. Refer to later chapters for platform-specific information.

• 14-5-6 Create system management interface for RTR using BMC Patrol
  An RTR Knowledge Module has been developed for those environments that use the BMC PATROL Application Manager suite of software products. The RTR Knowledge Module can be installed on systems with RTR and Patrol Agent installed, and can be used to monitor RTR and perform system management operations. For more information on the Knowledge Module functionality, refer to the Insight Innovations web site or contact them directly. Insight Innovations can be reached as follows:
  Insight Innovations
  Level 13
  121 Walker Street
  North Sydney, NSW 2060
  Australia
  Telephone: +61 2 9460 3022
  FAX: +61 2 9923 1551
  Internet: http://www.inin.com.au/
• 14-5-43 Improved diagnostics
  The heading in the output from most RTR SHOW commands now includes the nodename, group and date.
  Diagnostic counters have been added to the RTR IPC layers. These can be viewed with the monitor pictures ipc.mon and ipcrate.mon. The former displayed raw counts whilst the latter displays rate information.
• 14-5-45 Named partition support
  Starting with RTR V3.2, backend partitions have a name attribute. Changes to the rtr_open_channel() API allow the caller to specify a partition name and to either supply a name for a partition to be created, or specify the name of an existing partition to which the application wishes to attach a server channel. RTR provides default names for existing applications.
  Partition names are subjects of partition management commands, also new for RTR V3.2.
• 14-5-46 Independent transaction flags added
  RTR normally assumes that each transaction processed by a given server depends on the transactions that particular server has previously accepted. To keep the shadowed database identical to that on the primary, RTR controls the order in which the secondary executes transactions. The secondary is constrained to execute transactions in the same order as the primary. Under some circumstances, this can lead to the secondary sitting idle, waiting to be given a transaction to execute. This release introduces a performance enhancement which may help some applications reduce idle time on the secondary, decreasing the corresponding backlog. If the application knows that particular transactions are independent of all transactions previously received, then the application can set one of two new flags:
  • RTR_F_ACC_INDEPENDENT Set on an rtr_accept_tx call to indicate this transaction is independent.
  • RTR_F_REP_INDEPENDENT Set on an rtr_reply_to_client call along with RTR_F_REP_ACCEPT to indicate this transaction is independent.
  
  A transaction accepted with one of these flags can be started on the secondary while other transactions are still running.
  All transactions flagged with one of these flags must truly be independent of transactions that have previously executed. They will execute in an arbitrary sequence on the secondary. They may not contend with each other, nor with previous transactions for record locks. They may not use data that has been updated by previous transactions, or by each other.
• 14-5-47 SET TRANSACTION command
  A new utility, RTR SET TRANSACTION, is introduced in the RTR V3.2 release. This utility will allow an RTR system administrator to change a transaction's journal state during runtime. It is useful to resolve some abnormal situations. Please refer to RTR System Manager's Manual for details.
• 14-5-48 DUMP JOURNAL enhancements
  The DUMP JOURNAL command provides an easy way to observe the contents of a node's journal file at any point in time. Various qualifiers allow for the selection of transactions that meet specific criteria, and a full or brief accounting of both transaction state and message data can be displayed to the screen or output to a file.
• 14-5-49 SET PARTITION/failover_policy command
  RTR V3.2 contains a new command, SET PARTITION/FAILOVER_POLICY, that allows the system operator to determine RTR behavior in selecting a site to make active in the event of the loss of the current primary site. Options allow the operator to choose between failover to a standby, or to a remote shadow site.
  The command may be invoked as a command line, or programmatically through the rtr_set_info() API.
  Additional information can be found in the appropriate sections of the Programmers Reference and System Manager's Manuals.
• 14-5-51 SET PARTITION/SUSPEND/RESUME
  RTR V3.2 contains new commands that allow the system operator to control the presentation of transactions to server applications. SET PARTITION/SUSPEND stops the presentation of transactions on a given backend partition. SET PARTITION/RESUME resumes transaction presentation to servers.
  The commands may be invoked as a command line, or programmatically through the rtr_set_info() API.
  Additional information can be found the appropriate sections of the Programmer's Reference and System Manager's Manuals.
• 14-5-52 SET PARTITION/[NO]SHADOW
  RTR V3.2 contains new commands that allow the system operator to control the state of shadowing for a partition. SET PARTITION/SHADOW enables shadowing for a partition. SET PARTITION/NOSHADOW disables shadowing for a partition.
  The commands may be invoked as a command line, or programmatically through the rtr_set_info() API.
  Additional information can be found the appropriate sections of the Programmer's Reference and System Manager's Manuals.
• 14-5-54 rtr_set_info()
  This release of RTR contains a limited implementation of the rtr_set_info() verb. See the RTR Application Programmers Guide for further information.
  RTR V3.2 allows programmed SET PARTITION and SET TRANSACTION commands through the rtr_set_info() call. Details on the usage of this call can be found in the RTR Application Programmers Reference Manual.
• 14-5-58 Create/delete partition
  V3.2 of RTR contains commands for the creation and deletion of named key range partitions. See the V3.2 System Manager's Manual for further information.
• 14-5-62 Create flag RTR_F_CLO_IMMEDIATE to close channel w/o acknowledging in-progress transaction
  A new flag, RTR_F_CLO_IMMEDIATE, has been added to the rtr_close_channel() call. Setting this flag causes RTR to recover an accepted transaction (if any) on this channel to an alternate server channel. Without this flag set, the rtr_close_channel() call implicitly acknowledges the successful completion of any post rtr_accept_tx() processing, such as any database commit processing, and the transaction is not recovered.
• 14-5-70 Add C++ example to kit
  A sample C++ application for RTR may now be found in the "examples" directory.
• 14-5-79 rtr_get_tid API enhanced to support XA and DecDTM Transaction Management
  The rtr_get_tid API call has been enhanced to return transaction identifiers associated with XA and DECdtm managed transactions. No change is required for applications which currently use rtr_get_tid to return native RTR transaction identifiers.
  The changed function prototype is as follows:

  rtr_status_t rtr_get_tid ( rtr_channel_t channel, rtr_tid_flag_t flags, void *ptid )

  
  The flags and ptid arguments now accept the following options:

  flag argument ptid data type Returns ------------- -------------- --------------------- RTR_NO_FLAGS rtr_tid_t RTR transaction id RTR_F_TID_RTR rtr_tid_t RTR transaction id RTR_F_TID_XA rtr_xid_t XA transaction id RTR_F_TID_DDTM rtr_ddtmid_t DECdtm transaction id

• 14-5-80 Specify ordered lists of backends
  RTR V3.2 contains a command SET PARTITION/PRIORITY_LIST that allows the system operator to specify to RTR an ordered list of the backends in the system. RTR will take this ordering into account when determining which of the eligible backend partitions should become the active member.
  The commands may be invoked as a command line, or programmatically through the rtr_set_info() API.
  Additional information can be found the appropriate sections of the Programmer's Reference and System Manager's Manuals.
• 14-5-84 Changes to monitor files
  The following monitor files have been changed to display prepare-related information:
  • acp2app.mon
  • app2acp.mon
  • calls.mon
  
  Do not screen-scrape RTR monitor pictures to get information about RTR. The API call rtr_request_info() should be used instead.
• 14-5-89 Recovery retry count
  A maximum retry count can now be assigned to active partitions, helping to maintain server availability in the presence of a transaction that repeatedly causes termination of one or more servers during recovery operations. When the retry count is exceeded, the errant transaction is written in the journal as an exception record so that processing may continue. This feature is documented in the RTR System Manager's Manual for the SET PARTITION command.
• 14-5-97 SHOW TRANSACTION enhancement
  In RTR V3.2, the SHOW TRANSACTION command is enhanced by adding some new qualifiers. This allows the system operator to filter the display of transactions further than was previously possible through the use of additional qualifiers. The new qualifiers are:
  • /state
  • /user
  • /partition_name
  • /since <OpenVMS-style date and time>
  • /before <OpenVMS-style date and time>
  
  Additional information on these qualifiers can be found in the appropriate sections of the RTR Application Programmer's Reference and RTR System Manager's Manuals.
• 14-5-99 The crm_tx_kr_jnl_state_t enum is exposed to the application programmer with rtr_request_info() calls.
  
  • In rtr.h the enum rtr_transaction_state_t has been replaced by rtr_tx_jnl_state_t.
  • In rtr.h the enum identifier verb_set has been replaced by rtr_verb_set.
  
  Details can be found in the System Manager's Manual.
• 14-5-104 DUMP JOURNAL command enhancement
  The DUMP JOURNAL command has been enhanced with the following features:
  • The command DUMP JOURNAL also shows how many prepare records have been processed.
  • The command DUMP JOURNAL /FULL also shows the prepare records if there are any on this node.
  • The command DUMP JOURNAL /RECORD_CLASS=PREPARE explicitly selects the prepare records in the journal for displaying.
• 14-5-109 rtr_rqif is an unsupported utility distributed with the RTR kit
  rtr_rqif is an unsupported utility distributed with the RTR kit. It is used as an interface to the rtr_request_info API by some third-party vendors providing RTR add-ons.
• 14-8-155 New environment variables for adjusting connection timeout parameters
  Two new environment variables have been created to give operators greater discretion in determining how long to wait before retrying a network connection attempt.
  The RTR_TIMEOUT_CONNECT variable controls how long a connecting node will wait for a response from the connectee to its link initiation request. This value defaults to 60 seconds.
  If the RTR_TIMEOUT_CONNECT period expires without a response from the connectee, RTR will wait an additional period determined by the RTR_TIMEOUT_CONNECT_RELAX variable. This variable defaults to a value of 90 seconds. The purpose of the "relax" period is to allow the connector to accept a connection request from the connectee node, if any are forthcoming. It is important not to set this value too low on Backends and Routers, as such machines are likely to be receiving connection requests from many other machines. On machines configured to use only the Frontend role, however, you can safely set RTR_TIMEOUT_CONNECT_RELAX to just a few seconds so that the node can be free to attempt to connect to another router as quickly as possible.
  The minimum value for RTR_TIMEOUT_CONNECT is 5 and the minimum for RTR_TIMEOUT_CONNECT_RELAX is 1.

This section addresses known problems corrected since V3.1D.

• 14-1-39 Declaring exit handlers in RTR applications
  If an exit handler contains calls to RTR, then the exit handler must be declared after the first call to RTR.
  Using the RTR V2 or V3 API, if the exit handler is declared before the first call to RTR, then any call to RTR made within the exit handler will return an error. Under the V3 API, the error status returned is RTR_STS_INVCHANNEL. Under the V2 API, the error status returned is RTR$_INVALCH.
• 14-1-99 Read-only strings and compiler optimization
  RTR performance has improved generally on some platforms as a result of new compiler versions and compiler option tuning. Memory required for each RTR and application process has been reduced by locating constant data and strings in shared read-only memory.
• 14-1-183 FE not detecting a non-responsive router
  Diagnostic information to monitor the operation on the inactivity timers on a link has been added as additional link counters. The values of these counters can be displayed with the command:
  RTR> sho link/counter=*_lw_*
• 14-1-267 Node /isolate and link /suspect implementation faulty
  The SET NODE qualifier /ISOLATE and SET LINK qualifer /SUSPECT have been superseded by /AUTOISOLATE.
  Any RTR node may disconnect a remote node if it finds that node to be unresponsive or congested. The normal behavior following such action is automatic network link reconnection and recovery.
  When node autoisolation is enabled on a node, it allows the node to disconnect a congested remote node in such a way that when the congested node attempts to reconnect, it receives an instruction to close all its network links and cease connection attempts. When it is in this state, the node is termed isolated.
  Remote node autoisolation may be enabled at the node level where it applies to all links, or for specific links only with the 'set link/autoisolate' command.
  An isolated node will remain in that state until the system manager performs the following actions:
  • enables the link to the isolated node at all nodes that have isolated it

    set link <isolated-node>/enable

  • exit the isolated state at the isolated node

    set node/noisolate

• 14-1-276 Quorum lab exercise in SYS MGR training gives unpredictable results
  In previous versions of RTR, MONITOR QUORUM would sometimes display inconsistent or confusing output when a quorum problem existed. This has now been fixed. MONITOR QUORUM now displays the state (quorate,bad_cfg,uncertain, or not_cncted) as well as the name of the node causing the problem. The erroneous display of "CFG" as the quorum state when a role does not exist on a node has also been corrected.
  In addition, a new RTR command, SHOW QUORUM has been implemented which lists detailed information about the expected quorum view a node should have, and any discrepancies between the actual and expected state.
  
• 14-1-347 Transactions played out-of-order after server death
  After the death of a concurrent server, it could happen that some transactions that were in send state were rescheduled before other transactions on the same partition that were in voted or committed states. This has now been fixed, so that any voted or committed transactions are always rescheduled before any transactions in send state.
• 14-1-375 Server stuck in lcl_rec_fail, quorum and tid problems if DECnet Phase IV only nodes in facility
  Network connections between nodes where one or both of the partners is employing PATHWORKS DECnet as a transport on a Microsoft Windows operating system may occasionally fail to connect with the reason "invalid msglen argument". RTR will automatically retry the connection. No user intervention is required.
• 14-1-416 RTR-V2 CLI interface returns VOTE_TX completion status on DEQ_TX call
  In prior versions of RTR V3 an RTR V2 call made from the RTR command line could incorrectly report the completion status for some other prior call issued with the /NOWAIT qualifier. This has been corrected.
• 14-1-462 MODIFY JOURNAL does nothing if a new disk is specified
  MODIFY JOURNAL no longer reports JOURNALMOD for disks with no journal file. Previously, it reported JOURNALMOD <journal has been modified on device ...> for each specified disk device, even for disks with no journal file, provided that no change actually failed for any other reason.
  This has been corrected. You will now see NOCHANGES <No changes made>, or DSKNOTSET <Specified disk not part of the journal disk set>.
• 14-1-501 DUMP JOURNAL not counting pri_forget records; output misaligned
  Some field test releases of RTR V3.2 would incorrectly display the number of primary-forget records in the journal as zero. This has been corrected. A minor formatting error in the statistics section of DUMP JOURNAL output has also been corrected.
• 14-1-542 V2 router rejecting a V3 FE due to facility name case difference
  When v3 frontends try to connect to v2 routers, the frontends should send the facility name in uppercase. This requirement is needed as v2 routers store the facility name in uppercase, and getting lowercase facility name from frontend, will cause a facility name mismatch at the time of comparison.
• 14-1-640 Too many network addresses can confuse RTR
  RTR processes could behave unpredictably following a reference to a system where the storage required to hold all configured network address information for the system exceeds the space provided by RTR. This has been corrected. A log file entry is written to warn the operator that this situation has been encountered. If encountered, check for and remove any unnecessary protocol and adapter combinations for the system concerned.
• 14-3-82 Requester hangs in SYS$COMMIT_TXW with RTR V3.1D - null txn
  If rtr_start_tx() was called by a client followed immediately by rtr_accept_tx(), then the application would hang (unless rtr_start_tx() was called with a timeout). This has been corrected. The status returned in the rtr_mt_accepted data in such cases is RTR_STS_SYNCHCOMM (transaction committed synchronously).
  This also corrects the equivalent problem with the RTR V2 API. Also, the status returned in the TXSB for such transactions using the V2 API is RTR$_SYNCHCOMM.
• 14-3-93 MONITOR ACTIVE displayed wrong counts for client starts
  The number of started transactions (used for display purposes only) was calculated incorrectly. In particular, transactions explicitly started without a transaction timeout (i.e. using rtr_start_tx() with a zero value for timoutms) were being counted twice. This caused monitor displays, e.g. MONITOR ACTIVE, to display incorrect results. This problem has been corrected.
• 14-3-97 ENQFLAGS, V2 server $enq flag should ignore READONLY
  Any flags supplied with a $ENQ_TX call on a server channel are now ignored rather than cause an error to be returned. This maintains compatibility with prior (V2) versions.
• 14-3-101 RTR$COMMIT_TX(W) returns V3 status
  In previous RTR V3.X releases, the txsb status returned after a successful call to sys$commit_tx() was incorrectly being set to RTR$_COMMIT rather than SS$_NORMAL (as in version 2). This has been corrected.
• 14-3-102 MODIFY JOURNAL not supported
  The earlier restriction that a MODIFY JOURNAL command could not be issued after RTR was started has now been lifted. However, it is now required that RTR be started for a MODIFY JOURNAL command to be executed.
• 14-3-115 Set fac /BROAD=MIN=n not supported
  The command RTR SET FACILITY /BROADCAST=MINIMUM_RATE=n was not supported in Version 3. This problem has been corrected.
• 14-3-118 Transactions on pri_act not being played on sec_act
  If RTR is configured with servers on backends that are running DECnet Phase V, then under certain conditions, local recovery from the remote node's journal would not be performed. For example, local and shadow recovery would appear to work correctly in a shadow server configuration after the primary shadow would go down, but in actual fact any transactions in the remote node's journal would not be recovered. This can only occur if the backends are all using DECnet Phase V as the primary RTR transport, and if the DECnet addresses of the nodes concerned match a particular pattern. Note that this is a static DECnet configuration issue. If recovery works in your particular configuration, then it will always work so long as the DECnet network configuration is not changed.
  This has now been fixed. As a workaround for previous releases of RTR, use TCP/IP transport only, or ensure that at least one of the backends in each shadow pair uses TCP/IP as the primary protocol.
• 14-3-119 No broadcasts received if evtmsk not specified
  In previous versions of RTR 3.X sys$dcl_tx_prc() failed to correctly check that an evtast had been supplied if evtmsk or evtnam were specified. This has now been corrected, and the original V2 behavior of returning RTR$_INVEVTAST in this situation has been restored. In addition the V2 behavior where a null evtmsk would default to rtr$m_broadcast when an evtast is specified has also been restored.
• 14-3-125 Standby server stuck in lcl_rec_fail
  In previous versions of RTR-V3, a standby server which was attempting to take over after failure of the node which contained the previously-active server could become permanently stuck in state lcl_rec_fail. This would happen if two conditions were present: the node which had failed had not been in the same cluster as the node containing the standby, and the failed node had also been quorum-master router for the standby backend. This problem has now been fixed.
• 14-3-134 Certain v2:bm counters are not present as v3:brm counters
  Various counters connected with the delivery of broadcast events have been added: facility counters fdb_cn_bm_transit_brd_lost and fdb_cn_bm_transit_brd_delivered, link counters ndb_cn_bm_transit_lost and ndb_cn_bm_transit_delivered, and process counters bm_brd_lost and bm_brd_delivered.
• 14-3-150 RTR applications hang on trying to continue after ACP restarted
  If the application tried to open a channel again after seeing the status RTR_STS_ACPNOTVIA it could hang on the subsequent rtr_receive_message call. This problem has been corrected for threaded UNIX platforms. It is no longer necessary to restart any RTR application for UNIX after restarting RTR.
• 14-3-157 V2 Response Matching Feature Enabled
  The V2 reply consistency check for replayed messages is enabled. RTR can can enable, disable and display this feature.
  Usage:
  To turn on:

  ---

  Next

  Contents