System Management Guide

Chapter 7. Identifying Problems

If a problem occurs in your CallPath Services system, this section helps you:

• Isolate the part of the system where the problem lies
• Identify the cause of the problem
• Take appropriate action to correct the problem.

Finding the Source of a Problem

A telephony system that includes CallPath/CICS   consists of:

• User application programs
• CallPath/CICS
• CICS
• An IBM OS/390 operating system running on a host computer
• ACF/VTAM
• A network
• CallPath SwitchServer/2
• One or more switches
• Telephones.

A problem in one part of the system can cause unexpected problems to occur in other parts of the system. This section suggests an approach you can use to discover which part of your system is at fault.

Coding and design errors in application programs are the most likely cause of problems experienced by the agents and application programmers using the CallPath Services system. Unfortunately, the effect on your system of such a problem is difficult to predict. If your system experiences a problem not described in this section, an application program is probably at fault. Refer the problem to your application programmer who can find appropriate problem determination information in the CallPath/CICS for OS/390 Application Programming Guide.

What to Look For

This section tells you what to look for when a problem occurs.

Changes to your System

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

If your system has only recently been installed, make sure you have completed all the tasks described in Chapter 3, "Installing CallPath/CICS". Consider checking the installation by running the transaction EQIV, as described in "Task 10: Verifying the Installation".

System Symptoms

The section "Symptoms" contains a table listing the symptoms that might   alert users of your CallPath/CICS system that a problem has occurred. Look in the table for the symptom that your system displays. Then go to the listed topic to discover where the problem lies and identify its cause. After you discover the cause, you can take the recommended action to correct the problem. If you have more than one of the symptoms listed, go to each relevant section in turn.

Some symptoms can be caused by a number of different problems. A chart guides you through a series of questions that help you to isolate the particular problem that is affecting your system. The questions are arranged so that you can make the simplest checks first. You are given information to help you to answer the questions.

Often, many of the possible causes of a problem can be identified or eliminated by the system administrator using the online panels of the administration subsystem. When more detailed investigation is needed, the chart suggests that the system administrator refer the problem to the appropriate specialist: a systems programmer who understands the installation of CallPath/CICS, an ACF/VTAM specialist, a telephone or switch maintenance specialist, the CallPath SwitchServer/2 administrator, or an application programmer.

Problem Determination Aids

Message Log

CallPath/CICS logs all the error and information messages it generates. Many messages point to internal errors in CallPath/CICS and misuse of CallPath/CICS by an application program. Other messages indicate problems with the CICS environment in which CallPath/CICS is running.

You can use the online administration panels to display or print all the messages on the current log. Each message begins with a number you can use to look up the message in Appendix A, "System Messages". The message is explained and you are advised what to do when you see that it has been logged by your system. For example, if the message is caused by an internal error in the CallPath/CICS program code, you are advised to contact your service representative. If the message is caused by insufficient storage, you might be advised to increase the CallPath/CICS storage limit.

Message data written to transient data queues can be accessed by using either a user-written CICS application or OS/390 facilities.

Transient Data Queue CSSL

If CallPath/CICS is unable to write to its own message log when required, it writes error messages to the transient data queue CSSL.

The CallPath/CICS for OS/390 Application Programming Guide contains a list of abend codes CICS can write to the queue and suggests possible reasons for the system failure in each case.

Diagnostic Trace

When you contact your service representative, you might be asked to switch on diagnostic tracing for certain internal CallPath/CICS program modules. The internal program modules for which diagnostic tracing is available are listed in Table 17.

Symptoms

Table 16. Symptoms

