Switch to standard view 
  Sybase logo
 
 
 



Release Bulletin

Document ID: DC76342-01-1500-01

Topic

Page

1. Accessing current release bulletin information

2. Product summary

3. Changed functionality

3.1 New features

3.2 Updated functionality

3.3 Known limitations of mutually-aware OpenSwitch

4. Known problems

4.1 Pools are not suspended in a companion server failure scenario in mutually-aware environments

4.2 New clients take time to connect after primary Adaptive Server networks fail in mutually-aware environments

4.3 Companion OpenSwitches are out of sync once network is restored

4.4 Manual script not executed when a new client connection established in mutually-aware environments

4.5 Replication switch occurs more than once during failover

4.6 Applications using pre TDS 4.6 protocol may not work with OpenSwitch 15.0

4.7 OpenSwitch configuration options with NULL values report errors when issuing rp_set

4.8 Starting mutually-aware OpenSwitch cluster with -O command

5. Product compatibilities

6. Documentation updates and clarifications

6.1 OpenSwitch Reference Manual

6.2 README file

7. Technical support

8. Other sources of information

8.1 Sybase certifications on the Web

8.2 Sybase EBFs and software maintenance

9. Accessibility features

1. 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 release of the product CD, use the Sybase® Technical Library Product Manuals Web site.

Accessing release bulletins at the Technical Library Product Manuals Web site

  1. Go to Product Manuals.

  2. Follow the links to the appropriate Sybase product.

  3. Select the Release Bulletins link.

  4. Select the Sybase product version from the Release Bulletins list.

  5. 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.


2. Product summary

Enclosed is Sybase OpenSwitch 15.0, which is compatible with the following platform and operating system configurations:

3. Changed functionality

This section describes new and changed functionality in OpenSwitch 15.0. Each functionality description also contains a reference to more information in the OpenSwitch documentation.

3.1 New features

This section describes new functionality in OpenSwitch version 15.0.

3.1.1 New standalone configuration tool

OpenSwitch 15.0 includes an easy to use configuration tool with a graphical user interface (GUI). You access the configuration tool directly from the OpenSwitch installation program, or by starting the tool as a standalone application after installation. See the OpenSwitch installation guide for your platform, Chapter 2, “Configuring OpenSwitch,” for specific details.

3.1.2 New mutually-aware OpenSwitch server support

OpenSwitch version 15.0 supports a redundant “mutually-aware” environment with two OpenSwitch servers that serve the same pools of two Adaptive Server® Enterprise servers. Each OpenSwitch server is aware of the other OpenSwitch server and whether the connections and Adaptive Servers for which that server is responsible are up or down.

See Chapter 5, “Using Mutually-Aware OpenSwitch Servers,” in the OpenSwitch Administration Guide.

3.1.3 New general registered procedures

Several new general registered procedures have been added to OpenSwitch version 15.0.

See Chapter 6, “Registered Procedures,” in the OpenSwitch Administration Guide.

3.1.4 New coordination module registered procedures

Several new coordination module (CM) registered procedures have been added to OpenSwitch version 15.0. See Chapter 3, “Coordination Module Routines and Registered Procedures,” in the OpenSwitch Coordination Module Reference Guide.

3.1.5 New coordination module API

OpenSwitch 15.0 includes the new coordination module API cm_get_value, which is used to retrieve the mutually-aware configuration value of an OpenSwitch server.

See Chapter 3, “Coordination Module Routines and Registered Procedures,” in the OpenSwitch Coordination Module Reference Guide and Chapter 5, “Using Mutually-Aware OpenSwitch Servers,” in the OpenSwitch Administration Guide for information about mutually-aware support.

3.1.6 Using concurrent coordination modules

OpenSwitch 15.0 allows you to run multiple coordination modules (CMs) concurrently against one OpenSwitch server to create a redundant environment where CM is not a single point of failure.

See Chapter 2, “Using Coordination Modules,” in the OpenSwitch Coordination Module Reference Manual.

3.1.7 Starting and stopping the Replication Coordination Module from OpenSwitch

Version 15.0 allows you to start and stop the Replication Coordination Module (RCM) directly from OpenSwitch, which results in these additions to the product:

See Chapter 3, “Starting and Stopping OpenSwitch and RCMs,” in the OpenSwitch Administration Guide, and Chapter 4, “Using the Replication Coordination Module,” in the OpenSwitch Coordination Module Reference Manual.

