Transaction inputs and outputs can be divided into the following areas:
Terminal data is very important in solving problems, because it can help you answer the following questions:
The more you know about the information that was input at the terminal on which the transaction failed, the better your chance of duplicating the problem in a test environment. However, this information may not be precise, especially if there are many fields on the input screen. You are recommended to provide a quick and easy way for terminal operators to report problems, so that they can report the error while they can still see the data on the screen (or at least remember more clearly what it was).
The output from a transaction is sometimes easier to capture. If you have a locally attached printer, you can make a copy. (The problem may be that the printer output is incorrect.)
The items to look for on the input side are:
On the output screen, check the following points:
If the program explicitly uses any transient data or temporary storage queues, inspect them to see if their content is what you expect. You can use the CICS®-supplied transaction, CEBR, to inspect temporary storage queues in some detail. See CICS Supplied Transactions for information about this transaction.
Even if the program does not use queues, look at the system queues for CEMT (or your site replacement) and CSTL (and CDBC if you use DBCTL) to see if there are any relevant messages.
The things you might want to look for in the queues are:
Be particularly careful when you are using the common work area (CWA) because you only have one area for the entire system. A transaction may depend on a certain sequence of transactions and some other program may change that sequence. If you are using the CWA, you must also know if your CICS is split into multiple MRO regions because there is an independent CWA for each MRO region.
Terminal user areas can have problems because the area is associated with a terminal and not a particular transaction.
If you are using tables in the CWA, remember that there is no recovery; if a transaction updates the table and then abends, the transaction is backed out but the change is not.
Files and databases are often the main source of transaction input and output; you should always investigate both these areas whenever a program is having problems.
To do this, you need to use the appropriate utilities and diagnostic tools for the data access methods that you have at your installation.
Check the various indexes in files and databases. If you have more than one method of accessing information, one path may be working well but another path may be causing problems.
When looking through the data in files, pay particular attention to the record layout. The program may be using an out-of-date record description.