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.
- 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.
TIP
A *PSSR is local to the procedure in which it is coded; therefore, to have a common error routine, you can code a procedure to handle the error and call the procedure from each local *PSSR.