Subprocedure Considerations

These considerations apply to ordinary subprocedures and linear-main procedures except as otherwise noted.

• Any of the calculation operations may be coded in a subprocedure. However, input and output specifications are not supported in subprocedures, so data structure result fields must be used for file I/O operations to files defined locally in the subprocedure. All data areas must be defined in the main source section, although they can be used in a subprocedure.
• The control specification can only be coded in the main source section since it controls the entire module.
• A subprocedure can be called recursively.Each recursive call causes a new invocation of the procedure to be placed on the call stack. The new invocation has new storage for all data items in automatic storage, and that storage is unavailable to other invocations because it is local. (A data item that is defined in a subprocedure uses automatic storage unless the STATIC keyword is specified for the definition.)

  The automatic storage that is associated with earlier invocations is unaffected by later invocations. All invocations share the same static storage, so later invocations can affect the value held by a variable in static storage.

  Recursion can be a powerful programming technique when properly understood.

• The run-time behavior of a subprocedure (including a linear-main procedure) differs somewhat from that of a cycle-main procedure, because there is no cycle code for the subprocedure.
  • When a subprocedure ends, any open local files in automatic storage are closed. However, none of the termination activities, such as closing of global files, occurs until the cycle-main procedure, if any, that are associated with the subprocedure itself ends. If you want to ensure that your global files are closed before the activation group ends, you can code a "cleanup" subprocedure that is called both by the program entry procedure at application-end, and by a cancel handler enabled for the program entry procedure.

    An alternative to using a cleanup procedure is to code the module so that there is no implicit file opening or data area locking, and that within any subprocedure, an open is matched by a close, an IN by an OUT, a CRT by a DLT, and so on. This alternative should be strongly considered for a cycle-module if it might have a subprocedure active when the cycle-main procedure is not active.

  • Exception handling within a subprocedure differs from a cycle-main procedure primarily because there is no default exception handler for subprocedures. As a result, situations where the default handler would be called for a cycle-main procedure correspond to abnormal end of the subprocedure.