Wed, Jul
0 New Articles

Introduction to Service Programs

  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Learn how to create, compile, bind, and deploy service programs.


Editor's note: This article is excerpted from Programming in ILE RPG, Fifth Edition (MC Press, 2015), chapter 15, "Building and Using Service Programs."


Chapter 14 introduced the bind-by-copy model for creating an ILE program. Under this technique, a program includes a main procedure and optional subprocedures; all code for the program is physically copied into the program during the binding process. The resulting program (*Pgm object) is a single entry-point program. The entry module contains the main procedure, which is the first user-written code that is executed when the program is called. When many different programs use the same subprocedure, then many redundant copies of the subprocedure exist. If it is necessary to change the subprocedure, you must copy the new code into all those different programs, perhaps by using the UPDPGM CL command many times. Unless your organization has excellent documentation disciplines or change management tools, determining which programs are using any one subprocedure can be challenging.


To provide an alternative to the bind-by-copy single entry-point program, ILE introduces a different kind of program, the service program (*Srvpgm object). A service program is a container for subprocedures—a code toolbox that many programs can use without the binder having to physically copy the subprocedure code into each program. This program creation model is called bind-by-reference.


A service program is not a standalone executable object; it does not have a main procedure. Instead, any subprocedure in a service program can be an entry point into the service program. Thus, a service program is said to be a multiple entry-point program. A single entry-point ILE program—or another service program—can invoke any exported procedure in the service program. But, in the service program, only one copy of the actual subprocedure code exists, which many other programs (clients) share. Service programs combine some of the performance advantages of bind-by-copy static binding with the modularity and flexibility benefits of the dynamic program call.


15.3. Compiling and Binding Service Programs

Procedures that reside in a service program have no unique coding requirements. You code the procedures in a service program in Nomain modules. The procedure code uses the same syntax that we've already discussed. Although there is no main procedure, the source can still have a global declarations section. Items you declare in the global section, before any subprocedures, will be available to the procedures within the module. This section includes a prototype for each procedure, and items you declare within a procedure will be local to that procedure. After entering the source code for the module, you compile it normally by using the CRTRPGMOD command. The end result of the compile process is a *Module object.


Typically, procedures in a service program's Nomain module use the Export keyword to ensure that they are available to client programs. If, however, you want to hide a procedure in a service program so that only other procedures in the same module object can invoke it, omit the Export keyword.


As you might expect, you must next bind the appropriate module objects to use them. Just as with single entry-point programs, you can bind service programs from a single module or from multiple modules, and you can include modules written in different languages. Recall that the CRTPGM CL command performs the binding step for a single entry-point program. The CRTSRVPGM (Create Service Program) command performs the same function for a multiple entry-point service program. Figure 15.1 illustrates the prompted CRTSRVPGM command.



Figure 15.1: CRTSRVPGM (Create Service Program) command


The CRTSRVPGM command looks much like the CRTPGM command, and it serves much the same purpose, except that it creates a service program. As with the CRTPGM command, the service program binding process requires a list of modules to copy into the *Srvpgm object. Notice, though, that CRTSRVPGM specifies no parameter to designate an entry module. Because a service program is a multiple entry-point program, there is no entry module.


When you create a service program, its procedures might refer to other procedures that reside in other service programs. The CRTSRVPGM binder can list those service programs (in the BNDSRVPGM parameter, under Advanced Parameters), which are then bound by reference to the service program you are creating. All the exported procedures from those service programs are available to your service program as well. We'll discuss binding by reference in more detail shortly.


Also notice that the CRTSRVPGM command, like the CRTPGM command, supports the use of binding directories. Recall from Chapter 13 that a binding directory—a list of reusable modules—allows the binder to find necessary modules that you may not have explicitly listed with the binder command. In addition to module entries, a binding directory can store the names of service programs that you intend to reuse among many different programs. When the binder finds the required procedure in a module entry, it binds the module by copy. When it finds the necessary procedure in a service program entry, it binds the service program (and all its procedures) by reference. Once the binder finds all the procedures it needs, the end result of a successful binding step is a *Srvpgm object.


15.4. Deploying Service Programs in an Application

A single entry-point program—or another service program—can invoke any procedure in a service program. But the calling program does not call the service program itself. Because a service program lacks a main procedure, you cannot call it. Instead, the caller invokes an individual procedure in a service program by using the same syntax that it would use if the procedure were bound to it by copy:


Callp Updcust(Company:Custnbr);




Metrictemp = Celsius(Englishtemp);




If Celsius(Englishtemp) > 100;



