Frequently, you want to maintain some form of consistency or synchronization between rows on a table, between rows on different tables, or between data and various system actions. The main question for the application designer is when each action needs to be performed to maintain the synchronization. For tablesONLINE/CICS, this often becomes which exit opportunity to use for an operation.
Any item-level or field-level exit program can, of course, look at any tables which the application does not change and may write to tables designed for a group of related exits, as described for previous examples under ‘Interfacing’.
Consider the item-level exits in the employee table discussed in the previous example. The IXF exit can, as suggested above, read information from a salary range table. Other item-level exits might create rows in a message table when an employee row was added, or deleted, or when certain fields, such as salary, were updated. It would be a serious error to have item-level exits actually send such messages, since at the time of item-level operations you don’t know that the user will actually follow through and commit the changed table to storage. Instead, you should accumulate message data from item-level exits and wait until the TSA exit to actually send it. At that point, you know the table has been successfully stored.
The general rule here is that the exit programs should not commit themselves to irrevocable actions until the user commits to storing the table.