Symptom	Where to Look for Help
The CallPath Services system is slow.	"CallPath Services System is Slow".
One or more telephones do not respond to your application program.	"Telephones No Longer Respond".
You cannot start the administration subsystem using the Subsystem Startup/Shutdown panel.	"Administration Subsystem Cannot Be Started".
The administration subsystem starts (its status becomes active) but then fails.	"Administration Subsystem Starts Running and Then Fails".
You cannot start communications with a switch.	"Communications with CallPath SwitchServer/2 Cannot Be Established".
Communications with the switch are active but then fail.	"Communications with CallPath SwitchServer/2 were Established but Failed".
An application program fails to run in a remote region, although it runs successfully in the primary region.	"Program Calls to the API are Successful Only in the Primary Region".
The archive files that should contain system messages, trace information, and message traffic statistics are empty.	"Archive Files are Empty".
You cannot print system messages successfully using the System Messages panel.	"Cannot Print System Messages".
You cannot sign on to the administration subsystem.	"Problems with Security".

CallPath Services System is Slow

Symptom Explanation	Conditions That Could Cause This Symptom
The system is working but is slow	The CallPath/CICS transactions and programs do not have high enough priority. Your application program does not have high enough priority. Too many tasks are running concurrently in the primary CallPath/CICS region. Network problems exist.

1.  Refer the problem to your systems programmer.

   Is CallPath/CICS connected to more than one CallPath SwitchServer/2?
   

   Yes	Go to step 11
   No	Go to step 2

2.   The CallPath/CICS system might be generally overloaded. An indicator of this is if the system is slow only at certain times of the day. Ask your CallPath SwitchServer/2 administrator to follow the problem determination procedures in Using CallPath SwitchServer/2 to see if throughput is above the CallPath SwitchServer/2 design limit.

   Is throughput above the design limit of CallPath SwitchServer/2?
   

   Yes	Go to step 10
   No	Go to step 3

3.   Is the MROBTCH parameter in the SIT of the primary and any remote CallPath/CICS regions set to 1?
   

   Yes	Go to step 5
   No	Go to step 4

4.   Set the MROBTCH parameter to 1 in the SIT of each CallPath/CICS CICS region. If the parameter is not set to 1, there might be delays when application programs use CallPath/CICS from a remote CICS region.

   If the problem persists, go to step 5

5.   Do CallPath/CICS transactions and programs have higher priority than other programs and transactions (including application programs that use CallPath/CICS)?
   

   Yes	Go to step 7
   No	Go to step 6

6.   CallPath/CICS programs and transactions should have a very high priority. Reduce the priority of all other programs and transactions in the same region. If this is not possible, increase the priority of the CallPath/CICS programs and transactions, making sure you maintain the relative priority differences between them.

7.   Is the primary CallPath/CICS region moderately or heavily loaded?
   

   Yes	Go to step 9
   No	Go to step 8

8.   The priority of your application program might be too low compared to other tasks that do not use CallPath/CICS

   Either increase the priority of your application program, or move some non-CallPath/CICS tasks to another CICS region.

9.   Slow response can be caused by problems in the network. Problems can occur in the following parts of the network:

   • The link between CallPath/CICS and CallPath SwitchServer/2.

     To check this link, follow the procedure described in "Communications with CallPath SwitchServer/2 Cannot Be Established"

   • The links between CICS and each terminal.

10.   You have isolated the problem. Follow the procedures in Using CallPath SwitchServer/2.

11.   Is the problem associated with only one CallPath SwitchServer/2?
    

    Yes	Go to step 13
    No	Go to step 12

12.   The problem is not associated with one particular CallPath SwitchServer/2.

    - Go to step 2.

13.   The problem is either in CallPath SwitchServer/2, the switch, or the link between them. Ask your CallPath SwitchServer/2 administrator to refer to the problem determination information in Using CallPath SwitchServer/2

Telephones No Longer Respond

1.  If only one agent has reported a problem, contact other agents to see if the problem is isolated to one telephone.

   Is only one telephone affected?
   

   Yes	Go to step 7
   No	Go to step 2

