hp_Reliable_Transaction_Router______________________ Release Notes February 2003 HP Reliable Transaction Router (RTR) is fault tolerant transactional messaging middleware used to implement large, distributed applications using client/server technology. These notes describe the new features, corrections, restrictions, and known problems with workarounds for RTR Version 4.2. 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. Java[[TM]] is a US trademark of Sun Microsystems, Inc. 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. This document was prepared using DECdocument, Version 3.3- 1B. _________________________________________________________________ Contents Preface................................................... v 1 Information Applicable to all Platforms....... 1 1.1 New Features.............................. 1 1.1.1 Functionality........................... 1 1.1.2 Environment/Operational Improvements.... 3 1.2 Upgrades.................................. 5 1.3 Restrictions.............................. 6 1.4 Corrections............................... 6 1.5 Known Problems with Workarounds........... 6 2 OpenVMS-Specific Information.................. 7 2.1 Restrictions.............................. 7 2.2 Known Problems with Workarounds........... 7 3 Tru64-Specific Information.................... 7 3.1 Restrictions.............................. 7 3.2 Known Problems with Workarounds........... 7 4 Windows-Specific Information.................. 7 4.1 New Features.............................. 8 4.2 Restrictions.............................. 8 4.3 Known Problems with Workarounds........... 8 5 Sun Solaris-Specific Information.............. 9 5.1 Restrictions.............................. 9 5.2 Known Problems with Workarounds........... 9 Tables 1 RTR Documents............................. v iii _________________________________________________________________ Preface Purpose of these Release Notes This document provides information for Reliable Transaction Router Version 4.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. Related Documentation Table 1 describes RTR documents and groups them by audience. Table_1_RTR_Documents______________________________________ Document______________Content______________________________ For all users: Reliable Transaction Describes new features, changes, and Router Release known restrictions for RTR. Notes[1] Reliable Transaction Provides an overview of RTR Router Getting technology and solutions, and Started includes the glossary that defines all RTR terms. [1]Distributed_on_software_kit.____________________________ (continued on next page) v Table_1_(Cont.)_RTR_Documents______________________________ Document______________Content______________________________ Reliable Transaction A pocket-sized handbook that lists Router Commands all RTR commands, their qualifiers and defaults. Reliable Transaction Describes product features. Router Software Product Description For the system manager: Reliable Transaction Describes how to install RTR on all Router Installation supported platforms. Guide Reliable Transaction Describes how to configure, manage, Router System and monitor RTR. Manager's Manual Reliable Transaction Explains how to migrate from RTR Router Migration Version 2 to RTR Version 3 or 4 Guide[2] (OpenVMS only). For the application programmer: Reliable Transaction Describes how to design application Router Application programs for use with RTR, with both Design Guide C++ and C interfaces. Reliable Transaction Describes the object-oriented Router C++ C++ interface that can be used Foundation Classes to implement RTR object-oriented applications. Reliable Transaction Explains how to design and code RTR Router C Application applications using the C programming Programmer's language and the RTR C API. Contains Reference Manual full descriptions of the basic RTR API calls. [2]Softcopy_only.__________________________________________ ___________________________________________________________ You can find additional information about RTR, including the Software Product Descriptions, on the RTR website found vi through http://www.hp.com links to middleware products or at http:://www.hp.com/go/rtr. Conventions The following conventions are used in this manual: ___________________________________________________________ Convention________Meaning__________________________________ 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._ vii 1 Information Applicable to all Platforms This section describes the new features, changes, and restrictions in Reliable Transaction Router, Version 4.2. 1.1 New Features This section describes the new features available in this release for all platforms. 1.1.1 Functionality o 14-1-2062 Shadow recovery performance improved With fast shadow recovery, a node becomes primary active or secondary active as soon as it has copied all the transactions from the remembering node. Whether it becomes primary or secondary depends on its priority (established with the SET PARTITION/PRIORITY command). However, a large backlog of unprocessed transactions could cause a dual-site outage if a node immediately becomes primary active and then processes the backlog. To avoid such an outage, a change has been implemented in shadow recovery behavior. With this change, a node processing a fast-recovery backlog will stay secondary active until it has caught up with the primary. Only when it has caught up will it change to primary active state. o 14-1-2245, 14-1-2250 Many more commands logged Previously, only a small number of RTR commands were logged. Now, any commands that affect the RTR configuration are logged to give an audit trail. For more information, see the Reliable Transaction Router System Manager's Manual. o 14-1-2330 Linux evaluation kit available. An RTR Linux evaluation kit is available for download from the RTR website http://www.hp.com/go/rtr. o 14-1-2331 Additional documentation formats available on CDROM 1 With the current version of RTR, documents on the CDROM include .pdf files that can be read with Adobe Acrobat and .htm files that can be read with a web browser such as Internet Explorer. o 14-1-2346 Possible transaction hiatus if partition in pri_act or sec_act state is suspended Using the SET PARTITION partition-name/SUSPEND command can cause the following: o If the partition is in the pri_act state, executing the /SUSPEND command also halts transaction presentation at the secondary site. o If the partition is in the sec_act state, the primary site is unaffected. o 14-3-182 Function prototypes added to RTR_V2.H The RTR V2 interface has not changed, but the file has been updated to include function prototypes. o 14-3-372 No need to use partition or facility name with SET TRANSACTION with transaction ID RTR V4 no longer requires the user to specify either the facility or partition name when using the SET TRANSACTION command if the transaction ID is supplied. o 14-3-424, 14-3-425 SHOW FACILITY, SHOW LINK exit status When processing the SHOW FACILITY and SHOW LINK commands, the RTR utility now sets its exit status. o 14-3-439 New variation of the rtr_broadcast_event( ) API function added. The existing API routine, rtr_broadcast_event( ), has been complemented with a new "time out" version of the routine, rtr_ext_broadcast_event( ). This extended version allows the programmer to specify a timeout period in which to perform the operation. If RTR is unable to service the broadcast operation within the timeout period, an RTR_STS_TIMOUT status is returned. Refer to the C Application Programmer's Reference Manual for more details on the new routine. o 14-3-442 P1 parameter added to RTR$STARTUP and RTR$SHUTDOWN for OpenVMS 2 To ensure that rtr_pref_prot is correctly defined, the P1 parameter has been added to RTR$STARTUP and RTR$SHUTDOWN to define the preferred network protocol. For additional information, see the RTR Installation Guide. 1.1.2 Environment/Operational Improvements o 14-1-769, 14-5-281 Changes in Local Time Tolerated Prior versions of RTR would not operate correctly if the system time were changed to an earlier value, for example when processing a change between standard and daylight savings or summer time. This problem has been corrected. o 14-1-1767 Output of rtr_receive_message improved The output for rtr_receive_message now includes the facility and nodename (FE, TR, BE) of the node sending the event notification. o 14-1-1794, 14-1-1911, 14-3-445 Number of channels, number of partitions increased The number of channels per application process has been increased to 1024. The maximum number of partitions is now dynamic; that is, the user needs to supply the maximum number of partitions using the START RTR command with the /PARTITION qualifier. If the /PARTITION qualifier is not used, then the default number of partitions is set to 500. o 14-1-1938 Flow control counters improved Facility broadcast flow control counters have been expanded to allow differentiation by broadcast flow direction and monitoring of flow stall conditions. o 14-1-1973 Appdelay monitor picture enhanced to reveal blocking applications The process monitor picture APPDELAY has been enhanced to show the presence of application processes with channel queue backlogs sufficiently large to prevent the node from granting flow control credits to its connected RTR routers. Once identified, the system manager should take steps to improve the throughput of such processes. 3 o 14-5-244 Pass facility and link names with certain RTR events RTR NCF-based events are now accompanied by a message naming the affected facility and node. The feature can be disabled by defining the variable RTR_NO_NCF_EVENT_ DATA in the environment of all ACP processes in the configuration. The following events are subject to this behaviour: FACREADY, FACDEAD, FERTRLOSS, FERTRGAIN, RTRBEGAIN, RTRBELOSS, BERTRGAIN, BERTRLOSS, RTRFEGAIN, RTRFELOSS. A server channel may subscribe to these events and use this information to maintain a database of who is connected. o 14-5-294 IP address failover RTR networking support for machines with multiple network adapters has been improved to allow multiple IP connection targets for any host. Thus any pair of machines connected by multiple network paths can fail over to an alternate path should the primary path become unusable. For more information, refer to the Reliable Transaction Router System Manager's Manual section on Network Transports, DNS Server Support. o 14-5-319, 14-5-326 Optional compression of event and reply data This release includes the capability of transmitting broadcast event and transaction reply data in a compressed format, addressing the needs of users who wish to reduce their network bandwidth requirements for the transfer of such data. User data passed to RTR with the rtr_reply_to_client() and rtr_broadcast_ event() calls may optionally be compressed before being passed to the RTRACP process for transmission to the RTR router. The data is decompressed to its original state before being presented to the receiving applications. For more information, refer to the Reliable Transaction Router System Manager's Manual section on Compression of Event and Reply Data. o 14-5-335 Advance notification of prepare message arrival To accomodate the changes to RTR to provide advance notification of arrival of a prepare message, the following changes affect RTR documentation: 4 C API: Open channel flags: RTR_F_OPE_NTFY_PREPARE_PEND - requests notification of the presence of a pending prepare message for the transaction branch at the time of the delivery of the first message of the branch. rtr_receive_message(): New return status possible when returning a message on a channel opened with RTR_F_OPE_NTFY_PREPARE_PEND (see above): RTR_STS_OK_PREPARE_PEND - see rtr.msg 1.2 Upgrades o For a rolling upgrade, RTR nodes should be upgraded from Version 3.2 to Version 4.2 in the following order: 1. Upgrade frontend-only nodes at any time 2. Upgrade router-only and mixed frontend/router nodes 3. Upgrade mixed router/backend nodes 4. Upgrade backend-only nodes For more complex configurations, where a node may have combinations of facilities with different backend/router groupings, HP recommends that you set the recovery protocol to use the Version 3.2 algorithm. Once RTR has been upgraded on all nodes, the recovery protocol can be reset to its default value (Version 4.0, 4.1, or 4.2), and RTR restarted at a convenient time on each node. This need not be a simultaneous restart on all nodes. RTR can be restarted on each node one by one after resetting the default recovery protocol, so that continuous application availability is maintained. The following restrictions apply if you upgrade an RTR environment from RTR Version 3.2 to Version 4.0, 4.1, or 4.2: 5 o The RTR recovery protocol consists of messages sent from one backend through a router to the target backend. If either RTR backend is upgraded to RTR Version 4.0, 4.1 or 4.2, then the router that will be used for recovery must also be running the same version of RTR. o This generally means that any RTR router nodes should be upgraded to RTR Version 4.2 before any RTR backend nodes. o There is no restriction to the order in which RTR backends should be upgraded to Version 4.0, 4.1 or 4.2. 1.3 Restrictions The following restrictions apply to all platforms for this version of RTR. o 14-3-452 Nested transactions not supported Implementation of nested transactions has been withdrawn. This functionality is not available to customer applications. 1.4 Corrections None. 1.5 Known Problems with Workarounds The following known problems with workarounds apply to all platforms for this version of RTR. o 14-1-498 Upgrade using RTR V3.1D journal If you are upgrading to RTR Version 4.2 from RTR Version 3.1D, and there are recoverable transactions in the Version 3.1D journal, then you must set the recovery protocol to Version 3.2 mode before adding any facilities on any node that has access to the Version 3.1D journal. This can be done by entering the RTR SET NODE/RECOVERY=V32 command after starting the RTRACP, or by defining the environment variable RTR_CRM_BE_RECOVERY_PROTOCOL (system-wide) to be 32, using the method appropriate for your operating system. 6 2 OpenVMS-Specific Information This section gives platform-specific information for the OpenVMS implementation of Reliable Transaction Router. 2.1 Restrictions None. 2.2 Known Problems with Workarounds The following known problems with workarounds apply to the OpenVMS platform for RTR. o 14-3-409 RTR V2 command line API not covered in RTR V4 help Before uninstalling RTR V2, make a copy of the RTR V2 help file from SYS$COMMON:[SYSHLP]RTRHLP.HLB and then copy it back afterwards. You can then access it with $ help @RTRHLP 3 Tru64-Specific Information This section gives platform-specific information for this version of Reliable Transaction Router for Tru64 UNIX. 3.1 Restrictions o 14-9-79 Support of TruCluster Server 5 The /rtr directory is now a symbolic link to a target directory that is a context-dependent symbolic link (CDSL), so that it is a different physical directory on each cluster member. For more information, refer to the Reliable Transaction Router Installation Guide. 3.2 Known Problems with Workarounds None. 4 Windows-Specific Information This section gives platform-specific information for this version of Reliable Transaction Router for Windows platforms. 7 4.1 New Features o 14-1-2351, 14-1-2386 New toolkit modernizes RTR with Java support. The toolkit can be found on the RTR website at: http://www.hp.com/go/rtr Click on the Java RTR link to access the toolkit. Java RTR (JRTR) is a toolkit that layers on top of RTR. It provides standard Java and J2EE interfaces for RTR applications. JRTR exposes the traditional RTR features of hardware and software high availability, fault tolerance and entire-site disaster recovery by using already well-established interfaces. Specifically it provides JTA (javax.transaction.usertransaction), java.io.InputStream, java.io.OutputStream, and JDBC datasources and connection pools. With JRTR, programmers are more productive because they already know the Java and J2EE concepts. Your investment is protected because you are writing applications that are more portable and better able to integrate with other offerings in the marketplace. 4.2 Restrictions None. 4.3 Known Problems with Workarounds The following known problems with workarounds apply to Windows platforms for RTR. o 14-1-455 Last line of batch file must have The last line of a batch procedure or command file must explicitly end with added by pressing the Enter/Return key when creating the procedure. Without the explicit , RTR ignores the line. The workaround is to add a comment to the end of the file or to explicitly add to the end of the last line of the batch procedure. o 14-1-1628 Microsoft DTC patch update required for RTR XA & SQL running on Windows NT 4.0 8 A bug in Microsoft's Distributed Transaction Coordinator related to the xa_recover() call not returning the full list of in-doubt transactions has been fixed by Microsoft. If you are running Microsoft DTC Version 2.0, check the version number of the msdtc.dll image. If the version number is less than 1999.6.854.0, or if you are not running DTC Version 2.0, verify that NT 4.0 Service Pack 6A is installed, and then upgrade DTC manually. The DTC upgrade, contained in file dtcsetup.exe, and the instructions are available at: ftp://ftp.microsoft.com/bussys/distapps/ MTS/Public-Fixes/usa/DTC/SvcPack/nt4_sp6 ________________________ Note ________________________ This upgrade installs/upgrades to Microsoft DTC Version 2.0, msdtc.dll image version 1999.6.854.0. The upgrade to DTC version 2.0 is the minimum required for RTR to work properly with XA. ______________________________________________________ 5 Sun Solaris-Specific Information This section gives platform-specific information for the implementation of Reliable Transaction Router Version for the Sun Solaris platform. 5.1 Restrictions Reliable Transaction Router Version 4.2 requires Sun Solaris 2.6 or newer; it will not run on Solaris 2.5. 5.2 Known Problems with Workarounds None. 9