Read this section if you do not get the dump output you expect.
The things that can go wrong are:
The sections that follow give guidance about resolving each of these problems in turn.
If you have experienced this problem, it is likely that you have dumped the wrong CICS region. It should not occur if you are running a single region.
If you invoked the dump from the MVS™ console using the MVS MODIFY command, check that you specified the correct job name. It must be the job used to bring up the CICS region in which you are interested. If you invoked the dump from the CICS master terminal using CEMT PERFORM SNAP, check that you were using the master terminal for the correct region. This is more likely to be a problem if you have a VTAM® network, because that allows you to switch a single physical VTAM terminal between the different CICS regions.
Read this section if you are experiencing any of these problems:
There are, in general, two reasons why dumps might not be taken:
Depending on the areas that are missing from the dump, the dump formatting program might subsequently be able to format the data that is there, or it might not be able to format the data at all.
If you do not get a dump when an abend occurred, and there was no system error, the dumping that you required must somehow have been suppressed. There are several levels at which dumping can be suppressed:
You need to find out which of these types of dump suppression apply to your system before you decide what remedial action to take.
System dumping can be suppressed globally in two ways:
If system dumping has been suppressed globally by either of these means, any system dumping requirements specified in the transaction dump table and the system dump table are overridden.
You can inquire whether system dumping has been suppressed globally by using the EXEC CICS INQUIRE SYSTEM DUMPING system programming command. If necessary, you can cancel the global suppression of system dumping using EXEC CICS SET SYSTEM DUMPING with a CVDA value of SYSDUMP.
System dumping can be suppressed for specific dump codes by an XDUREQ user exit program. For programming information about the XDUREQ global user exit program, see the CICS Customization Guide.
If an exit program that suppresses system dumping for a particular dump code is enabled, system dumping is not done for that dump code. This overrides any system dumping requirement specified for the dump code in the dump table.
The exit program can suppress system dumps only while it is enabled. If you want the system dumping suppression to be canceled, you can issue an EXEC CICS DISABLE command for the program. Any system dumping requirements specified in the dump table then take effect.
Transaction dumps taken when a transaction abends can be suppressed for individual transactions by using the EXEC CICS SET TRANSACTION DUMPING system programming command, or by using the DUMP attribute on the RDO definition of the transaction. None of the dumping requirements specified in the transaction dump table would be met if a transaction for which dumping is suppressed were to abend.
You can use EXEC CICS INQUIRE TRANSACTION DUMPING to see whether dumping has been suppressed for a transaction, and then use the corresponding SET command to cancel the suppression if necessary.
If transaction dumping and system dumping are not suppressed by any of the preceding mechanisms, the dump table options determine whether or not you get a dump for a particular dump code. For details, see Using dumps in problem determination.
You can inquire on transaction and system dump code attributes using CEMT INQ TRDUMPCODE and CEMT INQ SYDUMPCODE, respectively. You must specify the dump code you are inquiring on.
If you find that the dumping options are not what you want, you can use CEMT SET TRDUMPCODE code or CEMT SET SYDUMPCODE code to change the values of the attributes accordingly.
If the attribute is shown to be TRANDUMP, look next at the maximum number of dumps specified for this dump code, and compare it with the current number. The values are probably equal, showing that the maximum number of dumps have already been taken.
Check also that you have not had all the dumps for this dump code, by comparing the maximum and current dump values.
Finally, check the maximum and current dump values. If they are the same, you need to reset the current value to zero.
CICS keeps a count of the number of times that dumping is invoked during the current run, and the count is included as part of the dump ID given at the start of the dump.
If both a transaction dump and a system dump are taken in response to the event that invoked dumping, the same dump ID is given to both. However, if just a transaction dump or just a system dump is taken, the dump ID is unique to that dump.
The complete range of dump IDs for any run of CICS is, therefore, distributed between the set of system dumps and the set of transaction dumps, but neither set of dumps has them all.
Table 15 gives an example of the sort of distribution of dump IDs that might occur. Note that each dump ID is prefixed by the run number, in this case 23, and that this is the same for any dump produced during that run. This does not apply to SDUMPs produced by the kernel; these always have a dump ID of 0/0000.
On system dump data set | On transaction dump data set |
---|---|
ID=23/0001 | |
ID=23/0002 | ID=23/0002 |
ID=23/0003 | |
ID=23/0004 | |
ID=23/0005 | |
ID=23/0006 | |
ID=23/0007 | |
ID=23/0008 |
For further discussion of the way CICS manages transaction and system dumps, see Using dumps in problem determination.
If you did not get the correct data formatted from a CICS system dump, these are the most likely explanations: