Modifying Action Diagrams › Understanding Shared Subroutines › Externalizing the Function Interface

Externalizing the Function Interface

When the interface to a subroutine is inside the subroutine, each time it is called a new version of the subroutine is required. To externalize the function interface, a unique internal work field is assigned for each parameter field and the interface is generated as Move statements before and after the subroutine call. The names of the internal work context fields are generated in a similar fashion to that of Neither parameters. This provides up to 10,000 unique field names in a given program.

When an internal function is called:

1. The function’s Input and Both parameters are moved to the new internal work context prior to the call.
2. Within the called function, this internal work context is used instead of the original PAR context.
3. Output and Both parameters are moved back to the return context after the subroutine call.

Note: The Moves required before and after calling a subroutine increase overhead somewhat. If a function has more parameters than executable statements, then reusing the subroutine increases the number of source lines generated.

You control the sharing of subroutines using the Share Subroutine (YSHRSBR) model value and its associated function option. The table shows the valid values; function option values are shown in parentheses. The default is *NO.

The YSHRSBR model value and function option are available on the CHGOBJ, CRTOBJ, DLTOBJ, RTVOBJ, and EXCINTFUN function types.

In addition, the Generate as subroutine? function option is provided for the EXCINTFUN function type to indicate whether to implement the function in-line or as a subroutine. The default is not to generate as a subroutine.