Product: Corepoint Telephony Client Version: 6.2.0 Level: E2065 Platform: OS/2 Date: 24 July 2001 Service File: eclos2.exe Size: 3544985 (3.4Mb) Installation Instructions: -------------------------- Download the self-extracting file, eclos2.exe, into a temporary directory. Execute it from the command line and follow the prompts. If you answered "Yes" to the backup query and wish to undo the service update, issue the following commands: : cd \ -Qdr where is the drive letter on which product is installed and is the full path name of the backup self-extracting file. Fixes contained in this Service Package: ---------------------------------------- Name: APAR IC30786 Date: 26 June 2001 Library: 9500 Symptom: After a network outage between a Callpath Enterprise client and server, an application that reopens a connection and registers for events may not receive events for which it is registered. Problem: The clean up processing associated with a broken Callpath Enterprise client to server connection may take over a minute to complete (mainly due to slow response from TCP/IP requests). If new event monitors are registered during the clean up period, they may inadvertently get cancelled by the clean up processing. Solution: Changed the logic in the Callpath Enterprise client to only clean up resources associated with connections that are active at the time of the network outage. Name: APAR IC30160 Date: 20 April 2001 Library: 9359 Symptom: csebclnt may trap/core dump if an associated CEO server is stopped and started several times. This problem may also occur if TCP/IP communcations with a CEO server is broken and re-established several times over a 10 to 20 minute period. Problem: If the heartbeat option is configured and a TCP/IP connection to a CEO server is expired by the heartbeat logic, then an exception may occur in removing the broken connection. The exception occurs when the broken connection is already being removed by another thread. Solution: Once a connection is marked internally as "close-pending" the heartbeat logic will no longer reference the connection. Name: APAR IC29587 Date: 19 February 2001 Library: 9188 Symptom: Over an extended period of time the number of abandoned event monitors increase resulting in a continued degradation in system performance. Another symptom is that if an application monitoring routed-trigger events exits without releasing the monitor, then this monitor continues to be active and since only one application can monitor routed-trigger events, no other monitor for this event is allowed. Problem: If an application that holds event monitors dies or attempts to close the connection (and discards the connection handle) while the CPE client could not communicate with the CPE server, then the event monitors held by this application are not cleaned up. Solution: If the CPE client or server receives an event that is no longer deliverable, then the connection associated with this event will be closed and the associated event monitors are stopped. Also, if a CPE client is unable to open its IPC queue on startup, it will log an error message and exit. Name: APAR IY12501 Date: 17 August 2000 Library: 8882 Symptom: A CallPath Enterprise client has multiple TCP connections to its server. Problem: If the case of the server host name in the client INI file is different than the case of the server host name used by the application on the TadsConnectToServer API call, then two or more TCP socket connections are established between the Callpath Enterprise client and the associated server. Solution: Ensure only one connection is established between a Callpath Enterprise client and any associated Callpath Enterprise server. ************************************************************** ***************** --> Service changes applied to prior release (2.02) ----------------------------------------------- Name: PMR 47625 Library: Defect 8325 Symptom: Applications are slow in receiving events or may not be receiving any events. Problem occurs only in an AIX environment. Problem: When an application is monitoring but is not receiving from its event queue the event queue gets full and the Corepoint Telephony client's event thread hangs in sending the next event to this application. Workaround: If an application is monitoring, ensure that the application is reading from its event queue in a timely manner. Solution: To limit the effect of an unresponsive application a code change was made to time out (after 6 seconds) the delivery of an event. This allows all applications, other than the unresponsive one, to continue receiving events. Name: PMR 70892 Library: Defect 7651 Symptom: In a multithreaded application, a Tads* call that immediately follows a TadsConnectToServer call may return TADS_HANDLE_DISCONNECTED. Problem: The problem occurs when one thread has issued a TadsDisconnectFromServer while another thread, at the same time, issues a TadsConnectToServer and gets the same connection handle. Then when the second thread does a subsequent Tads call, it occasionally returns right away with a return code of TADS_HANDLE_DISCONNECTED. Workaround: None Solution: Processing within TadsDisconnectFromServer was prematurely marking its connection handle as available. In rare cases, this resulted in data associated with the new connection being overwritten. The disconnect logic was changed to kept its connection handle until all processing has completed. Name: PMR 74506 Library: Defect 7042 Symptom: CEO applications in AIX that were set up to handle a SIGTERM signal were not seeing the SIGTERM signal until the second time the signal was sent. Problem: The build process that created the AIX API library (libcseb.a) was bringing in some incorrect libraries in the step where the shared library is created. This altered the SIGTERM behavior. Workaround: None Solution: libcseb.a now built with correct libraries. Name: PMR 09162 Library: Defect 6960 Symptom: The TCP connection between the Corepoint Telephony Server and an associated daemon breaks for no apparent reason. Shortly thereafter the server traps in AZAOM30.DLL. Problem: The daemon receives a 0 length message from its server connection. In response the daemon assumes the connection has gone away and closes the connection. Once the server discovers that the connection to the daemon is broken he attempts to cleanup and ends up overwriting memory. Workaround: None Solution: Changed code to not treat a "no data" condition on a TCP socket receive call as an error. Corrected the memory overwite problem. Name: PMR 42104 Library: Defect 7020 Symptom: In NT, occasionally the Corepoint Telephony Client traps after restarting an associated Corepoint Telephony Server. This problem can also occur in the server if associated daemons are stopped and started multiple times. Problem: The extents of an array holding connection information is exceeded. This results in memory being corrupted and the trap. Workaround: None Solution: Changed code to not use the socket handle as an index into the connection information array. Instead, hashing is used to locate array entries. Name: PMR 09206 Library: Defect 6912 Symptom: An occasional performance problem on Corepoint Telephony Server when a client goes away. Problem: Corepoint Telephony Clients are sending (in error) TADS_SYSTEM_EVENTS to the server. The server is fooled into treating these clients as daemons, and when one of these clients goes away, the server sends a TADS_SYSTEM_EVENT to all clients monitoring for system events. This causes a big performance problem when hundreds of clients are attached. Workaround: None Solution: Modified the server code to not be fooled into treating regular clients as daemons. Modified the client code to not send TADS_SYSTEM_EVENTS to the server. Name: PMR 32718 Library: Defect 6748 Symptom: Enterprise Client, Server, or a Daemon could abend during some shutdown scenarios. Usually this would occur during a user-invoked shutdown. Occsasionally, it would happen during an attempt at orderly shutdown due to a terminating error. Problem: Scenario: 1. Attempting to shutdown a client, server, or daemon that was started with the nodisplay option in certain AIX environments by using the SIGTERM signal. 2. Timing problem between shutdown of NetLayer and shutdown of DispatcherLayer. 3. Attempts to shutdown a daemon using the daemon stop() method. Workaround: None Solution: Several timing and cleanup problems in shutdown logic were removed. Name: Defect 3181 Symptom: Intermittent RC = 509 on API requests. Problem: Unexpected partial messages were occasionally received on the IPC queues between the application and Corepoint Telephony and were not being handled correctly. Workaround: None Solution: The code was modified to correctly handle this condition. Name: Defect 3819 Symptom: When configuring the Telephony Interface Daemon, ACDPulse parameter can not be accessed. Problem: The CSEBREM.CFG file needs to have this entry added for this component. Workaround: It could be accessed by selecting the Telephony Intelligent Load Balancing component. Solution: The CSEBREM.CFG file was updated for this component. Name: Defect 4128 Symptom: An application exception occurs in the CPE (Corepoint Telephony) API library when the application invokes TadsQueryCallData() with a NULL callID value. Problem: API library does not check for a NULL pointer when performing a query by callID. Workaround: Do not invoke TadsQueryCallData() with NULL callID. Solution: Check for a NULL pointer. Files contained in this Service Package: ---------------------------------------- dll\csebbase.dll dll\cseblib.dll dll\csebnet.dll dll\csebmwin.dll dll\csebapi.dll dll\csebdmon.dll dll\csebdres.dll dll\csacrcrt.dll dll\libcpo04.dll bin\csebdbgw.exe bin\csebclnt.exe csebclnt.txt bin\cfgcfg.jar bin\cfgframe.jar bin\readme.txt