Release Bulletin OpenSwitch 15.0 for Linux on POWER
Document ID: DC00704-01-1500-01
Last revised: January 3, 2007
Accessing current release bulletin information
A more recent version of this release bulletin may be available on the Web. To check for critical product or document information added after the product release, use the Sybase Product Manuals Web site.Accessing release bulletins at the Sybase Product Manuals Web site
Go to Product Manuals.
Select a product and language and click Go.
Select a product version from the Document Set list.
Select the Release Bulletins link.
From the list of individual documents, select the link to the release bulletin for your platform. You can either download the PDF version or browse the document online.
Sybase OpenSwitch 15.0 is now available on Linux on POWER Red Hat Enterprise Linux AS 3 release operating system.
The functionality in this version is similar to Sybase OpenSwitch version 15.0 ESD#1 on UNIX and Windows platforms. However, OpenSwitch version 15.0 on Linux on POWER platform does not support IPv6 next generation protocol designed by the IETF.
Known limitations of mutually-aware OpenSwitch
This section describes some known limitations with the new mutually-aware OpenSwitch feature.
MAS does not propagate some functions
Mutually-aware OpenSwitch does not propagate the following functions to its companion:
If you issue any of these commands on one of the companions, manually repeat the commands on the other companion. In addition, check that your Coordination Module applications do not contain the equivalent of these commands. If they do, you must find a way to notify the administrator when the commands are called by the Coordination Module, so that the administrator can manually repeat the same commands on the other companion OpenSwitch.
OpenSwitch does not run user scripts when you use CM or RCM
If you are using a Coordination Module or a Replicated Coordination Module, OpenSwitch does not run any user scripts during a client failover, even if you define SVR_FAIL_ACTION as CUSTOM or MANUAL.
Some user errors cannot be prevented
Currently there is no way to prevent certain user errors, for example, if users started two companions in a mutually-aware cluster, one with MUTUAL_AWARE set to 1, and the other set to 0. Such a setup can lead to the two companions not communicating with each other, thereby forsaking the whole purpose of mutually-aware OpenSwitch to maintain constant configuration information across two OpenSwitch servers.
You also see a user error when both mutually-aware companions are started with the -O option, which can lead to the two OpenSwitch companions being unsynchronized in their configurations. This opens up room for data loss during an Adaptive Server failure.
This section describes known problems that exist for this release.
Client connections to secondary OpenSwitch server hang on failover
[CR #435150] Client connections to a secondary OpenSwitch server hang when no available server is found at failover time. This happens in a Mutual Aware Support OpenSwitch setup with the Coordination Module application connected.
Workaround: Log in to secondary (companion) OpenSwitch as an administrator and enter the following commands:
> rp_kill <Pool_Name>, NULL, NULL > go
Coordination Module does not receive notifications on failover
The primary Adaptive Server fails
Primary OpenSwitch handles the failover successfully
Primary OpenSwitch fails
Administrator attempts to bring the primary Adaptive Server back to the UP mode
Workaround: When the primary Adaptive Server is back to the UP mode, perform the following steps manually in the secondary (companion) OpenSwitch server:
1> rp_stop <POOL1>, <Secondary ASE>, NULL, 0, 1 2> go 1> rp_server_status <Primary ASE>, UP 2> go 1> rp_switch <POOL1>, <Secondary ASE>, NULL, <Primary ASE>, 0, 1 2> go 1> rp_start <POOL1>, <Secondary ASE>, NULL 2> go
Improper client behavior due to network glitch with primary Adaptive Server
[CR #434445] When you experience network failure associated with an active Adaptive Server running on a Windows machine in a Mutual Aware Support environment, clients connected to the server may hang. This happens only if the network glitch occurs in the cable connecting the Windows machine running Adaptive Server. Subsequent failure of the same Adaptive Server might not be detected.
Workaround: Log in to OpenSwitch as an administrator and enter the following commands, which terminate all client connections currently established to the Adaptive Server <ASEName_which_experienced_network_glitch>:
> rp_kill NULL, <ASEName_which_experienced_network_glitch>, NULL > go
Transferring data to Adaptive Server with bcp -Q command does not work
Workaround: In case you need to use the bcp -Q functionality, it can be used directly against the Adaptive Server.
Applications using pre TDS 4.6 protocol may not work with OpenSwitch 15.0
[CR #414518] An Open Server™ regression from CR #382803, this issue only affects applications using pre-Tabular Data Stream 4.6 clients. For clients using TDS versions earlier than 4.6, Open Server does not run the packetsize negotiation properly, thus preventing such clients from connecting to OpenSwitch version 15.0.
Workaround: There is no workaround for this problem.
Server not responding causes InstallShield to hang
Performing install checks. Please wait ...
If this happens, the console from which you executed the installation displays a message similar to the following:
NFS3 server not responding still trying
You can verify this problem by executing df -P command from a command prompt. This command should also hang.
Stop the installation process.
Unmount the inaccessible device.
Retry the installation.
OpenSwitch 15.0 is compatible with:
Adaptive Server Enterprise versions 12.0, 12.5, 12.5.x, and 15.0
Replication Coordination Module versions 12.5, 12.5.1, and 15.0
The RCM 15.0 is compatible with:
OpenSwitch version 15.0
Adaptive Server Enterprise versions 12.0, 12.5, 12.5.x, and 15.0
Replication Server® versions 12.0 through 12.6
Documentation updates and clarifications
This section contains information omitted from documentation and new information that needs emphasis.
OpenSwitch Reference Manual
The following discusses updates and clarifications for the OpenSwitch Coordination Module Reference Manual.
Sample cm1.c file
The cm1.c sample has been modified such that, when a primary server is detected to be down, cm1 not only marks it as down, but also removes it from the pool. When the primary server comes back up, cm1 marks it as up and adds it to the end of the pool. This way, new clients can continue to be redirected to the secondary server until the administrator deems it appropriate to switch back all the connections by manually executing the failback sequence as described below:
rp_server_status <sec_ASE>, LOCKED – prevents more new clients from going to the secondary Adaptive Server
rp_stop NULL, <sec_ASE>, NULL – stops all connections on the secondary Adaptive Server
rp_server_status <sec_ASE>, DOWN – makes the secondary Adaptive Server unavailable to any new connections in the future
rp_server_status <pri_ASE>, UP – sets the primary Adaptive Server up for accepting new connections
rp_switch NULL, <sec_ASE>, NULL, <pri_ASE>, 0, 1 – switches all the connections back from the secondary to the primary Adaptive Servers
rp_start NULL, <sec_ASE>, NULL – restarts all the stopped connections
The above change does not apply to mutually-aware setups. If MUTUALLY_AWARE is set to 1, cm1 only marks the primary server as down when it detects a failure, but does not remove the server from the pool. Likewise, when the server comes back up in a mutually aware setup, cm1 marks the server as up, and the primary server begins accepting connections right away. If this behavior is undesirable, the administrator can modify the cm_time_ping() function in cm1.c to comment out the call to cm_server_status. By doing this, the cm1 program does not failback the connections automatically, thus allowing the administrators to control when the failback occurs (when they execute the failback sequence mentioned above).
Callback type, CM_CB_ASEFAIL
Installs or removes a CM event callback handler.
CS_RETCODE cm_callback(cm, cb_type, cb_func) cm_t *cm; CS_INT cb_type; CS_VOID *cb_func;
A pointer to a CM control structure.
cb_type The CM event callback handler being installed.
Called by the client connection to report messages or errors when the connection to an Adaptive Server is lost. This callback is recommended for PING_THREAD that may be running inside the Coordination Module to ping the Adaptive Server. If the callback is not installed, no error or warning messages are reported back to the client if the client loses connection to an Adaptive Server. The callback is only invoked when the severity of the message is greater than or equal to CS_SV_COMM_FAIL.
For more information about how to use this callback, refer to the sample Coordination Module source file at $OPENSWITCH/sample/cm1.c.
OpenSwitch Administration Guide
This following discusses documentation updates and clarifications for the OpenSwitch Administration Guide.
Registered procedure, rp_cm_list
Log in to OpenSwitch as an administrator and enter the following commands to list all the Coordination Modules:
1> rp_cm_list 2> go
OpenSwitch boot option “-V"
The -V option is provided when you start OpenSwitch server, as follows:
./OpenSwitch -c <Absolute path
to the configuration file> -V
This option will turn off validations for all the configuration options specified in the OpenSwitch configuration file.
By default, these validations are turned on. (If -V option is not specified.)
For example, MUTUAL_AWARE configuration parameter or option in the OpenSwitch configuration file is a boolean value (Valid values are 0 or 1). When -V option is not specified at server start time (default), MUTUAL_AWARE option will be validated for the specified value. If the value is neither 0 nor 1, an appropriate error message is displayed and OpenSwitch does not start.
If the -V is specified, then MUTUAL_AWARE option will not be validated for its valid value of either 0 or 1.
Each Sybase installation that has purchased a support contract has one or more designated people who are authorized to contact Sybase Technical Support. If you have any questions about this installation or if you need assistance during the installation process, ask the designated person to contact Sybase Technical Support or the Sybase subsidiary in your area.
Other sources of information
Use the Sybase Getting Started CD, the SyBooks CD, and the Sybase Product Manuals Web site to learn more about your product:
The Getting Started CD contains release bulletins and installation guides in PDF format, and may also contain other documents or updated information not included on the SyBooks CD. It is included with your software. To read or print documents on the Getting Started CD, you need Adobe Acrobat Reader, which you can download at no charge from the Adobe Web site using a link provided on the CD.
The SyBooks CD contains product manuals and is included with your software. The Eclipse-based SyBooks browser allows you to access the manuals in an easy-to-use, HTML-based format.
Some documentation may be provided in PDF format, which you can access through the PDF directory on the SyBooks CD. To read or print the PDF files, you need Adobe Acrobat Reader.
Refer to the SyBooks Installation Guide on the Getting Started CD, or the README.txt file on the SyBooks CD for instructions on installing and starting SyBooks.
The Sybase Product Manuals Web site is an online version of the SyBooks CD that you can access using a standard Web browser. In addition to product manuals, you will find links to EBFs/Maintenance, Technical Documents, Case Management, Solved Cases, newsgroups, and the Sybase Developer Network.
To access the Sybase Product Manuals Web site, go to Product Manuals.
Sybase certifications on the Web
Technical documentation at the Sybase Web site is updated frequently.Finding the latest information on product certifications
Point your Web browser to Technical Documents.
Click Certification Report.
In the Certification Report filter select a product, platform, and timeframe and then click Go.
Click a Certification Report title to display the report.
Point your Web browser to Availability and Certification Reports.
Either select the product family and product under Search by Base Product; or select the platform and product under Search by Platform.
Select Search to display the availability and certification report for the selection.
Set up a MySybase profile. MySybase is a free service that allows you to create a personalized view of Sybase Web pages.
Point your Web browser to Technical Documents.
Click MySybase and create a MySybase profile.
Sybase EBFs and software maintenanceFinding the latest information on EBFs and software maintenance
Point your Web browser to the Sybase Support Page.
Select EBFs/Maintenance. If prompted, enter your MySybase user name and password.
Select a product.
Specify a time frame and click Go. A list of EBF/Maintenance releases is displayed.
Padlock icons indicate that you do not have download authorization for certain EBF/Maintenance releases because you are not registered as a Technical Support Contact. If you have not registered, but have valid information provided by your Sybase representative or through your support contract, click Edit Roles to add the “Technical Support Contact” role to your MySybase profile.
Click the Info icon to display the EBF/Maintenance report, or click the product description to download the software.
This document is available in an HTML version that is specialized for accessibility. You can navigate the HTML with an adaptive technology such as a screen reader, or view it with a screen enlarger.
OpenSwitch version 15.0 and the HTML documentation have been tested for compliance with U.S. government Section 508 Accessibility requirements. Documents that comply with Section 508 generally also meet non-U.S. accessibility guidelines, such as the World Wide Web Consortium (W3C) guidelines for Web sites.
Note:You might need to configure your accessibility tool for optimal use. Some screen readers pronounce text based on its case; for example, they pronounce ALL UPPERCASE TEXT as initials, and MixedCase Text as words. You might find it helpful to configure your tool to announce syntax conventions. Consult the documentation for your tool.