No cycle code is generated for a subprocedure, and so you must
code it differently than you would code a cycle-main procedure. The
subprocedure ends when one of the following occurs:
A RETURN operation is processed
The last calculation in the body of the subprocedure is processed.
Figure 12 shows the normal processing steps for a subprocedure. Figure 13 shows the exception/error handling sequence.
Figure 12. Normal Processing Sequence for a Subprocedure
1
Taking the "No" branch means that another procedure has already been
called since the program was activated. You should ensure that you do not
make any incorrect assumptions about the state of files, data areas, etc.,
since another procedure may have closed files, or unlocked data areas.
2
If an entry parameter to the main procedure is RESET anywhere
in the module, this will cause an exception. If it is possible that a subprocedure
will be called before the main procedure, it is not advised to RESET any entry
parameters for the cycle-main procedure.
Figure 13. Exception/Error Handling Sequence for a Subprocedure
Here are some points to consider when coding subprocedures:
There is no *INZSR associated with subprocedures. Data is initialized
(with either INZ values or default values) when the subprocedure is first
called, but before the calculations begin.
Note also that if the subprocedure
is the first procedure to be called in a module, the
*INZSR of the cycle-main procedure (if present) will not be run, although
other initialization of global data will be done. The *INZSR of the cycle-main
procedure will be run when the cycle-main procedure is called.
When a subprocedure returns normally, the return value, if
specified on the prototype of the called program or procedure, is passed to
the caller. Nothing else occurs automatically. All files and data areas must
be closed manually. Files must be written out manually. You can set on the
LR or RT indicators, but it will have no immediate effect on the program termination.
If the the subprocedure was called by a cycle-main procedure, the setting
of the LR or RT indicators would take effect when the RPG cycle reached the
point at which RPG checks those indicators.
Exception handling within a subprocedure differs from a cycle-main
procedure primarily because 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. For example, Factor
2 of an ENDSR operation for a *PSSR subroutine within a subprocedure must
be blank. A blank Factor 2 of the ENDSR for the *PSSR subroutine in a cycle-main
procedure would result in control being passed to the default handler. In
a subprocedure, if the ENDSR of the *PSSR subroutine is reached, then the
subprocedure will end abnormally and RNX9001 will be signalled to the caller
of the subprocedure.
You can avoid abnormal termination either by coding
a RETURN operation in the *PSSR, or by coding a GOTO and label in the subprocedure
to continue processing.
The *PSSR error
subroutine is local to the subprocedure.
You cannot code an INFSR in a subprocedure, nor can you use a file for
which an INFSR is coded.
Indicators that control the cycle function solely as conditioning indicators
when used in a linear module (MAIN or NOMAIN on control specification); or
in a subprocedure that is active, but where the cycle-main procedure of the
module is not. Indicators that control the cycle include: LR, RT, H1-H9,
and control level indicators.
