Before you go further into looking for the cause of the problem, run through the following preliminary checks. These checks might highlight a simple cause or, at least, narrow the range of possible causes.
As you go through the questions, make a note of anything that might be relevant to the problem. Even if the observations you record do not at first suggest a cause, they could be useful to you later if you need to carry out systematic problem determination.
If the CICS system has not run successfully before, it is possible that you have not yet set it up correctly. You can check that CICS installed correctly by running batch or online verification procedures. See CICS Transaction Server for z/OS® Installation Guide for more information. If you have verified that CICS installed successfully, check the appropriate migration guide for any possible impacts to your system. The migration guides available are.....
If you are currently migrating to CICS Transaction Server for z/OS, Version 3 Release 1, ensure that you are aware of all the changes that have been made for this release. For details of these, see the CICS Transaction Server for z/OS Migration from CICS TS Version 2.3.
Are there any messages explaining the failure?
If a transaction abends, and the task terminates abnormally, CICS sends a message reporting the fact to the CSMT log (or your site replacement). If you find a message there, it might immediately suggest a reason for the failure.
Were there any unusual messages associated with CICS start up, or while the system was running before the error occurred? These might indicate some system problem that prevented your transaction from running successfully.
If you see any messages that you do not understand, you can use the CICS messages transaction, CMAC, for online message information. If you do not have access to a CICS system to run the CMAC transaction, look in CICS Messages and Codes for an explanation. A suggested course of action that you can take to resolve the problem might also be included with the explanation.
The exit programming interface enables you to invoke a domain and enter its environment directly; using it incorrectly can cause severe CICS system problems. Here are some particular points for your attention:
If the failure occurs at specific times of day, it could be dependent on system loading. Typically, peak system loading is at mid-morning and mid-afternoon, so those are the times when load-dependent failures are most likely to happen. If your CICS network extends across more than one time zone, peak system loading might seem to you to occur at some other time of day.
If an error is intermittent, particularly if it does not show the same symptoms, the problem might be more difficult to resolve. An intermittent failure can be caused by a "random" storage overlay. Furthermore, the transaction that caused the error might have been deleted from the system long before the symptoms are seen.
A method you can use to investigate random overlays is described in Dealing with storage violations.
Administration
If the definitions were made but not installed when CICS was last terminated, they might not have been preserved over the termination and subsequent start up. In general, changes made to the CSD but not installed are not visible when the CICS system is warm started. However, if the change was in a group in the GRPLIST specified on a cold start, it is effectively installed during startup. (Changes which have been installed are not visible after a cold start unless they were made to a group in the GRPLIST.)
If START=AUTO was specified in the system initialization table, or as an override, you need to examine the job log to find out how the CICS system last came up.
For detailed guidance about the ways in which resources can be defined and installed, see the CICS Resource Definition Guide.
Are specific parts of the network affected by the problem?
Has the application run successfully before?
Examine the new or modified part of the application.
CEMT SET PROGRAM(mapset) NEWCOPY
CEMT SET PROGRAM(all programs) NEWCOPY
(See CICS Supplied Transactions for guidance about the CEMT transaction.)
Establish what the program was doing when the error occurred, and check the source code in that part of the program.
If a program has been run successfully on many previous occasions, examine the contents of any records, screen data, and files that were being processed when the error occurred. They may contain some unusual data value that causes a rarely used path in the program to be invoked.
If you can reproduce the problem in a test system, you can use programming language debug tools and the CEDF transaction to check the data and solve the problem.
The application has not run successfully before
If your application has not yet run successfully, examine it carefully to see if you can find any errors.
If your application fails to translate, compile or assemble, or link-edit cleanly into the correct phase library, it will also fail to run if you attempt to invoke it.