3.2 Updated functionality

This section describes the updated functionality for OpenSwitch 15.0.

3.2.1 IP version 6 support

OpenSwitch version 15.0 supports the IPv6 ìnext generationî protocol designed by the IETF to replace the current version Internet Protocol, IP Version 4 (ìIPv4î). IPv6 support is available on:

IPv6 addresses a number of problems with IPv4, such as the limited number of available IPv4 addresses, which are needed by all new machines added to the Internet. IPv6 increases address size from 32 bits to 128 bits. It also adds many improvements to IPv4 in areas, such as routing and network auto-configuration. IPv6 is expected to gradually replace IPv4, with the two coexisting for a for a number of years during the transition period.

3.2.2 Registered procedures

The following registered procedures have changed in OpenSwitch 15.0:

3.2.3 Connect client application deployment update

The OpenSwitch configuration file has a new parameter called USE_DONEINPROCS, which resolves the problem of OpenSwitch not relaying the TDS token DONEPROC and DONEINPROC from Adaptive Server Enterprise to the client.

See “Deployment issues” in Chapter 1, “Overview,” in the OpenSwitch Administration Guide.

3.2.4 Additional rp_debug flag

The following debug flags have been added to rp_debug as part of this release, including:

See Chapter 6, “Registered Procedures,” in the OpenSwitch Administration Guide for more information.

3.2.5 MAX_LOG_MSG_SIZE

The value of the OpenSwitch configuration parameter MAX_LOG_MSG_SIZE has changed to 2048. See Chapter 4, “Using the Configuration File,” in the OpenSwitch Administration Guide.

3.2.6 Connection Monitor on startup

If the Connection Monitor (CMON) configuration option is set to 1, OpenSwitch starts a CMON connection to an Adaptive Server when it receives its first client connection request. The client connection is not made until the CMON connection is successfully started.

3.3 Known limitations of mutually-aware OpenSwitch

This section describes some known limitations with the new mutually-aware OpenSwitch feature.

3.3.1 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.

3.3.2 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.

3.3.3 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.

4. Known problems

This section describes known problems in OpenSwitch version 15.0.

4.1 Pools are not suspended in a companion server failure scenario in mutually-aware environments

