Thu, Jun
3 New Articles

Service Program Compile Stuff

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

As you might guess, service programs are not a one-size-fits-all kind of thing, and where there is flexibility, there is often complexity. It’s not a lot, but there are a few additional things you should know in order to fully understand and set up your service programs for maximum efficiency.

Editor's Note: This article is excerpted from chapter 18 of 21st Century RPG: /Free, ILE, and MVC, by David Shirey.

So let’s take a look at what those things are before we go any further.


Let’s start by quickly reminding ourselves what binding is and how it fits into the ILE environment.

Binding is nothing new; it has been around for a long time. It is the process of relating two programs together (the calling and the called programs) so that when you access one from the other, much of the overhead is already taken care of and the whole “call” thing goes quicker.

Of course, you are not forced to do binding. BOPs (Big Ol’ Programs) do not worry about binding. You do everything in one program. There are no calls, no binding, no worries. There is also, probably, no way that you can reliably enhance or modify this thing after a few years go by.

But anytime you are calling one program from another, you are using binding. This, of course, is exactly what happens in a modular environment, and the basic thrust of ILE is in that direction. There are two flavors that this binding comes in: dynamic and static.

Dynamic sounds better, doesn’t it? Everything that is dynamic is better than something that is static. But that is not always true, and it happens that for us, static is better than dynamic.

Dynamic Binding

This happens when neither the calling nor the called program knows anything about the other. It’s like a big surprise birthday party.

That is, you don’t do any kind of pre-compile binding, you just compile each program separately, and then call one from the other. Suddenly, when the call occurs, the two programs become aware of each other and form a connection.  All of the overhead responsible for the “call” happens at this point, and so if this is a connection that happens many times while the app is running, it can become excessive and contribute to slow response time.

It is nice, because you don’t have to plan ahead for this. It’s also nice because since the bind happens when the programs run, we can modify them independently of each other. That is, I can change the called program and not have to redo the compile/bind of the calling program. But it’s bad because it can really slow things down if the connection happens repeatedly. Dynamic binding is old-school.

And how do you get dynamic binding? Remember? Just compile the calling and the called program separately. The call between the two will then function not knowing a thing about the other program.

Static Binding

Static binding is the opposite. It is planned and prepared for ahead of time, with much of the work being done at compile time.

In order to set up static binding, you need to follow a two-step process. You start by creating modules (*MODULE) for all the programs involved (CRTRPGMOD or PDM option 15), and then tie them together to form a program with CRTPGM where you list the modules involved.

The advantage here is that you get a lot of the overhead out of the way when you do the compile, and so you have a very fast connect.

The disadvantage is that you have to think ahead and take preemptive action. That’s harder for some folks than others. It’s also a problem because now, since we bound them together when we compiled them, if either program changes, we need to recreate the changed modules and rebind them together.

And how do you get static binding set up? Simple, just compile both the calling and the called programs as modules (CRTRPGMOD, PDM option 15), and then issue the CRTPGM command to tie the two together.

Now I want to be clear here. This is not ILE. This is the way it has always been. But in the ILE world, static binding is preferred over dynamic binding. I wish they had called it “good binding” and “bad binding”; it would be easier to remember then, but nobody asked me what I thought. Story of my life.

What Does This Have to Do with Service Programs?

Service programs make use of binding, but the situation is a bit more robust than the chocolate-vanilla situation just described.

To start with, let’s remember that a sub-procedure cannot exist on its own: it must be embedded in a service program or a regular program. And if it is in a regular program, you cannot call the sub-procedure by itself; you have to call that program as a whole and then somehow get into the sub-procedure. Only a service program can house a sub-procedure and let you call it separately from the rest of the sub-procedures in the service program. And only the service program uses the H-spec, NOMAIN, which removes the main cycle processing from that program.

In other words, service programs are a bit different from “normal” programs. And how they handle binding is a little different as well. To see this, let’s review how you create a service program block (the service program and the calling program).

You start by converting your service program source to a module.

Despite what you might think, this is a required step. Even if you choose all the defaults, you cannot create a service program unless that service program first exists as a *MODULE. Bottom line: you need to do this. Keep in mind, this is the “compile” per se, and so if you want to debug or anything, you need to specify it in the command or with an H-spec.

CRTRPGMOD MODULE('service program ID')

Then, you turn that module into a service program.


That is fairly simple, and we will talk later (chapter 21) about the difference between *SRCFILE and *ALL in the EXPORT parm. For the moment, let’s use *ALL even though that is not the default.

