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 FORMroutines 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 WORKstatement 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 FORMroutines 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 FORMroutines (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.
For further information about RFC processing, refer to the Remote Communications documentation.