[CR #415689] UNIX only – If you set both of the following, OpenSwitch does not execute custom or manual scripts during a network outage between the companions:

Instead, you see an OpenSwitch message such as the following, informing you that it could not suspend the pools and execute the scripts:

posw: INFO: spid 8: manual_action: Executing /usr/u/uagrawal/manual.sh
(server=sosw, reason=1006)
posw: ERROR: spid 8: pool_set_prop_atomic: Failed to preset pool status in 
companion.
posw: ERROR: spid 8: coord_suspend: Cannot change status of pool POOL1 to 
SUSPENDED
posw: ERROR: spid 8: manual_action: Suspending OpenSwitch failed.
posw: ERROR: spid 8: do__useraction: Failed to execute the manual script for
CMP_FAIL_ACTION.  Check the error messages above for reasons of failure.
posw: DEBUG: spid 8: All future changes to the server/pool configuration are 
prohibited.

Workaround: Set CMP_FAIL_ACTION to DEFAULT. If you do not want the configuration to freeze during a network outage between the companions, set FREEZE_CFG_ON_FAIL to 0. Otherwise, set FREEZE_CFG_ON_FAIL to 1.

4.2 New clients take time to connect after primary Adaptive Server networks fail in mutually-aware environments

[CR 415556] When the network between OpenSwitch and the primary Adaptive Server breaks, the first client that tries to connect to the primary Adaptive Server through OpenSwitch can take several minutes to detect the failure, even if the PING_THREAD is set to 1.

After the first client detects the failure, it marks the server as down, and all subsequent clients from that point on failover to the secondary Adaptive Server upon connecting.

Workaround: You must set the client timeout to a value greater than the TCP/IP timeout value (for example, tcp_ip_abort_interval on Solaris) so that the first client can correctly detect the TCP/IP timeout and set the server status appropriately for future clients.

4.3 Companion OpenSwitches are out of sync once network is restored

[CR #414785] Windows only – if you return with an exit status of 1 from NET_FAIL_ACTION CUSTOM or MANUAL scripts, after the network is successfully restored, any changes you make to the pool/server might not get synced with its companion.

Workaround: Always return an exit status of 0 from the CUSTOM or MANUAL scripts for NET_FAIL_ACTION.

4.4 Manual script not executed when a new client connection established in mutually-aware environments

[CR #414784] This problem occurs if you set SVR_FAIL_ACTION in a mutually-aware environment to MANUAL, CUSTOM, or CUSTOM_MANUAL.

If all existing clients on OpenSwitch are idle when a server fails, and a new client attempts to connect after the server has failed but before the existing (idle) clients become busy again, that new client gets connected to the secondary data server, and the existing clients hang.

Workaround: This problem does not occur if you set SVR_FAIL_ACTION to DEFAULT. However if you set SVR_FAIL_ACTION to CUSTOM, MANUAL, or CUSTOM_MANUAL, make sure you have at least one busy client connected to the OpenSwitch at all times. If you cannot ensure this, you can write the following SQL script to create a busy client that runs in the background:

1> while (1=1)
2> waitfor delay "00:30"
3> go

Use a name for this script that is easy to remember, such as busy.sql, and run this script through isql in the background as a regular user to OpenSwitch:

isql -Uusername -Ppassword -SOpenSwitch_name -i busy.sql &

You should run this on both OpenSwitch companions, so that busy.sql can detect a server failure immediately, allowing you to handle the failure appropriately.

4.5 Replication switch occurs more than once during failover

[CR #414693] The Replication Coordination Model attempts to perform the replication switch more than once when a failover situation occurs. The subsequent switch attempts will fail and have no impact on client applications.

Workaround: There is no workaround, as this does not impact the RCM or Openswitch.

4.6 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.

4.7 OpenSwitch configuration options with NULL values report errors when issuing rp_set

[CR 414398] You see an error message that starts with, “Unable to get value of option...” when you issue an rp_set command with its <option> configured with a NULL value in the OpenSwitch configuration file:

rp_set  <option>

Workaround: Modify the configuration options to have a valid non-NULL value in your OpenSwitch configuration file.

4.8 Starting mutually-aware OpenSwitch cluster with -O command

[CR 399350] If both companions in a mutually-aware OpenSwitch cluster are started with the -O command, they both run as the Primary Companion, and the companion that started first runs in a single-server mode.

Workaround: Do not use the -O command to start an OpenSwitch in a mutually-aware cluster that already has another OpenSwitch running.

5. Product compatibilities

OpenSwitch 15.0 is compatible with:

The RCM 15.0 is compatible with:

6. Documentation updates and clarifications

This section discusses documentation updates and clarifications.

6.1 OpenSwitch Reference Manual

The following discusses updates and clarifications for the OpenSwitch Coordination Module Reference Manual.

6.1.1 Sample cml.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:

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

6.2 README file

The README file (README.nt in Windows) refers Open Client/Open Server version 12.5.

Replace all references to OCS-12_5 to $SYBASE_OCS (%SYBASE_OCS% in Windows), and set the value of $SYBASE_OCS (%SYBASE_OCS% in Windows) to OCS-15_0.

7. Technical support

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.

8. 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:

8.1 Sybase certifications on the Web

Technical documentation at the Sybase Web site is updated frequently.

Finding the latest information on product certifications

  1. Point your Web browser to Technical Documents.

  2. Select Products from the navigation bar on the left.

  3. Select a product name from the product list and click Go.

  4. Select the Certification Report filter, specify a time frame, and click Go.

  5. Click a Certification Report title to display the report.


Finding the latest information on component certifications

  1. Point your Web browser to Availability and Certification Reports.

  2. Either select the product family and product under Search by Product; or select the platform and product under Search by Platform.

  3. Select Search to display the availability and certification report for the selection.


Creating a personalized view of the Sybase Web site (including support pages)

Set up a MySybase profile. MySybase is a free service that allows you to create a personalized view of Sybase Web pages.

  1. Point your Web browser to Technical Documents.

  2. Click MySybase and create a MySybase profile.


8.2 Sybase EBFs and software maintenance

Finding the latest information on EBFs and software maintenance

  1. Point your Web browser to the Sybase Support Page.

  2. Select EBFs/Maintenance. If prompted, enter your MySybase user name and password.

  3. Select a product.

  4. 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.

  5. Click the Info icon to display the EBF/Maintenance report, or click the product description to download the software.


9. Accessibility features

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.




Back to Top
© Copyright 2010, Sybase Inc.