Service Programs Part 1

Serving Modules
Service programs consist of one or more modules. By referencing a service program at the time a program is created, any module that is defined in your service program export list is available to your program for binding. As a result, you end up with a "buffet" of procedure choices without the added complexity of listing them each individually on the CRTPGM command. Any collection of *MODULE objects can be used to create a service program, including "main" modules, but even so, neither a service program nor any of its procedures can be called directly; instead, they must be bound by a program. A service program has an object-type of *SRVPGM, and, like a *PGM object, once it has been created the constituent *MODULE objects can be deleted.
Let's return to the original example, only now we have four modules to bind together in order to create the program. Our command now looks something like this:
CRTPGM PGM(MYLIB/MYPGM)
MODULE(MYLIB/ENTRYMOD MYLIB/PROC1 MYLIB/PROC2 MYLIB/PROC3)
As you can see, the command just gets longer and longer, but we are about to change that. Let's assume that PROC1, PROC2, and PROC3 are all subprocedures and that they are used extensively throughout our software. Instead of maintaining them individually like this for each command, you want to put them into a service program. Here is a command that will do so quickly: CRTSRVPGM SRVPGM(MYLIB/MYSRVPGM) MODULE(MYLIB/PROC1 MYLIB/PROC2 MYLIB/PROC3) EXPORT(*ALL)
You now have a *SRVPGM object called MYSRVPGM. By specifying EXPORT(*ALL), you are making all of the modules listed on the CRTSRVPGM command available to any program that references the service program at creation time. Before I continue I must point out that this is not how I recommend managing the objects in your service programs, but is invariably where everyone starts and is a crucial step toward understanding service program maintenance. You can view the module contents of the service program by running this command:
DSPSRVPGM SRVPGM(MYLIB/MYSRVPGM) DETAIL(*MODULE)
Run this command without a DETAIL attribute specified, and you can scroll through 11 different displays and get a great deal of information.
Now when you want to create the program, the command looks a little different:
CRTPGM PGM(MYLIB/MYPGM) MODULE(MYLIB/ENTRYMOD) BNDSRVPGM(MYLIB/MYSRVPGM)
Hopefully, you will agree that this command is much cleaner to use, especially if you had 30 modules instead of three. While this is nice, the greatest benefit comes when you need to change a module. In the first example, you had to execute the Update Program (UPDPGM) command for every program that uses the module, which was not a pretty maintenance picture. With service programs, you only have to issue one command, UPDSRVPGM, like so:
UPDSRVPGM SRVPGM(MYLIB/MYSRVPGM) MODULE(MYLIB/PROC2)
Doing so updates not only the service program itself but also all of the programs that have bound PROC2. This automatic update is perhaps the best argument for using service programs, but it can also cause its own set of problems.