Product: IBM CallPath Enterprise Server Version: 6.3.1 Level: E2106 Platform: Windows Date: 14 September 2001 Service File: ecswnt.exe History: ecswnt.hst Size: 4764390 (4.5Mb) Installation Instructions: -------------------------- Download the self-extracting file, ecswnt.exe, into a temporary directory. Execute it from the command line and follow the prompts. This will start an InstallShield Wizard to guide you through the installation process. Fixes contained in this Service Package: ---------------------------------------- Name: APAR IC31512 Date: 29 Aug 2001 Library: 9834 Symptom: The call ID changes on a call that is routed. Also, call data associated with the call may no longer be available via JTAPI. Problem: This problem is associated with APAR IC31019, in which support for dynamic ACD addresses was added. In this situation the two parties remaining in the call are an external party and a dynamic ACD. Both of these parties have dynamic addresses, so the JTAPI daemon assumes its role in the call is over and removes the call info from its data areas. Once additional events are received from the CP daemon concerning this call, a new call ID is assigned. Solution: Instead of marking an ACD that's discovered during Agent logon processing as dynamic, mark it as permanent. This is a code change to the JTAPI daemon. Name: APAR IC31486 Date: 28 August 2001 Library: 9814 Symptom: Message "ERROR: Sem timeout: tmcptabl.cpp, line 864" repeatedly appears in the cplog/cperr logs. There are no other negative effects other than the error messages. Problem: csebcp incorrectly handles semaphores when deleting a Call ID from its call model. Solution: csebcp changed to correctly handle semaphores when deleting a Call ID from its call model. Name: APAR IC31363 Date: 21 August 2001 Library: 9783 Symptom: When an ACD Status event is sent by csebcp, the message EVT: 1 ACD Info event(s) sent for or EVT: 1 ACD Info event(s) sent for (null) appears in the cplog/cpblog(s); this is incorrect. (Note that the ACD Status event(s) themselves are correct; this is an error only in the cplog/cpblog(s).) Problem: csebcp looks in the wrong place for the line number for the queue the ACD Status event is being sent for. Solution: csebcp changed to correctly print the line number for the queue and correctly refer to it as an ACD Status event, in the cplog/cpblog(s). Name: APAR IC31189 Date: 14 August 2001 Library: 9658 Symptom: If, over a large period of time, there is a lot of call and application activity, csebcp will "overload" due to lack of memory. One sure sign of this problem is the message "TadsDropApps invoked in TADSCP module" appearing in the cplog/cpblog files much more often than customer applications are actually doing TadsDisconnectFromServer. Problem: A recent change to CEO Server may generate additional DropApp requests to csebcp for a period of time after the TadsDisconnectFromServer is issued, especially during periods of heavy call activity. csebcp was not checking for duplication of these requests before putting them on an internal queue for processing. Solution: csebcp changed to not put duplicate DropApp requests on its internal queue and to process TadsDisconnectFromServer requests at the rate of two per second rather than one per second. Name: APAR IC31245 Date: 08 August 2001 Library: 9635 Symptom: On certain routed events where only one party (the calling party) is monitored, the Initiator Flag in the event (field fInitiator) is set to TRUE when it should be FALSE. Problem: Initiator Flag in routed events in the scenario above is incorrect. Solution: csebcp changed to set the Initiator Flag correctly for routed events in this scenario. Name: APAR IC31047 Date: 13 July 2001 Library: 9548 Symptom: After a network outage between a Callpath Enterprise client and a Callpath Enterprise server is corrected, an application may not immediately be able to re-establish all of its event monitors. Events that can only be monitored by a single application in the system may still be incorrectly marked as being held by an application. Problem: Once the system has recovered from a network outage, a Callpath Enterprise Server may not be aware that a client has gone away or that a client has removed event monitors during the network outage. APAR IC29587 partially addressed this problem by removing event monitors and connections once the server or client could not deliver an event due to a broken connection. But, if there's no events to deliver then this cleanup is not triggered. Solution: If a new TCP socket connection is received, but there's already a connection established with the same host machine then send a heartbeat across the existing connection to verify that it's still an active connection. If the connection is no longer valid, clean up all resources associated with it. Since this is a change in data flow between CEO components, for this fix to be activated the environment variable "TADS_CHECK_CON" must be set to "ON" prior to starting csebserv. Name: APAR IC31019 Date: 12 July 2001 Library: 9543 Symptom: If an agent logs on to an ACD that's not configured in csebprof.ini, then once this agent logs off he is not allowed to log back on. Problem: When an agent is associated with an ACD that's not configured in CEO's JTAPI configuration data, then the JTAPI daemon does not recognize the ACD as valid. This results in incomplete cleanup when the agent logs off. The JTAPI daemon after this point will not allow the agent to log back on. Solution: If an ACD unknown to the JTAPI daemon is associated with an agent, then the daemon will create an entry for the dynamic ACD address in its information area. Name: APAR IC30962 Date: 29 Jun 2001 Library: 9510 Symptom: If you're running on a Nortel SL1 switch and you make a call to a busy phone, you cannot disconnect immediately and it takes up to 16 seconds for the switch to issue the disconnect. If running JTAPI or CallPath Phone, the disconnect occurs automatically "under the covers" after the call to the busy phone and the user cannot issue another call request for up to 16 seconds. Problem: csebcp deletes an internal structure that it shouldn't in this scenario. Solution: Modify csebcp to not delete the internal structure and accept disconnect properly in this scenario. Name: APAR IC30780 Date: 27 Jun 2001 Library: 9479 Symptom: If csebcp receives a "disconnected" event for a particular party while csebcp is still processing a TadsRequestExtend from that party to another party, under certain conditions, a core dump in csebcp will occur. Problem: csebcp handles internal data structures incorrectly in this scenario. Solution: Modify csebcp to avoid core dumping and handle internal data structures correctly in this scenario. Name: APAR IC30779 Date: 27 Jun 2001 Library: 9472 Symptom: If csebcp.ini is set up so that the "Servers" field under [INITIALIZATION] is 16 digits (7600@abcdefghijk), csebcp will not connect to CallPath Server, and error message "STLIPD failed! rc = 5" will appear repeatedly in the cplog. (A 16-digit "Servers" field typically happens if the TCP/IP hostname for the CallPath Enterprise Server is 11 digits, for example, abcdefghijk.) Problem: csebcp does not handle the "Servers" field correctly if it is 16 digits. Solution: Modify csebcp to handle this field correctly when it is 16 digits, allowing csebcp to successfully connect to CallPath Server in this scenario. Name: APAR IC30778 Date: 27 Jun 2001 Library: 9469 Symptom: Occasionally, the error message "LList looping error in LListAddItem" can be seen in logs, such as cplog/cperr or ilberr. No other errors occur other than these messages appearing in the log(s). Problem: csebcp believes there is a problem in its internal list handling when no such problem exists. Solution: Modify csebcp to avoid printing this error incorrectly in this scenario. Name: APAR IC30630 Date: 08 Jun 2001 Library: 9449 Symptom: If csebcp receives a "connected" event where the connecting party's connection ID matches any of the connection IDs of the existing parties, and the connecting party's connection ID was not previously seen by csebcp in another event, and there are two or more existing parties, a core dump in csebcp will occur. Problem: csebcp handles internal data structures incorrectly in this scenario. Solution: Modify csebcp to avoid core dumping and handle internal data structures correctly in this scenario. Name: APAR IC28247 Date: 6 June 2001 Library: 9430 Symptom: JTAPI behaves as if an agent is still logged on after he is logged off. However, requests on behalf of this agent fail. Problem: If on an agent logon request an ACD of X is specified, but once the logon is processed the agent is really associated with ACD Y then internal to JTAPI the agent remains associated with both ACDs. At agent log off, clean-up code does not remove the agent's association with ACD X. On a subsequent logon attempt, the agent appears to already be logged on. So, the logon request simply returns without actually logging the agent on. Solution: Once an agent logon completes, the ACD value in the agent object will be updated to the actual associated value. Updates were required to the JTAPI daemon, the JTAPI client, and CPPhone to correct this problem. Files contained in this Service Package: ---------------------------------------- csebclnt.txt csebserv.txt bin\csebclnt.exe bin\csebcp.exe bin\csebdbgw.exe bin\csebmon.exe bin\csebjtpi.exe bin\csebprof.exe bin\csebserv.exe bin\csebxmsg.exe bin\csebsvcw.exe bin\cpesvc.exe bin\cpesvcd.exe conf\cseblims.cfg dll\csacrcrt.dll dll\csebapi.dll dll\csebbase.dll dll\csebdmon.dll dll\csebintf.dll dll\cseblib.dll dll\csebmwin.dll dll\csebnet.dll dll\csebdres.dll dll\csebutil.dll dll\libcmnr.dll dll\libcpn04.dll dll\vacdapi.dll bin\cfgcfg.jar bin\cfgframe.jar cpcfg.txt