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.