AS/400 Links Partner with Rochester Institute Contact Us
Training Catalog Free Downloads Privacy / Usage


FREE AS/400, iSeries, and System i / iSeries Downloads
HOME >> FREE AS/400, iSeries, and System i / iSeries Downloads >> RPG "Cheat Sheet" #2 -; Create a Service Program



RPG "Cheat Sheet" #2 - Create a Service Program
Author: Craig Pelkie


Overview

A service program is an OS/400 object (type *SRVPGM). Service programs are created by binding one or more modules (object type *MODULE) together. A service program usually contains one or more procedure or data exports. The exported procedures and data can be used in programs, modules and other service programs that are bound to the service program.

If the procedures or data in a module will be used in more than one program, it is usually advantageous to create a service program based on the module. When you create programs (object type *PGM) that bind directly to a module, each program has its own copy of the module's code, as it was at the time the program was created. If you make changes to the module, you need to recreate or update the program (using the UPDPGM command) so that the program will use the new version of the module. When you bind a program to a service program, the program uses the code in the service program's copy of the module. If you change the module and recreate or update the service program, the changes in the module are available to all programs that use the service program.

In most cases, you will design and create modules with the intention of binding them into service programs. If the code in a module is only used in one program, you may want to consider directly coding the procedures in the program itself.

Create a service program


Step 1 - Complete the coding for all modules used in the service program 
Verify that required modules are available.

  • Use the DSPMOD command to display each module and verify its list of procedure exports.
  • Verify that exported procedure names are unique among all modules that will be bound into the service program.

Comment: although it is possible to create a service program by resolving duplicate export names, it is better to avoid duplicate export names.

Suggestion: use the module name as the prefix for all procedures and data that are exported from the module.

Example: modules INVENTORY and PURCHASING each contain an exported procedure named checkQuantity. If you create a service program that uses the two modules, only one of the checkQuantity procedures can be exported from the service program.

To use both versions of the procedure, rename the procedures to INVENTORY_checkQuantity and PURCHASING_checkQuantity.

Note: the duplicate export name problem is not solved by simply creating two separate service programs. If you create a program that uses the two service programs, only one instance of the duplicate name will be usable.
 

Step 2 - Is this the "production build" of the service program? 
Yes, after creating the          Go to the next step. 
service program, it will
be used with production
programs 

--------------------------------------------------------------------

No, the service program is still being developed and tested  Do you have one or more binding directories that contain a list of modules and service programs that are to be bound to this service program?

--------------------------------------------------------------------

No or Don't Know - enter the Create Service Program (CRTSRVPGM) command similar to the following:

CRTSRVPGM SRVPGM(lib_name/srvpgm_name)
          MODULE(lib_name/module_name1 lib_name/module_name2...)
          EXPORT(*ALL)
          BNDSRVPGM(lib_name/srvpgm_name1 lib_name/srvpgm_name2...)
          TEXT('descriptive text')

Notes

  • You must bind one or more modules to create the service program.
  • If the service program is only bound to one module and the module has the same name as the service program, you can use the default value MODUL (*SRVPGM).
  • You only need to use the BNDSRVPGM parameter if the modules you are binding use exported procedures or data in other service programs.
  • The default value for the TEXT parameter is blank.

Examples

  1. Create service program SRVLIB/INVENTORY. The service program uses module SRVLIB/INVENTORY. Library SRVLIB is in the library list when you run the CRTSRVPGM command.
     
    CRTSRVPGM SRVPGM(SRVLIB/INVENTORY)
              EXPORT(*ALL)
              TEXT('Inventory service program')
     
  2.  Create service program SRVLIB/GENERAL. The service program uses modules SRVLIB/INVENTORY and SRVLIB/PURCHASING. Several exported procedures in service program SRVLIB/UTILS are also used.