2.   Although the problem telephones do not respond to your application program, you might still be able to operate them manually.

   If it is not possible to test your telephones manually, skip this step and go to step 4

   Answer these questions:

   • Is there a dial tone?

   • Can you make calls from the telephone?

   • Can you receive calls at the telephone?

   If you answer no to any of these questions, the telephones are not working.

   Are the telephones working?
   

   Yes	Go to step 4
   No	Go to step 3

3.   There is probably a fault in the switch. Contact your switch maintenance service.

4.   Do all the problem telephones use the same switch and the same application?
   

   Yes	Go to step 6
   No	Go to step 5

5.   The following possibilities exist:

   • The problem telephones all use the same switch but are controlled by different application programs. In this case there might be a problem either with the switch or with the CallPath/CICS administration subsystem. If other application programs are using CallPath/CICS successfully, the problem can be isolated to the switch. Contact your switch maintenance service.

   • The problem telephones are all controlled by the same application program, but use different switches. In this case, a problem with the application program is likely. Contact your application programmer.

6.   It is either an application problem, switch problem, or CallPath/CICS problem. You do not have enough information to distinguish between problems in the switch or your application program. To discover whether the problem is in CallPath/CICS, go to step 8

7.   The problem might be caused by a fault in the telephone line or the telephone itself.

   Contact your telephone maintenance service.

8.   Make sure the administration subsystem is running:

   1. Sign on to the CallPath/CICS administration subsystem using the transaction EQAC.

   2. On the System Administration Menu, select System Status Information. Look at the status of the administration subsystem.

      If the status is active, the administration subsystem is running.

   Is the CallPath/CICS administration subsystem running?
   

   Yes	Go to step 10
   No	Go to step 9

9.   The administration subsystem must be running before communications can be started with a switch.

   1. Start the CallPath/CICS administration subsystem.

      If you cannot start the administration subsystem, go to "Administration Subsystem Cannot Be Started".

   2. When the status of the administration subsystem is active, use the Switch Communications Startup/Shutdown panel to start communications with the switch. (See "Starting and Stopping Switch Communications" for more information).

      If you are unable to start communications with the switch, go to "Communications with CallPath SwitchServer/2 Cannot Be Established".

10.   Look at the status of the switch on the System Status Information panel. If communications are started, the switch status is active.

    Note: The status of the request handler and the status of the event handler must also be active, otherwise the switch status might not be current.

    Are communications started with the switch?
    

    Yes	Go to step 14
    No	Go to step 13

11.   Use the Switch Communications Startup/Shutdown panel to start communications with the switch. (See "Starting and Stopping Switch Communications" for more information.)

    If you cannot start switch communications, follow the procedure described in "Communications with CallPath SwitchServer/2 Cannot Be Established"

12.   Is the switch in the correct mode (that is, not simulation mode)?
    

    Yes	Go to step 14
    No	Go to step 13

13.   Switches in simulation mode cannot manipulate telephones.

    Use the Switch Communications Startup/Shutdown panel to:

    1. Stop the simulation.

    2. Start the switch in normal mode.

       See "Starting and Stopping Switch Communications" for detailed instructions.

14.   Refer the problem to your systems programmer.

    Each call in the API is a CICS task-related user exit (TRUE). Each TRUE must be enabled before a program call can be successful.

    Is the CallPath/CICS API enabled in each CICS region?
    

    Yes	Go to step 20
    No	Go to step 15

15.   If EQZ5TINT is included in the startup PLT, the CallPath/CICS API is automatically enabled when CICS starts.

    Were you expecting the API to be automatically enabled when CICS starts?
    

    Yes	Go to step 17
    No	Go to step 16

16.   Use the CICS transaction EQTI to enable the API.

17.   Look at the output produced by the CICS JCL.

    Does the output show that the startup list was run?
    

    Yes	Go to step 19
    No	Go to step 18

18.   You might have isolated the problem.

    Make sure the SIT PLTPI is pointing to a correct startup list.

19.   You might have isolated the problem.

    Make sure EQZ5TINT is included in the startup program list.

    Look in the CallPath/CICS system messages log.

