Error Handling for Bundled Updates 

Runtime errors can occur during execution of bundled updates. How are they handled? In general, COMMIT WORK processing occurs in the following order:

  1. All dialog-task FORM routines logged with PERFORM ON COMMIT are executed.
  2. All high-priority (V1) update-task function modules are executed.

    3. The end of V1-update processing marks the end of the . If you used COMMIT WORK AND WAIT to trigger commit processing, control returns to the dialog-task program.

  3. All low-priority (V2) update-task function modules are triggered.
    All background-task function modules are triggered.

Runtime errors can occur either in the system itself, or because your program issues an termination message (MESSAGE type ‘A’). Also, the ROLLBACK WORK statement automatically signals a runtime error. The system handles errors according to where they occur:

- Updates already executed for the current update transaction are rolled back.

- No other FORM routines will be started.

- No further update-task or background-task functions will be started.

- An error message appears on the screen.

- Updates already executed for V1 functions are rolled back.

- All further update-task requests (V1 or V2) are thrown away.

- All background-task requests are thrown away.

- Updates already executed for FORM routines called with PERFORM ON COMMIT are not rolled back.

- An error message appears on the screen, if your system is set up to send them

- Updates already executed for the current V2 function are rolled back.

- All update-task requests (V2) still to be executed are carried out.

- All background-task requests still to be executed are carried out.

- No updates for previously executed V1 or V2 function are rolled back.

- No updates previously executed for FORM routines (called with ON COMMIT) are rolled back.

- An error message appears on the screen, if your system is set up to send them

- Background-task updates already executed for the current DESTINATION are not rolled back.

- All further background-task requests for the same DESTINATION are thrown away.

- No other previously-executed updates are not rolled back.

- No error message appears on the screen.

If your program detects that an error in remote processing has occurred, it can decide whether to resubmit the requests at a later time.

For further information about RFC processing, refer to the Remote Communications documentation.