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.
There are three main reasons why CICS® might unexpectedly stop running:
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:
If you do not find any explanatory message on the MVS console, check in the CSMT log to see if anything has been written there.
If you see only a transaction abend message in the CSMT log, that will not account for CICS itself not running, and you should not classify the problem as an abend. A faulty transaction could hold CICS up, perhaps indefinitely, but CICS would resume work again if the transaction abended.
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.
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.
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.
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.
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.
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.
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.
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.
If an XRF error has occurred, turn to the CICS/ESA 4.1 Problem Determination Guide for advice on what to do.