Recall that when you bind a module to a program, the binder physically copies the executable code from the module into the program—hence, the term bind-by-copy. When you bind a service program to an ILE program or to another service program, the binder does not physically copy the code to the client. Instead, the binder makes a reference associating the client with the service program and each of the procedures in it (i.e., bind-by-reference). You can think of the program as jotting a note to itself, a reminder that when it's time to load itself at runtime, it must also load any service programs that have been bound to it by reference. After the client program and any of its associated service programs have been loaded, all the procedures work together as a unit, regardless of whether they were bound by copy or by reference. If the client program cannot find all the service programs bound to it, or if a bound service program no longer exports a needed procedure, the program activation fails.


Regardless of how many clients use the procedures in a service program, only one copy of the executable code exists in the service program. When many programs use a procedure, bind-by-reference avoids the redundancy of bind-by-copy, and it can eliminate the need to update many programs when you must correct or enhance a procedure.


If the way you invoke a procedure in a module and the way you invoke it in a service program are the same, how will your program know which technique to use? The answer lies in the way that you bind the procedure to the calling program. When you use the CRTPGM command to bind a single entry-point program or the CRTSRVPGM command to bind a service program, you choose between either bind-by-copy or bind-by-reference. These commands have three parameters in common that control the binding technique:


You have several components to consider when creating a single entry-point program or a service program. Both the CRTPGM command and the CRTSRVPGM command bind these components in order. First, all the *Module objects listed in the MODULE parameter are bound by copy. Next, all the *Srvpgm objects listed in the BNDSRVPGM parameter are bound by reference. Finally, for any unresolved exports, the binder searches entries in the binding directories listed in the BNDDIR parameter. If it finds a required procedure in a module entry, it binds that *Module by copy. The binding directory can also list service programs as well as modules (Figure 15.2). If the binder, either CRTPGM or CRTSRVPGM, finds a needed procedure in a service program entry, it binds that *Srvpgm by reference. The binder ignores all unnecessary binding directory entries to complete the binding process.



Figure 15.2: Binding directory entries


When the binding process uses a service program by reference, all the exported procedures in that service program are available to the bound program (or service program), whether or not the bound program uses all of them. You should organize service programs efficiently to avoid unnecessarily activating an excess of procedures that the client program will not use. The procedures in a single service program should be closely related to each other, a concept known as cohesion. Usually, when you activate a service program, most of the procedures in it should be used.


When you first activate an ILE program or service program, by default, all the service programs bound by reference are also activated. Activation allocates and initializes the storage needed to execute the program or service program. You can choose to defer activation of a particular service program until the caller invokes one of the exported procedures in the service program (i.e., until it truly uses the service program). When you specify a service program in the binder's BNDSRVPGM parameter, or you list it in a binding directory, indicate *DEFER instead of *IMMED activation (Figures 15.1 and 15.2). Deferred activation can offer a small performance improvement if the program binds many service programs but uses some of them only infrequently in actual practice.


The DSPPGM (Display Program) CL command lists the modules and service programs that make up a program if you specify the parameter value DETAIL(*MODULE *SRVPGM). Figures 15.3 and 15.4 illustrate the DSPPGM output. Similarly, the DSPSRVPGM (Display Service Program) CL command shows the modules and service programs that a service program uses. RDi's Remote Systems Explorer also offers an application diagram to help visualize the program or service program construction (Figure 15.5).









Figure 15.5: RDi application diagrams

James Buck
Jim Buck's career in IT has spanned more than 35 years, primarily in the college education, manufacturing, and healthcare industries. Past president (13 years) of the Wisconsin Midrange Computer Professional Association, he has served on several teams developing IBM and COMMON certification tests. Jim has co-authored several IBM i textbooks with Bryan Meyers that are used by many companies and in colleges worldwide. Other accomplishments include: recipient of the 2007 IBM System i Innovation - Education Excellence Award, 2014 COMMON President's Award, and 2013/2016/2017 IBM Champion - Power Systems.

Jim is the president and founder of imPower Technologies, where he provides professional IBM i training and consulting services. He is active in the IBM i community, working to help companies train their employees in the latest IBM technologies and develop the next generation of IBM i professionals.

MC Press books written by Jim Buck available now on the MC Press Bookstore.

Control Language Programming for IBM i Control Language Programming for IBM i
Master the A-Z of CL, including features such as structured programming, file processing enhancements, and ILE.
List Price $79.95

Now On Sale

Mastering IBM i Mastering IBM i
Get the must-have guide to the tools and concepts needed to work with today's IBM i.
List Price $85.95

Now On Sale

Programming in ILE RPG Programming in ILE RPG
Get the definitive guide to the RPG programming language.
List Price $95.95

Now On Sale

Programming in RPG IV Programming in RPG IV
Understand the essentials of business programming using RPG IV.
List Price $79.95

Now On Sale



Support MC Press Online


Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: