The following example applies to the ON_ERROR command.
Consider the following RDML "input and validate" program:
REQUEST FIELDS(#A #B #C #D #E)
BEGINCHECK
FILECHECK FIELD(#A) USING_FILE(ACHECK)
FILECHECK FIELD(#B) USING_FILE(BCHECK)
FILECHECK FIELD(#C) USING_FILE(CCHECK)
FILECHECK FIELD(#D) USING_FILE(DCHECK)
FILECHECK FIELD(#E) USING_FILE(ECHECK)
ENDCHECK
This validation block is relatively inefficient because it performs all subsequent checks even if a previous check failed. For instance if field #A is in error then the checks of #B, #C, #D and #E are wasted because they will have to be performed again when field #A is corrected by the user.
The ON_ERROR command can be used to improve the efficiency of such a validation block by specifying a series of "premature ends" like this:
L10: REQUEST FIELDS(#A #B #C #D #E)
BEGINCHECK
FILECHECK FIELD(#A) USING_FILE(ACHECK)
ON_ERROR GOTO(L10)
FILECHECK FIELD(#B) USING_FILE(BCHECK)
ON_ERROR GOTO(L10)
FILECHECK FIELD(#C) USING_FILE(CCHECK)
ON_ERROR GOTO(L10)
FILECHECK FIELD(#D) USING_FILE(DCHECK)
ON_ERROR GOTO(L10)
FILECHECK FIELD(#E) USING_FILE(ECHECK)
ENDCHECK
Thus any failed check will cause control to be passed back to the REQUEST command and the error details will be displayed for correction. Of course the disadvantage of this technique is that if a field is in error all subsequent fields will not be validated until the first error is corrected.
