Service Program:
A service program (object type *SRVPGM) is a set of procedures that can be bound into ILE RPG programs. Basically when the service program is referenced any of its procedures might then be called. These callable procedures that are defined to the service program are referred to as exports which can be any ILE module, program, or even other service programs.
Service programs do not have a program entry procedure and therefore are non-callable. When bound the service program code is only referenced by linkages. That is, unlike other bound programs, the service program exports are not directly copied into the compiled program. The benefit of using a service program is easier maintenance, consistent performance, and more efficient processing.
As you know many software packages will have some global APIs. A date manipulation/validation API is a prime example of when a service program, full of date validation and conversion sub procedures, could be used. Other common examples include string manipulation procedures, combining procedures that retrieve or manipulate the run-time environment (adding to the library list for example), message handling, authority checking, XML, data encryption, IFS interface, email, etc.(something like a Java class or windows DLL).
RPG Modules can be created using CRTRPGMOD. A Module can have much number of procedures. These procedures are as similar to reusable subroutines, only more flexible in view of passing parameters, returning result variable. Starting and ending lines of the procedure can be identified with Begin & End of Procedure Statements on P - Spec.
CRTRPGMOD MODULE(MYLIB/MOD1) SRCFILE(MYLIB/QRPGLESRC)
You create a service program, and bind modules to it, with CRTSRVPGM which does not require a source member.
CRTSRVPGM SRVPGM(MYLIB/SRVPGM1) MODULE(MOD1 MOD2, MOD3) EXPORT(*ALL)
Binder Source:
By using EXPORT(*ALL) on CRTSRVPGM Command, Service program will be created with all procedures available in attached Modules.
You will find the importance binder source when there are many procedures in modules being attached and you would like only few modules to be exported through service program, You can achieve that by using binder source.
Example source for Binder Source.
STRPGMEXP PGMLVL(*CURRENT)
EXPORT SYMBOL(PROCEDURE1)
EXPORT SYMBOL(PROCEDURE2)
ENDPGMEXP
CRTSRVPGM SRVPGM(MYLIB/SRVPGM1) MODULE(MOD1 MOD2, MOD3) EXPORT(*SOURCE) SRCFILE(MYLIB/QSRVSRC) SRCMBR(SRVPGM1)
Binding Directory:
Exporting procedures from service program is powerful tool in developer tool kit, yet you can gain more advantages of it by using Binding Directory.
E.g. 1:
You are writing a service program to export modules from 10 different Modules. And, few of these modules are using procedures that are being exported by different service program.
In this case, You can mention the Modules & Service programs in Binding Directory and use CRTSRVPGM with parameter BNDDIR(BIND1).
CRTSRVPGM SRVPGM(MYLIB/SRVPGM1) MODULE(MOD1 MOD2, MOD3) EXPORT(*SOURCE) SRCFILE(MYLIB/QSRVSRC) SRCMBR(SRVPGM1) BNDDIR(BIND1)
E.g. 2:
You are writing an RPGLE program which would take advantage of procedures that have been created in multiple service programs.
You can take advantage of Binding directory by attaching those service programs to binding directory and attach it to your program.
Referring to the service program can be done one program at a time or, better yet, by using a binding directory. With the binding directory specified in the control specifications any unresolved procedure, sub procedure, program, or service program in that directory can be accessed when compiling and the CRTBNDRPG, CRTPGM, and CRTSRVPGM will not need individual module names specified. To see an IBM binding directory use the following command;
WRKBNDDIRE QSYS/QC2LE
After the binding directory has been created and procedures have been added the calling program can specify the binding directories in the H specs ;
0001.00 H DFTACTGRP(*NO) ACTGRP(*CALLER)
0002.00 H BNDDIR('BIND1':'BIND2')
Such a program must be created with the CRTBNDRPG command.
Note that the DFTACTGRP is set to *No to take advantage of ILE binding. Think of DFTACTGRP(*YES) as more related to OPM programming and DFTACTGRP more appropriate for ILE.
There are a few issues to consider when using service programs. When the caller references the service program some overhead is incurred. Normally this is offset by performance improvements. It is only an issue if the service program is called from the same program repeatedly. Also, certain changes to service programs can alter the "signature" of the service program which might require rebinding or recompiling some programs. This situation can be avoided by using binding source.
Comments
Post a Comment