BEGINCHECK / ENDCHECK blocks can be nested. However, if an "inner" block detects an error it also triggers an error in all associated "outer" blocks.
This can be illustrated like this:
A validation error in this block will "trigger" a
validation error at all levels (marked by <-).
The ability to nest BEGINCHECK / ENDCHECK commands is particularly useful when processing screens that have browse lists that are used for data entry. Consider a data entry screen like this:
The RDML program to process data entered in this way might look something like this:
GROUP_BY NAME(#ORDERHEAD) FIELDS(#ORDNUM #CUSTNUM #DATEDUE)
DEF_LIST NAME(#ORDERLINE) FIELDS(#ORDLIN #PRODUCT #QUANTITY #PRICE)
INZ_LIST NAMED(#ORDERLINE) NUM_ENTRYS(20)
L1: REQUEST FIELDS(#ORDERHEAD) BROWSELIST(#ORDERLINE)
<< validate order header details >>
SELECTLIST NAMED(#ORDERLINE) GET_ENTRYS(*NOTNULL) <-
<< validate order line details >> |
UPD_ENTRY IN_LIST(#ORDERLINE) |
ENDCHECK IF_ERROR(*NEXT) |
<< update database >>
Note that the "inner" BEGINCHECK/ENDCHECK loop is processed for each browse list entry that the user entered. Note also that the IF_ERROR(*NEXT) parameter causes the SELECTLIST loop to continue to process all browse list entries and not stop the first time an error is detected.
The "outer" BEGINCHECK/ENDCHECK command uses the IF_ERROR(*LASTDIS) parameter which will cause the REQUEST command to be re-executed if a validation error is detected. A validation error will be "detected" if
an error is found in the order header details.
an error is found in one or more of the order line details. This happens because any error in the "inner" validation block also triggers an error in the "outer" validation block.