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.

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 as a result of a 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 discarded.

○       Other previously executed updates are rolled back.

○       No error message appears on the screen.

If your program detects that an error in remote processing has occurred, the requests can be resubmitted at a later time.

More information about RFC processing: Remote Communications documentation.