20.   Run the installation verification program.

    (For information about using the installation verification program, see "Task 10: Verifying the Installation".)

    Does the IVP run without producing any error messages ?
    

    Yes	Go to step 19
    No	Go to step 21

21.   CallPath/CICS is not installed correctly. Correct any problems indicated by the messages. Refer to Chapter 3, "Installing CallPath/CICS" for information about how to install CallPath/CICS.

22.   There might be a problem in your application program.

    Refer the problem to your application programmer.

Administration Subsystem Cannot Be Started

1.   To see the status of the administration subsystem:

   1. Sign on to the CallPath/CICS administration subsystem using the transaction EQAC.

   2. On the System Administration Menu, select System Status Information. Look at the status of the administration subsystem.

   Is the status of the administration subsystem active?
   

   Yes	Go to step 4
   No	Go to step 2

2.   Is the status start requested or starting?
   

   Yes	Go to step 3
   No	Go to step 5

3.   The administration subsystem is starting. When the startup process is complete, the status changes to active.

   If the status does not change to active:

   1. Press the Refresh key to make sure you see the current status.

   2. Check the CallPath/CICS system messages log to see if any errors have been logged. For more information about how to perform this task, see "Displaying Messages" and "Printing Messages".

      Look up any system messages in Appendix A and follow the recommended actions.

   3. Stop the administration subsystem using the Subsystem Startup/Shutdown panel.

      The administration subsystem status changes to inactive.

      If you cannot stop the administration subsystem, ask your systems programmer to purge transaction EQSS (the administration subsystem) using the transaction CEMT.

      The subsystem status changes to abnormal end.

   4. Start the administration subsystem using the Subsystem Startup/Shutdown panel.

   If problems persist, go to step 10.

4.   The administration subsystem appears to be running. If you think it is not running, ask your systems programmer to do the following:

   Use the CICS command CEMT I TA to see if transaction EQSS (the administration subsystem) is running.

   If this transaction is not running, the administration subsystem has abnormally terminated without starting its abend module. To correct the problem:

   1. Check the CallPath/CICS system messages log for any errors and take the recommended action.

   2. At this point, you might need to load a new copy of EQZTSCT using the NEWCOPY option of CEMT SET PROGRAM.

   3. Restart the administration subsystem using the Subsystem Startup/Shutdown panel.

   If problems persist, go to step 10.

5.   Is the status of the subsystem either end requested or ending?
   

   Yes	Go to step 9
   No	Go to step 6

6.   Is the status abnormal end?
   

   Yes	Go to step 8
   No	Go to step 7

7.   Ask your systems programmer to:.

   1. Use the CICS command CEMT I TA to see the status of transaction EQSS (the administration subsystem). If transaction EQSS is running, the administration subsystem is running.

   2. Purge the transaction. The administration subsystem is stopped.

   3. Start the administration subsystem.

8.   The administration subsystem came to an abnormal stop.

   1. Check the system messages log for any errors and take the recommended action.

   2. Restart the administration subsystem.

   If problems persist, go to 10.

9.   The administration subsystem is shutting down. The status changes to inactive when shutdown is complete.

   If the status does not change to inactive:

   1. Press the Refresh key to make sure you see the current status.

   2. Ask your systems programmer to purge transaction EQSS (the administration subsystem).
   When shutdown is complete, start the administration subsystem using the Subsystem Startup/Shutdown panel.

   If problems persist, go to 10.

10.   Refer the problem to your systems programmer.

    Make sure the CICS JCL is correct. The EQZRDR DD statement must have an LRECL/BLKSIZE of 80.

    Does the CICS JCL contain the required EQZRDR DD statement?
    

    Yes	Go to step 12
    No	Go to step 11

11.   Add the required statement to the JCL.

    See task 7, in Chapter 3, Installing CallPath/CICS, for more information about the CICS JCL.

    If the problem persists, go to step 12.

