Skip to main content

Service Program, Binder Source & Binding Directory

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.


You create a service program, and bind modules to it, with CRTSRVPGM which does not require a source member.


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)                          


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).


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;


After the binding directory has been created and procedures have been added the calling program can specify the binding directories in the H specs ;

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. 


Popular posts from this blog

All about READ in RPGLE & Why we use it with SETLL/SETGT?

READ READ is one of the most used Opcodes in RPGLE. As the name suggests main purpose of this Opcode is to read a record from Database file. What are the different READ Opcodes? To list, Below are the five Opcodes.  READ - Read a Record READC - Read Next Changed Record READE - Read Equal Key Record READP - Read Prior Record READPE - Read Prior Equal Record We will see more about each of these later in this article. Before that, We will see a bit about SETLL/SETGT .  SETLL (Set Lower Limit) SETLL accepts Key Fields or Relative Record Number (RRN) as Search Arguments and positions the file at the Corresponding Record (or Next Record if exact match isn't found).  SETGT (Set Greater Than) SETGT accepts Key Fields or Relative Record Number (RRN) as Search Arguments and positions the file at the Next Record (Greater Than the Key value). Syntax: SETLL SEARCH-ARGUMENTS/KEYFIELDS FILENAME SETGT  SEARCH-ARGUMENTS/KEYFIELDS FILENAME One of the below can be passed as Search Arguments. Key Fiel

What we need to know about CHAIN (RPGLE) & How is it different from READ?

CHAIN READ & CHAIN, These are one of the most used (& useful) Opcodes by any RPG developer. These Opcodes are used to read a record from file. So, What's the difference between CHAIN & READ?   CHAIN operation retrieves a record based on the Key specified. It's more like Retrieving Random record from a Database file based on the Key fields.  READ operation reads the record currently pointed to from a Database file. There are multiple Opcodes that start with READ and all are used to read a record but with slight difference. We will see more about different Opcodes and How they are different from each other (and CHAIN) in another article. Few differences to note.  CHAIN requires Key fields to read a record where as READ would read the record currently pointed to (SETLL or SETGT are used to point a Record).  If there are multiple records with the same Key data, CHAIN would return the same record every time. READE can be used to read all the records with the specified Ke

Extract a portion of a Date/Time/Timestamp in RPGLE - IBM i

%SUBDT Extracting Year, Month, Day, Hour, Minutes, Seconds or Milli seconds of a given Date/Time/Timestamp is required most of the times.  This can be extracted easily by using %SUBDT. BIF name looks more similar to %SUBST which is used to extract a portion of string by passing from and two positions of the original string. Instead, We would need to pass a value (i.e., Date, Time or Timestamp ) and Unit (i.e., *YEARS, *MONTHS, *DAYS, *HOURS, *MINUTES, *SECONDS or *MSECONDS) to %SUBDT.  Valid unit should be passed for the type of the value passed. Below are the valid values for each type. Date - *DAYS, *MONTHS, *YEARS Time - *HOURS, *MINUTES, *SECONDS Timestamp - *DAYS, *MONTHS, *YEARS, *HOURS, *MINUTES, *SECONDS, *MSECONDS Syntax: %SUBDT(value : unit { : digits { : decpos} }) Value and Unit are the mandatory arguments.  Digits and Decimal positions are optional and can only be used with *SECONDS for Timestamp. We can either pass the full form for the unit or use the short form. Below i