Tips for Creating Modules, Programs, and Service Programs

To create and maintain modules, ILE programs, and service programs conveniently, consider the following:
  • Follow a naming convention for the modules that will get copied to create a program or service program.

    A naming strategy with a common prefix makes it easier to specify modules generically on the module parameter.

  • For ease of maintenance, include each module in only one program or service program. If more than one program needs to use a module, put the module in a service program. That way, if you have to redesign a module, you only have to redesign it in one place.
  • To ensure your signature, use the binder language whenever you create a service program.

    The binder language allows the service program to be easily updated without having to re-create the using programs and service programs.

    The Retrieve Binder Source (RTVBNDSRC) command can be used to help generate the binder language source based on exports from one or more modules or service programs.

    If either of the following conditions exists:
    • A service program will never change
    • Users of the service program do not mind changing their programs when a signature changes
    you do not need to use the binder language. Because this situation is not likely for most applications, consider using the binder language for all service programs.
  • If you get a CPF5D04 message when using a program creation command such as CRTPGM, CRTSRVPGM, or UPDPGM, but your program or service program is still created, there are two possible explanations:
    1. Your program is created with OPTION(*UNRSLVREF) and contains unresolved references.
    2. You are binding to a *SRVPGM listed in *BNDDIR QSYS/QUSAPIBD that is shipped with *PUBLIC *EXCLUDE authority, and you do not have authority. To see who is authorized to an object, use the DSPOBJAUT command. System *BNDDIR QUSAPIBD contains the names of *SRVPGMs that provide system APIs. Some of these APIs are security-sensitive, so the *SRVPGMs they are in are shipped with *PUBLIC *EXCLUDE authority. These *SRVPGMs are grouped at the end of QUSAPIBD. When you are using a *PUBLIC *EXCLUDE service program in this list, the binder usually has to examine other *PUBLIC *EXCLUDE *SRVPGMs ahead of yours, and it takes the CPF5D04.

    To avoid getting the CPF5D04 message, use one of the following methods:

    • Explicitly specify any *SRVPGMs your program or service program is bound to. To see the list of *SRVPGMS your program or service is bound to, use DSPPGM or DSPSRVPGM DETAIL(*SRVPGM). These *SRVPGMs can be specified on the CRTPGM or CRTSRVPGM BNDSRVPGM parameter. They can also be placed into a binding directory given on the CRTBNDRPG, CRTRPGMOD, CRTBNDCBL, CRTPGM, or CRTSRVPGM BNDDIR parameter, or from an RPG H-spec. Taking this action ensures that all references are resolved before the *PUBLIC *EXCLUDE *SRVPGMs in *BNDDIR QUSAPIBD need to be examined.
    • Grant *PUBLIC or individual authority to the *SRVPGMs listed in the CPF5D04 messages. This has the drawback of authorizing users to potentially security-sensitive interfaces unnecessarily.
    • If OPTION(*UNRSLVREF) is used and your program contains unresolved references, make sure all references are resolved.
  • If other people will use a program object or service program that you create, specify OPTION(*RSLVREF) when you create it. When you are developing an application, you may want to create a program object or service program with unresolved imports. However, when in production, all the imports should be resolved.

    If OPTION(*WARN) is specified, unresolved references are listed in the job log that contains the CRTPGM or CRTSRVPGM request. If you specify a listing on the DETAIL parameter, they are also included on the program listing. You should keep the job log or listing.

  • When designing new applications, determine if common procedures that should go into one or more service programs can be identified.

    It is probably easiest to identify and design common procedures for new applications. If you are converting an existing application to use ILE, it may be more difficult to determine common procedures for a service program. Nevertheless, try to identify common procedures needed by the application and try to create service programs containing the common procedures.

  • When converting an existing application to ILE, consider creating a few large programs.

    With a few, usually minor changes, you can easily convert an existing application to take advantage of the ILE capabilities. After you create the modules, combining them into a few large programs may be the easiest and least expensive way to convert to ILE.

  • Try to limit the number of service programs your application uses.

    This may require a service program to be created from more than one module. The advantages are a faster activation time and a faster binding process.

    There are no simple answers for the number of service programs an application should use. If a program uses hundreds of service programs, it is probably using too many. On the other hand, one service program may not be practical either.