Problem Determination

Chapter 3. Problem Determination Procedures

CallCoordinator interacts with several other components. (Refer to CallPath CallCoordinator/CICS General Information for details). A problem in one part of the system can cause unexpected problems to occur in other parts of the system. This chapter addresses only those problems connected with CallCoordinator.

If your system experiences a symptom that is not discussed here, refer the problem to your system programmer. Your system programmer can refer to other problem determination guides for more information.

If your system has been working satisfactorily before a problem occurs, find out if changes have been made to any part of the system. A change to one component can cause unexpected problems to occur in another part.

In problem determination, follow the general steps listed below. This procedure first uses local resources, then indicates the appropriate support group.

1. Analyze the symptoms to localize the problem (to a terminal, a telephone, the switch, the PS/2, or the host computer). In a multiregion operation (MRO) environment, try to localize the problem to a specific CICS region, or to difficulties in communication between regions. If the problem appears on the host, try to isolate to VTAM.

   Also try to localize the problem to CallPath/CICS for OS/390 (EQZ) or to CallCoordinator (EZP or CAM).

2. Follow routine reporting and repair procedures at your facility.

3. When routine procedures are not adequate, report the problem to the correct support group. Use the following resources for help:

   • For PC or host computer hardware problems, contact the hardware vendor.

   • For non-CallCoordinator software problems in the PC or host computer, contact the software vendor.

   • For non-CallCoordinator problems in the switch, contact the switch vendor.

   • For problems with CallCoordinator software call the IBM Software Support Center at 1-800-237-5511. Report the problem against component ID 5655-B34. You must have an IBM customer number to use this service.

During the operation of a computer system, problems may be caused by three kinds of errors:

• A mistake by a human operating or configuring the system
• A coding error in the computer software
• A failure in the hardware system.

The observed symptom of a problem is either an error message, or some unexpected behavior of the system. A complex system such as CallCoordinator involves several cooperating software subsystems. If one of the software subsystems encounters an unexpected condition in its interaction with another subsystem, it cannot determine the kind of error that caused the unexpected behavior. The system administrator can use the following strategy for the problem determination:

1. Start with the subsystem where the problem is observed.

2. Use its problem determination procedures to determine if the source of the problem is within that subsystem.

3. If the source of the problem is not within that subsystem, find which subsystem gave the unexpected results to that subsystem and use the problem determination procedures for the other subsystem to pursue the error.

If the CallCoordinator software detects an unexpected condition, it generates an error message. Different error messages imply the different kinds of error and subsystems. Since CallCoordinator does not directly support any hardware, a hardware failure results in a problem originating from another subsystem. CallCoordinator writes messages to three destinations:

• A terminal (used by either an agent or support personnel)

  Messages displayed on terminals usually report a human error in data entered at the terminal, but sometimes report other kinds of information, like a system down condition.

• The MIS Log

  Messages written to the MIS Log file generally result from unexpected conditions detected when processing messages received from CallCoordinator, but also record normal call events.

• The CICS System Log

  Messages written to the CICS system log are either informational messages that record normal operations, such as the starting or stopping of the CallCoordinator feature, or messages that require action by the CICS system programmer to handle such problems as missing program modules or unavailable storage.

Chapter 6, "CallCoordinator Messages" contains all of the CallCoordinator messages in alphanumeric sequence, with an explanation of each message, the action the system takes, and the action the user should take. The chapter is divided into two sections; messages generated with the prefix CAM, and messages generated with the prefix EZP.

Symptom table

The following table provides symptoms of and corrections for unexpected behavior in CallCoordinator.

Table 2. Symptoms and Corrections for CallCoordinator Problems

