Managing a single system image

When you are running and monitoring a single system image, consider the following:

Starting Blueworx Voice Response
You must start Blueworx Voice Response on the database server node of the single system image before you start it on any of the client nodes.
Shutting down Blueworx Voice Response
If you shut down Blueworx Voice Response on the server node while any of the clients are running, some housekeeping functions are affected, so do not shut down Blueworx Voice Response on the server for extended periods of time.
Stopping AIX or DB2
If you restart AIX or DB2 on the server of a single system image while applications are running on any of the clients, those applications might fail and cause call information to be lost.
System clocks
When you implement time synchronization you should ensure a skewing algorithm is used. This is where the clock is slowed, or speeded up a little to accommodate minor adjustments in time. Many NTP daemons do this using the UNIX adjtime() function. The initial ‘set’ of the time should be done without Blueworx Voice Response running. If the clock were to be changed suddenly, system timeouts could occur due to miscalculations in time differences, and some system problems could follow, resulting in errors 5310, 5312, 5313, 5315, 5317 and 2003. These recommendations apply equally to standalone systems and are also of benefit in ensuring system error logs and traces are synchronized to aid in problem analysis or isolation and also system management and monitoring. For explanations of error codes see Blueworx Voice Response for AIX: Problem Determination.
Call statistics
Call statistics are stored in a local database on each client node and on the database server node. When you use the reports on a particular node, you will see data for that node only.
Changes to application objects
When you modify or import an application object (such as a state table) on one node, the change is not apparent on the other nodes of the single system image immediately. The time taken for the change to be available on all nodes is determined by the Runtime Cache Check Interval system parameter.

If you are using the Blueworx Voice Response container windows to display application objects on a node, and another user creates or deletes an object of the same type, but on a different node, the data in your container window will not be refreshed automatically.

Status of custom servers
On a client node in a single system image, the information about the status of custom servers is not refreshed immediately. For example, when a custom server is uninstalled from one node, the other nodes do not know immediately that this has happened. This affects the currency of information displayed in the Custom Server Manager window, on the ASCII console, and in the data returned to a user program through SNMP. The system parameter SSI Custom Server Status Check Interval controls how often this data gets refreshed at the client nodes.
Preventing Custom Servers Starting Automatically on Every Node
You may have defined some custom servers to start automatically every time Blueworx Voice Response starts. However, if you do not want these custom servers to start on every node of your single system image, you can use the DTcs command to add these custom servers to an override list on some nodes. This prevents the custom servers being started automatically on those nodes. For more information, see DTcs command.
State Table Editor
If somebody uses the State Table Editor on one node of a single system image, and saves preferences about the behavior and appearance of the editor, those preferences will not be available if the same person invokes the State Table Editor on a different node.

More information on setting up a single system image

For information on tuning and configuring a single system image for better performance, see
www.ibm.com/software/speech/enterprise/universalaccess_2_101.html.