12.   The primary CallPath/CICS region is defined in the load module EQZTSCT that you create when you install CallPath/CICS.

    1. Find out if EQZTSCT has been recently altered. The primary CallPath/CICS region might no longer be correctly defined.

    2. Find out if the APPLID in the SIT of the primary region has been recently altered.

    See task 6.

    Is the administration subsystem installed correctly in the primary CallPath/CICS region?
    

    Yes	Go to step 14
    No	Go to step 13

13.   Correct your installation. For installation information, see Chapter 3, "Installing CallPath/CICS".

14.   Use the CICS command CEMT I PR(EQZ3SUBS) to check that the administration subsystem is enabled on CICS.

    Is the administration subsystem program EQZ3SUBS enabled on CICS?
    

    Yes	Go to step 16
    No	Go to step 15

15.   Enable the program.

16.   Make sure all the files needed by the administration subsystem are open and enabled.

    To see a list of files and their statuses, use the CICS command CEMT I FILE(EQZ_*) .

Administration Subsystem Starts Running and Then Fails

If the administration subsystem ran successfully before failing:

1. Look at the CallPath/CICS system messages log. If there are error messages, correct the problems they indicate.

2. Check if there is a problem swapping from active to alternative log files.

   The JCL utility to archive the contents of the active log file to the alternative log file might not have a high enough priority for the job to run before the next archive request. Increase the priority of the job on its job card.

   If your system is very active, you might need to increase the size of the log files to prevent the build up of a queue of files to be archived. See "Creating Data Sets that Contain the CallPath/CICS JCL" for information about how to define the size of log files.

Communications with CallPath SwitchServer/2 Cannot Be Established

1.   First check the CallPath/CICS system messages log for any errors and take the recommended action.

   Sign on to the CallPath/CICS administration subsystem. Display the System Status Information panel.

   Is the name of the switch you selected displayed on the panel?
   

   Yes	Go to step 5
   No	Go to step 2

2.   Is the status of the administration subsystem active?
   

   Yes	Go to step 4
   No	Go to step 3

3.   Do the following to start the administration subsystem and switch communications:

   • Use the Subsystem Startup/Shutdown panel to start the administration subsystem

   • Use the Switch Communications Startup/Shutdown panel to start switch communications.

4.   Switch communications are not active. Follow the instructions in "Starting and Stopping Switch Communications" to start communications with the switch.

5.   Is the status of the event handler, the request handler, and the switch active?
   

   Yes	Go to step 6
   No	Go to step 7

6.   CallPath/CICS is communicating with CallPath SwitchServer/2.

7.   Is the status of either the request handler or the event handler start requested or starting?
   

   Yes	Go to step 10
   No	Go to step 8

8.   Is the status of the request handler ending or end requested?
   

   Yes	Go to step 9
   No	Go to step 11

9.   Communications are shutting down.

   When the shutdown is complete, the name of the switch is no longer displayed on the panel. You can then start communications with the switch. (See "Starting and Stopping Switch Communications" for detailed instructions.)

10.   Communications are being started.

    After a brief time, the statuses of all three components change to active. If they do not change, a problem still exists. Go to step 13.

11.   Is the status of the request handler or event handler link down?
    

    Yes	Go to step 13
    No	Go to step 12

12.   Ask your systems programmer to:

    1. Stop the CallPath/CICS administration subsystem.

    2. Use the CICS command CEMT I TA to see which transactions are running. If transactions EQEH, EQRH, or EQSS are running, purge them.

    3. Start the administration subsystem.

    4. Start communications with the appropriate switch.

