Using the symptoms to classify the problem

The paragraphs that follow are to help you to classify the problem on the basis of the symptoms you observe.

The symptoms might enable you to classify the problem correctly at once, but sometimes classification is not so straightforward. You might need to consider the evidence carefully before making your decision. You might need to make a "best guess", and then be prepared to reconsider later on the basis of further evidence.

Look for the section heading that most nearly describes the symptoms you have, and then follow the advice given there.

CICS has stopped running

There are three main reasons why CICS® might unexpectedly stop running:

  1. There could be a CICS system abend.
  2. CICS could be in a wait state. In other words, it could have stalled.
  3. A program could be in a tight loop.

Consider, too, the possibility that CICS might still be running, but only slowly. Be certain that there is no activity at all before carrying out the checks in this section. If CICS is running slowly, you probably have a performance problem. If so, read CICS is running slowly to confirm this before going on to Dealing with performance problems for advice about what to do next.

If CICS has stopped running, look for any message that might explain the situation. The message might appear in either of the following places:

Here are two examples of messages that might accompany CICS system abends, and which you would find on the CSMT log:

DFHST0001 applid An abend (code aaa/bbbb) has occurred at offset X'offset' in module modname.

DFHSR0601 Program interrupt occurred with system task taskid in control

If you get either of these messages, or any others for which the system action is to terminate CICS, turn to Dealing with CICS system abends for advice on what to do next.

If you can find no message saying that CICS has terminated, it is likely that the CICS system is in a wait state, or that some program is in a tight loop and not returning control to CICS. These two possibilities are dealt with in Dealing with waits and Dealing with loops, respectively.

CICS is running slowly

If CICS is running slowly, it is likely that you have a performance problem. It could be because your system is badly tuned, or because it is operating near the limits of its capacity. You will probably notice that the problem is worst at peak system load times, typically at mid-morning and mid-afternoon. If your network extends across more than one time zone, peak system load might seem to you to occur at some other time.

If you find that performance degradation is not dependent on system loading, but happens sometimes when the system is lightly loaded, a poorly designed transaction could be the cause. You might classify the problem initially as "poor performance", but be prepared to reconsider your classification later.

The following are some individual symptoms that could contribute to your perception that CICS is running slowly:

Some of these symptoms do not, in isolation, necessarily mean that you have got a performance problem. They could indicate that some task is in a loop, or is waiting on a resource that is not available. Only you can judge whether what you see should be classified as "poor performance", in the light of all the evidence you have.

You might be able to gather more detailed evidence by using the tools and techniques that CICS provides for collecting performance data. The following is a summary of what is available:

For guidance about using these tools and techniques, and advice about performance and system tuning in general, see the CICS Performance Guide.

You can find guidance about identifying specific performance bottlenecks in your CICS system in Dealing with performance problems.

A task fails to start

If a task fails to start, look first in the CSMT and CSNE logs for any explanatory message. If you do not find one, the task is possibly being prevented from starting because either the system is running at the MXT limit, the transaction is queuing for admittance to a transaction class, or for other performance reasons.

Classify the problem tentatively as "poor performance", and turn to Dealing with performance problems for further guidance.

A task is running slowly

If just one task is running slowly, it is likely that the explanation lies with the task itself. It could be in a loop, or it could periodically be entering a wait state. You need to decide which of these possibilities is the most likely before starting systematic problem determination. The ways that you might distinguish between waits and loops are described in Distinguishing between waits, loops, and poor performance.

Note:
Do not overlook the possibility that the task might simply be doing unnecessary work that does not change the final result--for example, starting a skip sequential browse with large gaps between the keys, or failing to finish one because it is holding on to resources.

A task stops running at a terminal

When a task stops running at a terminal, you will notice either or both of these symptoms:

First, make sure that the task is still in the system. Use CEMT INQ TASK to check its status, and make sure that it has not simply ended without writing back to the terminal.

If the terminal has a display unit, check to see whether a special symbol has been displayed in the operator information area that could explain the fault. If the operator information area is clear, next check to see that no message has been sent to any of the transient data destinations used for error messages, for example:

For details of the destinations used by CICS, see the CICS System Definition Guide. If you can find no explanation for the problem, the fault is probably associated with the task running at the terminal. These are the possibilities:

Read Distinguishing between waits, loops, and poor performance to find out which of these is the most likely explanation. You can then read to the appropriate section for advice about dealing with the problem.

A transaction has abended

If the transaction abended when you ran your application, CICS gives you an error message on your screen as well as a message on the CSMT log.

Use the CMAC transaction or look in CICS Messages and Codes for an explanation of the message, and, perhaps, advice about what you should do to solve the problem. If the code is not there, or the explanation or advice given is not sufficient for you to solve the problem, turn to Dealing with transaction abend codes.

You have obtained some incorrect output

Incorrect output might be regarded as any sort of output that you were not expecting. However, use the term with care in the context of problem determination, because it might be a secondary effect of some other type of error. For example, looping could be occurring if you get any sort of repetitive output, even though that output is not what you had expected. Also, CICS responds to many errors that it detects by sending messages. You might regard the messages as "incorrect output", but they are only symptoms of another type of problem.

If you have received an unexpected message, and its meaning is not at first clear, use the CMAC transaction or look inCICS Messages and Codes for an explanation. It might suggest a simple response that you can make to the message, or it might direct you to other sources of information for further guidance.

These are the types of incorrect output that are dealt with in this manual:

You can find advice about investigating the cause of any of these types of incorrect output in Dealing with incorrect output.

A storage violation has occurred

When CICS detects that storage has been corrupted, this message is sent to the console:

DFHSM0102 applid A storage violation (code X'code') has been detected by module modname.

If you see this message, or you know (through other means) that a storage violation has occurred, turn to Dealing with storage violations for advice about dealing with the problem.

In many cases, storage violations go undetected by CICS, and you only find out that they have occurred when something else goes wrong as a result of the overlay. You could, for example, get a program check because code or data has been overlaid. You might suspect some other type of problem at first, and only after starting your investigation find that a storage violation has occurred.

You can avoid many storage violations by enabling transaction isolation, storage protection, and command protection.

An XRF error has occurred

If an XRF error has occurred, turn to the CICS/ESA 4.1 Problem Determination Guide for advice on what to do.

Related concepts
Tools for obtaining CICS performance data
Information Sources to help analyze performance
Overview of CICS storage protection and transaction isolation
CICS Command Security
What to investigate when analyzing performance
Related tasks
CICS Performance Analysis Techniques
Dealing with performance problems
Dealing with CICS system abends
Dealing with waits
Dealing with loops
Distinguishing between waits, loops, and poor performance
Setting up transient data destination data sets
Dealing with transaction abend codes
Dealing with incorrect output
Dealing with storage violations
Related references
System abend and dump codes
Transaction abend codes
DFH Messages
[[ Contents Previous Page | Next Page Index ]]