CRTSRVPGM SRVPGM(SRVLIB/GENERAL)
          MODULE(SRVLIB/INVENTORY SRVLIB/PURCHASING)
          EXPORT(*ALL)
          BNDSRVPGM(SRVLIB/UTILS)
          TEXT('General procedures for inventory and
purchasing')

---------------------------------------------------------------

Yes - enter the Create Service Program (CRTSRVPGM) command similar to the following:

CRTSRVPGM SRVPGM(lib_name/srvpgm_name)
          MODULE(lib_name/module_name1 lib_name/module_name2...)
          EXPORT(*ALL)
          BNDSRVPGM(lib_name/srvpgm_name1 lib_name/srvpgm_name2...)
          BNDDIR(lib_name/bnddir_name1 lib_name/bnddir_name2...)
          TEXT('descriptive text')

Notes

  • If a required module is included in a binding directory, do not enter its name in the MODULE parameter.
  • If a required service program is included in a binding directory, do not enter its name in the BNDSRVPGM parameter.
  • The default value for the TEXT parameter is blank.


Examples

  1. Create service program SRVLIB/INVENTORY. The service program uses module SRVLIB/INVENTORY. Library SRVLIB is in the library list when you run the CRTSRVPGM command.

    CRTSRVPGM SRVPGM(SRVLIB/INVENTORY)
              EXPORT(*ALL)
              TEXT('Inventory service program')

  2. Create service program SRVLIB/GENERAL. The service program uses modules SRVLIB/INVENTORY and SRVLIB/PURCHASING. Several exported procedures in service program SRVLIB/UTILS are also used. Binding directory SRVLIB/SRV_MODS contains entries for the SRVLIB/INVENTORY and SRVLIB/PURCHASING modules. Binding directory SRVLIB/SRV_SRVPGM contains an entry for the UTILS service program.

CRTSRVPGM SRVPGM(SRVLIB/GENERAL)
          EXPORT(*ALL)
          BNDDIR(SRVLIB/SRV_MODS SRVLIB/SRV_SRVPGM)
          TEXT('General procedures for inventory and purchasing')

 

--------------------------------------------------------------------
Resolve any create errors if necessary. When the service program is successfully created, go to Step 4 below. 

Step 3 - Create the "production version" of the service program 
When you deploy a service program in a production environment, you will almost always find it to be advantageous to "version" the service program. OS/400 lets you assign one or more signatures to a service program. Each signature is associated with a set of procedures and data that are exported from the service program. Service program signatures are analogous to database file level checks. However, service program signatures can encompass multiple generations of the service program.

You assign signatures to a service program by using binder source. Binder source is a series of source statements in a source member. You can use the Retrieve Binder Source (RTVBNDSRC) command to create binder source or you can manually enter binder source. When you are ready to deploy a service program for production, you indicate that the service program is associated with the binder source.

--------------------------------------------------------------------
Do you have a binder source member available for the service program that you are creating? 

No

Use the Retrieve Binder Source (RTVBNDSRC) command for each of the modules that are included in the service program, or manually enter binder source statements into a binder source member.

Once you have the binder source, follow the steps shown below for the "Yes" response for this step. 


--------------------------------------------------------------------

Yes

Is the binder source member name the same as the service program name, and is the binder source member in source file QSRVSRC? 

---------------------------------------------------------------Yes - Use the following form of the CRTSRVPGM command:

CRTSRVPGM SRVPGM(lib_name/srvpgm_name)
          MODULE(lib_name/module_name1 lib_name/module_name2...)
          BNDSRVPGM(lib_name/srvpgm_name1 lib_name/srvpgm_name2...)
          BNDDIR(lib_name/bnddir_name1 lib_name/bnddir_name2...)
          TEXT('descriptive text')


---------------------------------------------------------------
No - Use the following form of the CRTSRVPGM command:

CRTSRVPGM SRVPGM(lib_name/srvpgm_name)
          MODULE(lib_name/module_name1 lib_name/module_name2...)
          EXPORT(*SRCFILE)
          SRCFILE(lib_name/bndsrc_name)
          SRCMBR(bndsrc_mbr)
          BNDSRVPGM(lib_name/srvpgm_name1 lib_name/srvpgm_name2...)
          BNDDIR(lib_name/bnddir_name1 lib_name/bnddir_name2...)
          TEXT('General procedures for inventory and purchasing')

---------------------------------------------------------------
Notes

  • If the service program is only bound to one module and that module has the same name as the service program, you can use the default value MODULE(*SRVPGM).
  • You only need to use the BNDSRVPGM parameter if the modules you are binding use exported procedures or data in other service programs.
    The BNDDIR parameter is optional and is only needed if you are using one or more binding directories to locate required modules and service programs.
  • The default value for the TEXT parameter is blank.


Examples

  1. Create service program SRVLIB/INVENTORY. The service program uses module SRVLIB/INVENTORY. Library SRVLIB is in the library list when you run the CRTSRVPGM command.

    Source file SRVLIB/QBNDSRC contains source member GENERAL. That source member contains binder source statements that list the exported procedures and data for the service program.

    CRTSRVPGM SRVPGM(SRVLIB/INVENTORY)
              TEXT('Inventory service program')

  2. Create service program SRVLIB/GENERAL. The service program uses modules SRVLIB/INVENTORY and SRVLIB/PURCHASING. Several exported procedures in service program SRVLIB/UTILS are also used. Binding directory SRVLIB/SRV_MODS contains entries for the SRVLIB/INVENTORY and SRVLIB/PURCHASING modules. Binding directory SRVLIB/SRV_SRVPGM contains an entry for the UTILS service program.

    Source file SRVLIB/QBNDSRC contains source member GENERAL. That source member contains binder source statements that list the exported procedures and data for the service program.

    CRTSRVPGM SRVPGM(SRVLIB/GENERAL)
              EXPORT(*SRCFILE)
              SRCFILE(SRVLIB/QBNDSRC)
              SRCMBR(GENERAL)
              BNDDIR(SRVLIB/SRV_MODS SRVLIB/SRV_SRVPGM)
              TEXT('General procedures for inventory and purchasing')


Step 4 - Use the DSPSRVPGM command to review the service program 
Use the Display Service Program (DSPSRVPGM) command to review the attributes of the *SRVPGM object:

DSPSRVPGM SRVPGM(libname/srvpgm_name)
          DETAIL(*ALL)

Notes:

  • *BASIC (panel 1 of 10) - shows the activation group that the service program will run in (default value: *CALLER) and the current export signature. When you create programs and other service programs that use this service program, the current export signature is copied into those objects. At run-time, the copied-in signature value is compared with the list of signatures that are in the service program.
  • *MODULE (panel 3 of 10) - shows the list of modules that were used to create the service program. Verify that all of the required modules are present and that the correct library was specified, if a module of the same name is in multiple libraries.
  • *SRVPGM (panel 4 of 10) - shows the list of service programs that are bound to this service program. Verify that all of the required service programs are listed and that the correct library was specified, if a service program of the same name is in multiple libraries. You will see some IBM supplied service programs in the list; you can ignore those entries.
  • *PROCEXP (panel 5 of 10) - shows the list of procedures that are exported from the service program. Clients of this service program (programs, modules and other service programs) can call these procedures. Use this list to verify the following:
    • All procedures that you intend to use in other objects are listed (the EXPORT keyword was specified for procedures and a binder source entry for the procedure is in the binder source member)
    • Only the procedures that you intend to use in other objects are listed (you did not erroneously specify EXPORT for an internal-use only procedure)
  • *DTAEXP (panel 6 of 10) - shows the list of data that are exported from the service program. You can use the data in clients of this service program (programs, modules and other service programs).
  • Suggestion: rather than export data, consider creating accessor procedures in your modules to get and set the values of module data. Data exports are essentially "globally defined variables", which break encapsulation. The data can be freely modified in any client of the service program, which can lead to difficult to find bugs.
  • *SIGNATURE (panel 9 of 10) - shows the list of signatures that are associated with the service program. If you do not assign a signature in binder source, a default current signature is generated and assigned to the service program
  • *COPYRIGHT (panel 10 of 10) - shows the copyright text for all modules that specify the text. You can assign a copyright string in RPG using the H-spec COPYRIGHT keyword. You may want to use the copyright text for other information about the module. 

Learn how to create ILE RPG subprocedures, modules, service programs and programs! Order your copy of Subprocedures for RPG Programmers  by Craig Pelkie.