13.   The communication link ended abnormally.

    1. CallPath/CICS will attempt to restart communications automatically. (See "Automatic communications restart".)

       If the attempt is unsuccessful, CallPath/CICS will wait for a period, then try again. The wait period is 30 seconds for the first ten attempts, and 1 minute thereafter. CallPath/CICS will keep trying to restart communications for 20 minutes. After 20 minutes, it is unlikely automatic restart will succeed without external intervention, and CallPath/CICS no longer tries to restart communications. If a switch that is down is stopped or manually restarted using the EQAC menu, the restart process is abandoned.

    2. Check the CallPath/CICS system messages log for any error messages and take the recommended action.

    3. Restart switch communications using the Switch Communications Startup/Shutdown panel.

    Check VTAM. Use the CICS command CEMT I VTAM.

    Is VTAM OPEN on CICS?
    

    Yes	Go to step 15
    No	Go to step 14

14.   Open VTAM.

15.   Check the network connections. Use the CICS command CEMT I CONN.

    Are all the connections in service and acquired?
    

    Yes	Go to step 17
    No	Go to step 16

16.   Place the connections in service and acquire them.

17.   Check the CICS connections, sessions, and profiles.

    Look at the Transmit connection name and the Receive connection name on the Switch Description Configuration Details panel for the switch. For more detailed information about how to do this, see "Viewing Switch Description Configuration Information".

    Are the connection names valid?
    

    Yes	Go to step 19
    No	Go to step 18

18.   Enter valid connection names on the Switch Description Configuration Details panel. Or change the connection names using RDO.

19.   Simulate the CallPath/CICS message handlers. Use the CICS command CECI AL SY(connection_name) PROFILE(profile_name) NOQ.

    Use the connection name and profile name you see on the Switch Description Configuration Details panel.

    Is the response NORMAL?
    

    Yes	Go to step 25
    No	Go to step 20

20.   The options defined in your CICS system might be incompatible with APPC. Check your CICS SIT options against those supplied as SYSIN input to the CICS JCL. (See "Task 2: Customizing CICS Macro Table Entries" for more information.)

    Is the response SYSBUSY?
    

    Yes	Go to step 24
    No	Go to step 21

21.   Is the response TERMERR?
    

    Yes	Go to step 23
    No	Go to step 22

22.   The response is SYSIDERR. CallPath/CICS cannot communicate with either CICS or the network. Go to step 25.

23.   CallPath/CICS network connections are functioning correctly. There might be a problem with CallPath SwitchServer/2.

    Go to step 28.

24.   CallPath/CICS cannot obtain a session to communicate with the CallPath SwitchServer/2.

25.   Check the profile defined for the switch.

    Use the CICS command CECI AL SY(connection_name) NOQ.

    Is the profile correct?
    

    Yes	Go to step 27
    No	Go to step 26

26.   Do the following to check the profile:

    • Make sure the correct profile name is entered on the Switch Description Configuration Details panel.

    • Make sure the CICS profile definition is correct. An example profile definition is provided in "LUTYPE6.2 Link Requirements".

    • Ask your VTAM systems programmer to check that the mode name in the profile is valid for VTAM, and that the mode is not for parallel sessions.

    When you find an error, correct the profile.

    If the problem persists, go to step 28.

27.   There might be a problem with CallPath SwitchServer/2. Go to step 28.

28.   Ask the CallPath SwitchServer/2 administrator to check that CallPath SwitchServer/2 is running.

Communications with CallPath SwitchServer/2 were Established but Failed

1.   Look at the CallPath/CICS System Messages log.

   Are there any relevant messages in the CallPath/CICS System Messages log?
   

   Yes	Go to step 5
   No	Go to step 2

2.   Ask the CallPath SwitchServer/2 administrator to check the CallPath SwitchServer/2 system messages log.

   Are there any relevant messages in the CallPath SwitchServer/2 log?
   

   Yes	Go to step 4
   No	Go to step 3

3.   Restart the administration subsystem and switch communications:

   1. Use the Subsystem Startup/Shutdown panel to shut down and restart the CallPath/CICS administration subsystem.

   2. Use the Switch Communications Startup/Shutdown panel to start communications with the appropriate switch.

   If the problem persists, go to step 6.

4.   Correct any problems that the messages indicate.

   If the problem persists, go to step 3.

5.   Correct any problems that the messages indicate.

   If the problem persists, go to step 2.

6.   Ask the CallPath SwitchServer/2 administrator to shut down and restart CallPath SwitchServer/2. Attempt to restart the switches from CallPath/CICS

   If the problem persists, go to step 7.

7.   Are the timeout parameters on profile definitions correct?
   

   Yes	Go to step 9
   No	Go to step 8

8.   Correct the parameters. See "Profile Definition".

9.   Refer the problem to your CallPath SwitchServer/2 administrator. There might be a problem with CommServer/2.

Program Calls to the API are Successful Only in the Primary Region

1.   Refer the problem to your systems programmer.

   Is the program running in the primary region identical to the program that fails in the remote region?
   

   Yes	Go to step 3
   No	Go to step 2

2.   You might have isolated the problem.

   Refer the problem to your application programmer.

3.   Use the CICS command CEMT I IRC to check that inter-region communication (IRC) is open in all regions.

   Is IRC open in the primary region and remote regions?
   

   Yes	Go to step 5
   No	Go to step 4

4.   You might have isolated the problem.

   Open IRC. If the problem persists, go to step 5.

5.   Use the CICS command CEMT I CONN to check the MRO links between the primary and the remote region.

   Are the MRO links active and in service?
   

   Yes	Go to step 7
   No	Go to step 6

6.   You might have isolated the problem.

   Activate and then acquire the links. If the problem persists, go to step 7.

7.   The region should be defined in the SCT. See "Task 6: Creating the System Configuration Table (SCT)" for more information.

   Is the remote region defined correctly in the SCT?
   

   Yes	Go to step 9
   No	Go to step 8

8.   You might have isolated the problem.

   Define the remote region correctly, following the procedure described in "Task 6: Creating the System Configuration Table (SCT)"

   If the problem persists, go to step 9.

9.   Is the APPLID parameter in the SIT for the MRO region correct?
   

   Yes	Go to step 11
   No	Go to step 10

10.   You might have isolated the problem.

    Correct the APPLID parameter.

    If the problem persists, go to step 11.

11.   Are the CICS TRUEs enabled in the MRO region?
    

    Yes	Go to step 13
    No	Go to step 12

12.   You might have isolated the problem.

    Use transaction EQTI to enable the TRUEs.

    If the problem persists, go to step 13.

13.   Are sufficient MRO sessions defined?
    

    Yes	Go to step 15
    No	Go to step 14

14.   Define more sessions

    If the problem persists, go to step 15.

15.   Is the maximum task parameter (MXT) in the SIT high enough?
    

    Yes	Go to step 17
    No	Go to step 16

16.   Increase the MXT parameter, and check if the AMXT parameter needs a proportional increase.

    If the problem persists, go to step 17.

17.   Do the following test:

    1. Shut down CallPath/CICS in the primary region.

    2. In the remote region, write to the remote queue EQSQ using the CICS command CECI WRITEQ TD QUEUE(EQSQ) FROM(TEST.WRITE).

    3. Look at queue EQSQ in the primary CallPath/CICS region. If the test message is not there, refer the problem to your systems programmer. If you see the test message:
       1. Make sure the program EQZ5BEND is enabled in the primary region.
       2. Make sure transaction EQZ1 is enabled in the primary region.

Problems with Security

CallPath/CICS programs and transactions are supplied with minimal CICS security and no external security. If you have changed the supplied CICS security levels, or if you run CallPath/CICS under your own external security system, you might develop problems with authorization.

All CallPath/CICS programs must have authority to load the module EQZTSCT. Some CallPath/CICS programs load other modules. To see a list of modules, use the CICS command:

CEMT I PR(EQZT_*)

Archive Files are Empty

The creation of archive files is an optional facility. Refer to "Installing the Facility to Create Archive Files" to make sure the facility is installed correctly.

