Exception Handling within Subprocedures

Exception handling within a subprocedure, including one designated as a linear-main procedure, differs from exception handling within a cycle-main procedure in the following ways:

• If you are using a global file, then because you cannot code an INFSR subroutine for that file, you should handle file errors using error indicators, the 'E' operation code extender, or a MONITOR group.
• There is no default handler; in other words, users will never see an inquiry message.

Exception handling within a subprocedure differs from a cycle-main procedure primarily because there is no RPG cycle code generated for subprocedures. As a result there is no default exception handler for subprocedures and so situations where the default handler would be called for a cycle-main procedure correspond to abnormal end of the subprocedure. This means that:

• Factor 2 of an ENDSR operation for a *PSSR subroutine within a subprocedure must be blank. A blank factor 2 in a cycle-main procedure would result in control being passed to the default handler. In a subprocedure, if the ENDSR is reached, then the subprocedure will end abnormally and RNX9001 will be signalled to the caller of the subprocedure.
• If there is no *PSSR and a function check occurs, the procedure is removed from the call stack and the exception is percolated to the caller.
• Since an inquiry message is never issued for an error in a subprocedure, you do not have access to the 'Retry' function available for some I/O errors. If you expect record-lock errors in a subprocedure, you should code an error indicator or an 'E' extender and check if the status is related to a record being locked.

Note that the PSDS and INFDS for global files have module scope. Both main procedures and subprocedures can access them.