| 2. There is an affinity table for each of the following command groups that cause |
| |
| v INQUIRE, SET, ENABLE, DISABLE, EXTRACT, COLLECT STATS, |
| PERFORM, DISCARD, CREATE, and RESYNC commands |
v CICS BTS BROWSE commands are treated as inquire commands | |
| v WAITCICS, WAIT EVENT, and WAIT EXTERNAL commands |
| 3. There are two affinity tables that are used as aids to searching some of the |
| other tables. |
| The affinity tables reside in the data space and are saved to the Transaction |
| Affinities Utility ®les when you stop the Detector and, optionally, at predetermined |
| intervals. |
| Saving affinity data |
| The affinity data collected by the Detector is saved to the Transaction Affinities |
| Utility VSAM ®les by the autosave transaction, CAFB. For more information about |
| these ®les, see ªThe affinity data VSAM ®lesº on page 17. |
The CAFB transaction saves affinity data automatically when you stop the Detector. You can also specify that the CAFB transaction save affinity data as follows:
vOn a predetermined time/activity basis. That is, data is saved if either more than 300 seconds has passed, or more than 1000 table elements have changed, since the last save.
vWhen you pause the Detector.
Once the CAFB transaction has saved any data collected, it either becomes dormant until next activated (while the Detector is still running or paused), or terminates (if the Detector has been stopped).
Not all the affinity tables in the data space need to be saved, because some are temporary or are used only as an aid to searching. Furthermore, some tables contain temporary elements, used for recording a possible affinity. Such elements are not saved to the ®les. They are either deleted when the Transaction Affinities Utility deduces that there is actually no affinity, or are made permanent when it deduces that there really is affinity (in which case they get saved). Also, when data is saved, only those table elements that have been added or changed since the last save are written to the dataset. Time stamps in each table element indicate whether the element has been written already, and whether it has changed since the last write. This minimizes the number of writes performed.
To improve performance, each affinity table is browsed and saved in its entirety, before the next table is considered.
The affinity table elements are written in such an order that the data on the ®le is always consistent.
Note: If CICS or the Detector abends, the affinity data may be incomplete. Where possible, the Reporter detects this and issues a message to warn about possible incomplete data.
16 CICS Transaction Affinities Utility Guide