The next step is to convert the calling program to a module.

CRTRPGMOD MODULE('calling program ID')

This can be done before or after you do the CRTSRVPGM. What is important here is that before the next step you have a service program (the output of the CRTSRVPGM) and a program module for the calling program (the output of CRTRPGMOD for the calling program).

The final step is to then create the final, bound program that combines both the calling program and the service program.

I generally name this program the same as the calling program (since we have only created that as a module so far), but you don’t have to do it that way (you can name this program whatever you want).

Service Program Compile Stuff - Figure 1

Now, what is interesting is the last parm, BNDSRVPGM. It actually consists of three pieces.

The first is the name of the service program module that is being bound in.

The second is the library that this service program module lives in. Prior to 7.3, this had to be a physical file in a library. But with 7.3, it became possible to include a stream file as the source of the source.

The third is the one that is interesting because the available values are either *IMMED or *DEFER. And it is the choice here that makes all the difference in how your service program works.

If you specify *IMMED, then the two programs (your calling program and your service program) are bound together at the time that the compile is done. This is static binding in that now your calling program and service program modules are bound together, and if you change the service program, you are going to have to not only recreate the service program but do the CRTPGM command again to bring in the new source for the changed service program. But it is really fast.

If you specify *DEFER, then the bind is delayed until you call that service program from the calling program. This is not quite as efficient because that overhead work gets done when you do the call, but it also means that since the service program source is not bound in at compile time, I can change the service program and not have to create the calling program all over again. If the service program you have changed is used by a large number of calling programs, this can save you a great deal of time.

It is not obvious from the command, but the default if not entered is *DEFER.

Which one should you choose? It depends on what you want. Do you have a service program that is used by a large number of other programs and which may be likely to change? Then using *DEFER is probably a good option. If, however, you don’t think the service program is likely to change and/or it is not called from that many places and you’d like to reap the extra efficiency, then *IMMED might be a better choice.

One final thing I should mention is that you might very well have multiple service programs bound to a single calling program (for example, if the calling program calls multiple sub-procedures from multiple service programs). This can be handled quite simply because you can enter multiple BNDSRVPGM parm sets. It is also a good time to bring in binding directories, which we will discuss in the next chapter.

What Happens When You Call a Service Program?

OK, we now have a handle on binding service programs and what some of the pros and cons might be in using them.

In a few minutes, we will look at some of the types of problems, er I mean situations that you can run into when working with service programs.

But before we do that, I want to take a closer look at exactly what happens when a program calls a sub-procedure in a service program.

We know from chapter 10 that the call occurs when we issue a CALLP with the object being the name of the sub-procedure that we want to access. There is no information in that call about the name of the service program that contains that sub-procedure, so how does the system find it?

That should be an easy-to-answer question because we saw a page or two ago that when we do the CRTPGM and bind the calling and service programs together, we actually specify the service program name(s).

So now we have two pieces of information: the sub-procedure name from the CALLP (or rather, actually from the PR D-spec EXTPGM parm), and the service program name(s) from the CRTPGM command (either via the BNDSRVPGM or the BNDDIR parm).

The logical thing to think at this point is that the i starts with the first service program listed in the CRTPGM and begins searching through till it finds a sub-procedure whose name matches the one from the calling program’s PR D-spec. But life is rarely as simple as we envision it.

The i does indeed search, but it does not go through the service programs. Instead, it searches through a list that is associated with the service program. Where does this list come from? Hang on. For the moment, just know that it looks through the “list,” finds an entry that matches the sub-procedure name from the calling program PR D-spec, and then notices what sequential number that sub- procedure name is in the list. Let’s say it is the third one down.

The i then goes out to the service program already identified and finds the sub-procedure with the same sequence number, in this case the third one in the service program, and with complete disregard for what the name of this sub-procedure might actually be, executes it because the position in the service program matches the position in the list.

One thing you might be wondering about here is where in the service program does the system look? Does it look at the list of PRs or at the actual procedures in the program? Normally these will be in the same order, but not necessarily. As it turns out, the system goes through the actual source of the program and ignores the PRs in trying to determine which sub-procedure is called.

The other thing you might be wondering is: why does IBM do this? Why do they look at a list and then use a relative position in that list rather than just looking for the sub-procedure in the service program? And the answer is, efficiency. It is much faster to look in a short list, then determine the relative position in that list (like the index of an array), and then find that position in a service program than it is to search through a service program looking for a name match. This makes sense, but it does leave some room for problems if you are not careful. More on that later.

Anyway, the next question is: where does the list come from? Well, if you compile your service program (CRTSRVPGM) with the EXPORT (Export Source Member) keyword set to *SRCFILE, then the system will look for a binding language source member to use as that list. If one does not exist, there will be a compile error. The spot where this source file is located is then given by the SRCFILE and SRCMBR keywords. We will talk about binding language in chapter 20, but for now just know that you have to set up your binding language source file before you compile your service program, if you are using it.

But if you set EXPORT to *ALL, then the system will, during the compile, look at the service program and create its own behind-the-scenes list that shows the order of the sub-procedures in that service program.

And this is the list, whether created by you via binding language (see chapter 20) or auto-created by the system, that will be used to find the position of a sub-procedure in that service program. It does not throw this list out into a source file so that you can see it, but it creates an object list just the same.

And don’t worry about the binding language references above. We will cover that in chapter 20.

What Can Go Wrong

Of course, any time you have a lot of flexibility and options, things can go wrong. I suppose that is not the best way to sell service programs, but sometimes bad things happen to good things.

So what do you need to watch out for in terms of service programs?

Calling the Wrong Sub-Procedure

Yes, it may be hard to believe, but you can actually call the wrong sub-procedure in a service program. That is, you might have sub-procedures A and B in the service program, and you mean to call A, but you end up kicking off B instead.

The primary reason for this is because of the “finding things by relative list position” thing. If we picked them up by name instead of their spot on a list, this wouldn’t occur. But we don’t, and so it can.

The good news is that it only happens in a very specific circumstance, and there are a number of things you can do to minimize the chances of this ever happening. We’ll discuss this in detail in chapter 20.

Signature Violations

The second thing is what is known as a signature violation. I won’t go into all the details here. See chapter 21 for the whole ugly story. We will just say that the service program signature is similar to a level check except that it is quite a bit different. But you’ll see when we get there.

Other than that, it’s pretty bulletproof. And very handy, so don’t decide you don’t want to do service programs because you might have one of the two problems mentioned earlier. That would be very short-sighted indeed.

What Ya Shoulda Learned

The main emphasis here is on binding.

We start with the classic definitions of static and dynamic binding and look at how they relate to even OPM programs.

The next step takes us back through the compile process for a service program and its calling program because they are treated a little differently from regular programs.

As part of this compile review, we saw that we have a number of parms in the compile commands that exert a great effect on the objects. Specifically, we have *SRCFILE and *ALL on the EXPORT parm of the CRTSRVPGM, which we will talk about in chapter 20, and the *DEFER and *IMMED values on the BNDSRVPGM parm of the CRTPGM command.

We talked about the *DEFER and *IMMED values here and saw that using *IMMED causes the calling program and service program to be bound at compile time the way a normal bind works. *DEFER, on the other hand, doesn’t actually bind until the run occurs. Both methods have their pros and cons, and you should be able to describe what those benefits/weaknesses are. Can you?

We then went on with a blow-by-blow description of the sequence of events when a program calls a sub-procedure in a service program.

Finally, we named the two things that can happen to cause problems when you are accessing a service program. Can you tell me what those two problems are? We promised more details on them in a subsequent chapter.

And that’s about it. But time wanes, and we must move on. There are two things that you keep running into when you talk about service programs: binding directories and binding language. Let’s dive into them next and see what all the fuss is about.


David Shirey

David Shirey is president of Shirey Consulting Services, providing technical and business consulting services for the IBM i world. Among the services provided are IBM i technical support, including application design and programming services, ERP installation and support, and EDI setup and maintenance. With experience in a wide range of industries (food and beverage to electronics to hard manufacturing to drugs--the legal kind--to medical devices to fulfillment houses) and a wide range of business sizes served (from very large, like Fresh Express, to much smaller, like Labconco), SCS has the knowledge and experience to assist with your technical or business issues. You may contact Dave by email at This email address is being protected from spambots. You need JavaScript enabled to view it. or by phone at (616) 304-2466.

MC Press books written by David Shirey available now on the MC Press Bookstore.

21st Century RPG: /Free, ILE, and MVC 21st Century RPG: /Free, ILE, and MVC
Boost your productivity, modernize your applications, and upgrade your skills with these powerful coding methods.
List Price $69.95

Now On Sale



Support MC Press Online

$0.00 Raised:

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: