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.

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:

• in a FORM routine (called with PERFORM ON COMMIT)

• 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.

• in a V1 update-task function module (requested IN UPDATE TASK)

• 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

• in a V2 update-task function module (requested IN UPDATE TASK)

• Updates already executed for the current V2 function are rolled back.
• All update-task requests (V2) still to be executed are discarded.
• All background-task requests still to be executed are carried out.
• No updates for previously executed V1 functions 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

• in a background-task function module (requested IN BACKGROUND TASK DESTINATION)

• 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.
• Other previously executed updates are rolled back.
• No error message appears on the screen.