If your transaction produces no output at all, read Your transaction produces no output at all. For other types of wrong terminal output, read this section.
You get incorrect output to a terminal if data, which is the object of the transaction, becomes corrupted at some stage.
For example, consider a transaction that reads records from a file, processes the information in the records, and displays the results on a terminal. The data might be corrupted at any of points 1 through 5, as it flows from file to terminal.
Each of these possibilities will be dealt with in turn.
You can check the contents of a file or database either by using CECI or by using a utility program to list off the records in question.
If you find bad data in the file or data set, the error is likely to have been caused by the program that last updated the records containing that data. If the records you expected to see are missing, make sure that your application can deal with a ‘record not found’ condition.
If the data in the file is valid, it must have been corrupted later on in the processing.
When a program reads data from a file or a database, the data is put into a field described by a symbolic data declaration in the program.
Is the data contained in the record that is read compatible with the data declaration in the program?
Check each field in the data structure receiving the record, making sure in particular that the type of data in the record is the same as that in the declaration, and that the field receiving the record is the right length.
If the program receives input data from the terminal, make sure that the relevant data declarations are correct for that, too.
If there seems to be no error in the way in which the data is mapped from the file or terminal to the program storage areas, the next thing to check is the program logic.
To find out if data is being corrupted by bad programming logic in the application, consider the flow of data through the transaction.
You can determine the flow of data through your transaction by "desk checking", or by using the interactive tools and tracing techniques supplied by CICS®.
Desk checking your source code is sometimes best done with the help of another programmer who is not familiar with the program. It is often possible for such a person to see weaknesses in the code which you have overlooked.
Interactive tools allow you to look at the ways in which the data values being manipulated by your program change as the transaction proceeds.
User tracing allows you to trace the flow of control and data through your program, and to record data values at specific points in the execution of the transaction. You could, for example, look at the values of counters, flags, and key variables during the execution of your program. You can include up to 4000 bytes of data on any trace entry, and so this can be a powerful technique for finding where data values are being corrupted.
For programming information about how you can invoke user tracing, see CICS Application Programming Reference.
CSFE storage freeze can be used to freeze the storage associated with a terminal or a transaction so that it is not FREEMAINed at the end of processing. This can be a useful tool if, for example, you want to investigate possible storage violations. You need to get a transaction dump to look at the storage after you have run the task with storage freeze on.
For long-running tasks, there is a possibility that a large amount of storage may be consumed because it cannot be FREEMAINed while storage freeze is on. For short-running tasks, however, there should be no significant overhead.
If, after using these techniques, you can find no fault with the logic of the program, the fault either lies with the way data is mapped to the terminal, or you could have missed some important evidence.
Incorrect data mapping to a terminal can have both application-related and system-related causes. If you are using BMS mapping, check the items below.