If the facility is installed and archive files are empty, the JCL batch utility is not running successfully. Check the output from the appropriate batch job. Make sure the job accounting information is correct.

Cannot Print System Messages

The facility to print system messages is optional. Refer to "Installing the Facility to Print the System Messages Log" to make sure the facility is installed correctly.

If the facility is installed and you are unable to print system messages, the JCL batch utility is not running successfully. Check the output from the appropriate batch job. Make sure the job accounting information is correct.

Abends and Dumps

For information on the abend codes you might receive in a CallPath/CICS environment, refer to the CallPath/CICS for OS/390 Application Programming Guide.

Problem Determination Aids to Use With Your Service Representative

This section describes problem determination aids you can use when you work with your service representative to solve problems.

Identifying Problems in Message Decoding

If the event handler is unable to decode a message from CallPath SwitchServer/2 the complete switch message is written to the VSAM file EQZSPI. Whenever this occurs, you are informed by a message in the CallPath/CICS message log. Your service representative can use the information in EQZSPI to identify the cause of the decoding error.

Using Diagnostic Tracing

When a problem occurs, your service representative might ask you to switch on diagnostic tracing for one of the internal program modules listed in Table 17.   For information about how to switch on and off diagnostic tracing, see "Switching Diagnostic Tracing On and Off".

Table 17. Modules for which Diagnostic Trace Records are Generated

EQZ1ADDP	Add_Party
EQZ1ALTR	Alternate_Call
EQZ1ANSR	Answer_Call
EQZ1CONF	Conference_Call
EQZ1DEL	Delete_Call_Profile
EQZ1DISC	Disconnect_Call
EQZ1HOLD	Hold_Call
EQZ1IDEN	Identify_Program_Name
EQZ1IMMT	Immediate_Transfer
EQZ1INIT	Initialize_Call_Profile
EQZ1INVK	Invoke_Feature
EQZ1MAKE	Make_Call
EQZ1MON	Monitor
EQZ1MONS	Monitor_System_Status
EQZ1QPS	Query_Party_Status
EQZ1RCV	Receive
EQZ1RED	Redirect_Call
EQZ1REG	Register_Ownership
EQZ1REJ	Reject_Call
EQZ1REL	Release_Program_Name
EQZ1RETR	Retrieve_Call
EQZ1RTNC	Return_Control
EQZ1SAA	Set_Automatic_Answer
EQZ1SAPD	Set_Add_Party_Direction
EQZ1SBP	Set_Billed_Party
EQZ1SCDA	Set_Called_Party_Alerting_Time
EQZ1SCT	Set_Call_Type
EQZ1SDEO	Set_Disconnect_Execution_Option
EQZ1SEDD	Send_Device_Data
EQZ1SEP	Set_Extend_Purpose
EQZ1SHCC	Set_Held_Call_Connection
EQZ1SHCR	Set_Held_Call_Recording
EQZ1SHPB	Set_Holding_Party_Callback
EQZ1SHPC	Set_Holding_Party_Calling
EQZ1SMCD	Set_Make_Call DND Override
EQZ1SMCF	Set_Make_Call_Forward_Override
EQZ1SMCN	Set_Make_Call_Notification
EQZ1SMCP	Set_Make_Call_Party_Order
EQZ1SMT	Set_Monitor_Tracking
EQZ1SPS	Set_Party_Specification
EQZ1SRPO	Set_Remaining_Parties_Option
EQZ1SRR	Set_Return_Response
EQZ1TRAN	Transfer_Call
EQZ1TRGR	Trigger
EQZ1XTND	Extend_Call
EQZ2REQH	Request Handler
EQZ2EVTH	Event Handler
EQZ3SUBS	Subsystem
EQZ4SIME	Simulator Control Module
EQZ5BEND	Distributed Transaction Processing (DTP) Back End Processor
EQZ5QCLN	Queue Clean program