In response to the Work with Service Program References (WRKSPGREF) command that I provided in the September 25, 2008, installment of APIs by Example, I received a note from a reader asking for a similar tool that finds the programs or service programs that import a given procedure. Such a tool would be helpful if you need to alter the procedure interface in a way that would be incompatible with the current interface or if you want to perform an impact analysis given a requirement to remove or replace a procedure.
I welcome suggestions or ideas for new API-driven commands and utilities! When I receive a suggestion based on actual business need, I’m inspired to try to come up with a new API example. So I quickly envisioned a new Work with Program Import (WRKPGMIMP) command and embarked on the initial steps involved in the design of such a utility.
However, during my initial research, I realized that no direct way exists to examine the program or service program object and identify the procedures a module imports. However, if the module object still exists and remains unchanged, it is possible to establish the required reference between program and procedure.
The requirement of keeping the module around and intact potentially reduces the usefulness of the WRKPGMIMP command. For example, programs created by using a Create Bound (CRTBNDxxx) command, such as CRTBNDRPG, will do their the binding against a temporary module object in QTEMP, and therefore there’s no module object when you want to run WRKPGMIMP. So I added an option to the WRKPGMIMP command to help you locate all programs and service programs that contain modules that no longer exist or modules that are out of date (i.e., the source has been changed since the module was created). To take advantage of this option, you must specify the special value *VFYMODREF for the WRKPGMIMP command’s IMPORT parameter.
But let me start out with a brief discussion of the module anatomy of ILE programs and service programs. Both program types can be created from one or more modules all together making up the final program object. For programs, one module will provide the program entry module, and this is the one specified on the Create Program (CRTPGM) command’s Entry module (ENTMOD) parameter. This parameter by default points to the *FIRST module specified for the command’s module list (MODULE) parameter. For service programs, no single entry point exists, as each exported subprocedure effectively constitutes an individual entry point.