Complex synchronization

Synchronization issues may become quite complex, even within a single table. Consider comparing an employee’s salary to that of the supervisor. Whether and when to do this depends on how significant the comparison is, which in turn depends greatly on the organization.

In some organizations, an employee salary higher than the manager’s might be a routine occurrence and not worth checking at all. In others, it might be an oddity worth catching in an IXF exit and reporting to the operator as an information message. It is safe to use this exit when no more drastic action is taken.

In some organizations, such a row would be conspicuously anomalous and a more serious action such as rejecting the row or notifying the supervisor’s supervisor would be appropriate. An item-level exit must not take serious actions based on other rows in the table. Just as cross-field validation must wait for IXF time, so serious cross-row checks must wait for TSB or TSA time. The required data is not reliable until then.

For example, if the IXF exit rejects a salary greater than the supervisor’s, then the operator who attempts to update both salaries and takes the rows in the wrong order is put to some unnecessary trouble. The solution is to delay this check until the TSB exit.

Any other actions intended to ensure consistency within a table should also be taken at TSB exit time. For example, if the supervisor’s row has a Number of Subordinates field, then this is the correct time to adjust it to reflect any change which the employee row change implies.

Actions which keep the outside world posted on the state of the table should, in general, be done at TSA exit time. For example, if the required action when an employee is paid more than a supervisor is to notify the supervisor’s supervisor, then TSA is the correct time for such messages.