Problem	Correction
Switch is down	Do the following: See the CallPath/CICS for OS/390 system administrator or the switch administrator.
CallCoordinator status is FAILED Status is set to FAILED if the system fails to start.	Do the following: Check the system log for messages and Chapter 6, "CallCoordinator Messages" for message content. Also see Appendix A, "Reference Lists of CallCoordinator Software Elements" for identifying program names.
CallCoordinator status is PURGED Status is set to PURGED if the system starts OK, but a LRT abended during operation.	Do the following: Check the system log for messages and Chapter 6, "CallCoordinator Messages" for message content. Also see Appendix A, "Reference Lists of CallCoordinator Software Elements" for identifying program names. Verify that CallPath/CICS for OS/390 has been initialized properly for CallCoordinator startup. CallCoordinator transaction V220 will ABEND with   a CICS Abend code of AEY9 if CallPath/CICS for OS/390 has not initialized the task-related user exits (TRUE). This symptom will be seen when the CICS region is brought up with the PLTPI=NO option in the CICS startup JCL, or if the PLTPI does not start CallPath/CICS for OS/390 prior to starting CallCoordinator. Corrective action requires running transaction EQTI, then restarting CallCoordinator. Refer to the CallPath/CICS for OS/390 books for more information on enabling TRUE. Recovery may be automatic or manual. See "Shutdown and Recovery".
Agent sign-on to CallCoordinator (VA90) fails	Do the following: Verify that CallCoordinator is installed and operational. Verify that the switch is active via VA20 (option 2 from V800). Verify that the Agent Signon API program (VA90) is enabled by using CEMT INQUIRE PROG(VA90). If it is disabled, CICS will issue an AZI6 abend on the agent's terminal. Verify that the Agents table is not full. You might need to increase its size and recycle CallCoordinator. Check Agent Sign on/Sign Off panel and Agent Detail panel for CallCoordinator: Verify that Agent ID is entered correctly. Verify that the Record status field contains Y, indicating that the agent is fully defined and activated for CallCoordinator.
Agent receives no initial transaction panel	Do the following: Verify that the switch is available. Verify that the Agent mode field contains Y and not I or P. Verify that the initial CICS transaction has been defined to CICS and has been enabled. Verify that the correct CICS transaction ID has been entered in the Init trans ID field on the COR Telephony Settings panel. See "Terminal identification for MRO".
Request for transaction fails; receive message not available	Do the following: Verify that the correct CICS transaction ID was entered on the CICS panel. Verify that the CICS transaction has been defined to CICS and has been enabled.
Request for a Transfer Load Balancing number fails	Do the following: Verify that the correct Switch ID is entered in the Switches and Extensions panels. Contact your switch administrator to ensure that the switches are configured correctly for pilot numbers for the ACD groups and for the backup telephone numbers. Verify that the information entered on the Load Balancing panels is correct. Refer to the Planning part of the CallPath CallCoordinator/CICS System Management Guide for more information on Load Balancing. Verify that agent has an active call. Verify that the link to the switch is operable.
Call transfer fails	Verify that the switch supports Host Initiated Transfer.

Terminal identification for MRO

For Multiregion operation (MRO) a terminal definition is required by CallCoordinator that includes the terminal's characteristics and the region it belongs to. To set this up, use the Agent Sign On panel (VA90), or use the Sign On API (CAMI710C) from your own application program, in the remote region. These use START to start a transaction in the CallCoordinator region (the V795 transaction) causing the Terminal Control Table Terminal Entry (TCTTE) to be shipped to the CallCoordinator region. In subsequent INQUIRE commands, CallCoordinator requires the SYSID of the TOR in order to start a transaction via Screen Presentation Manager®. Terminal definitions for CallCoordinator agents must be defined as "shippable".

CICS Deletion of TCTTE

In CICS V4.1 there are two parameters: DSHIPIDL and DSHIPINT, which represent the Idle time and Interval, respectively, that CICS V4.1 will use to determine if and when to delete TCTTE information. If an agent has been inactive for the period of time specified in the DSHIPIDL parameter, their TCTTE information may be removed from the CallCoordinator region. Subsequent INQUIRE requests will then fail. If the agent signs off from CallCoordinator and then signs back on again, the TCTTE information will be recreated.

DSHIPIDL and DSHIPINT should be set very high, or set to zero for no deletion, within the CallCoordinator region. These parameters reside in the System Initialization Table (SIT) and can be checked or set using CEMT I DEL. Overtype one or both of the INT and IDL parameters and press ENTER to change.