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

More Articles By This Author
Related Articles


Support MC Press Online





  • White Paper: Node.js for Enterprise IBM i Modernization

    SB Profound WP 5539

    If your business is thinking about modernizing your legacy IBM i (also known as AS/400 or iSeries) applications, you will want to read this white paper first!

    Download this paper and learn how Node.js can ensure that you:
    - Modernize on-time and budget - no more lengthy, costly, disruptive app rewrites!
    - Retain your IBM i systems of record
    - Find and hire new development talent
    - Integrate new Node.js applications with your existing RPG, Java, .Net, and PHP apps
    - Extend your IBM i capabilties to include Watson API, Cloud, and Internet of Things

    Read Node.js for Enterprise IBM i Modernization Now!


  • Profound Logic Solution Guide

    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 companyare not aligned with the current IT environment.

    Get your copy of this important guide today!


  • 2022 IBM i Marketplace Survey Results

    Fortra2022 marks the eighth edition of the IBM i Marketplace Survey Results. Each year, Fortra captures data on how businesses use the IBM i platform and the IT and cybersecurity initiatives it supports.

    Over the years, this survey has become a true industry benchmark, revealing to readers the trends that are shaping and driving the market and providing insight into what the future may bring for this technology.

  • Brunswick bowls a perfect 300 with LANSA!

    FortraBrunswick is the leader in bowling products, services, and industry expertise for the development and renovation of new and existing bowling centers and mixed-use recreation facilities across the entertainment industry. However, the lifeblood of Brunswick’s capital equipment business was running on a 15-year-old software application written in Visual Basic 6 (VB6) with a SQL Server back-end. The application was at the end of its life and needed to be replaced.
    With the help of Visual LANSA, they found an easy-to-use, long-term platform that enabled their team to collaborate, innovate, and integrate with existing systems and databases within a single platform.
    Read the case study to learn how they achieved success and increased the speed of development by 30% with Visual LANSA.


  • Progressive Web Apps: Create a Universal Experience Across All Devices

    LANSAProgressive Web Apps allow you to reach anyone, anywhere, and on any device with a single unified codebase. This means that your applications—regardless of browser, device, or platform—instantly become more reliable and consistent. They are the present and future of application development, and more and more businesses are catching on.
    Download this whitepaper and learn:

    • How PWAs support fast application development and streamline DevOps
    • How to give your business a competitive edge using PWAs
    • What makes progressive web apps so versatile, both online and offline



  • The Power of Coding in a Low-Code Solution

    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:

    • Discover the benefits of Low-code's quick application creation
    • Understand the differences in model-based and language-based Low-Code platforms
    • Explore the strengths of LANSA's Low-Code Solution to Low-Code’s biggest drawbacks



  • Why Migrate When You Can Modernize?

    LANSABusiness 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.
    In this white paper, you’ll learn how to think of these issues as opportunities rather than problems. We’ll explore motivations to migrate or modernize, their risks and considerations you should be aware of before embarking on a (migration or modernization) project.
    Lastly, we’ll discuss how modernizing IBM i applications with optimized business workflows, integration with other technologies and new mobile and web user interfaces will enable IT – and the business – to experience time-added value and much more.


  • UPDATED: Developer Kit: Making a Business Case for Modernization and Beyond

    Profound Logic Software, Inc.Having trouble getting management approval for modernization projects? The problem may be you're not speaking enough "business" to them.

    This Developer Kit provides you study-backed data and a ready-to-use business case template to help get your very next development project approved!

  • What to Do When Your AS/400 Talent Retires

    FortraIT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators is small.

    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:

    • Why IBM i skills depletion is a top concern
    • How leading organizations are coping
    • Where automation will make the biggest impact


  • Node.js on IBM i Webinar Series Pt. 2: Setting Up Your Development Tools

    Profound Logic Software, Inc.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. In Part 2, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Attend this webinar to learn:

    • Different tools to develop Node.js applications on IBM i
    • Debugging Node.js
    • The basics of Git and tools to help those new to it
    • Using as a pre-built development environment



  • Expert Tips for IBM i Security: Beyond the Basics

    SB PowerTech WC GenericIn this session, IBM i security expert Robin Tatam provides a quick recap of IBM i security basics and guides you through some advanced cybersecurity techniques that can help you take data protection to the next level. Robin will cover:

    • Reducing the risk posed by special authorities
    • Establishing object-level security
    • Overseeing user actions and data access

    Don't miss this chance to take your knowledge of IBM i security beyond the basics.



  • 5 IBM i Security Quick Wins

    SB PowerTech WC GenericIn today’s threat landscape, upper management is laser-focused on cybersecurity. You need to make progress in securing your systems—and make it fast.
    There’s no shortage of actions you could take, but what tactics will actually deliver the results you need? And how can you find a security strategy that fits your budget and time constraints?
    Join top IBM i security expert Robin Tatam as he outlines the five fastest and most impactful changes you can make to strengthen IBM i security this year.
    Your system didn’t become unsecure overnight and you won’t be able to turn it around overnight either. But quick wins are possible with IBM i security, and Robin Tatam will show you how to achieve them.

  • Security Bulletin: Malware Infection Discovered on IBM i Server!

    SB PowerTech WC GenericMalicious programs can bring entire businesses to their knees—and IBM i shops are not immune. It’s critical to grasp the true impact malware can have on IBM i and the network that connects to it. Attend this webinar to gain a thorough understanding of the relationships between:

    • Viruses, native objects, and the integrated file system (IFS)
    • Power Systems and Windows-based viruses and malware
    • PC-based anti-virus scanning versus native IBM i scanning

    There are a number of ways you can minimize your exposure to viruses. IBM i security expert Sandi Moore explains the facts, including how to ensure you're fully protected and compliant with regulations such as PCI.



  • Encryption on IBM i Simplified

    SB PowerTech WC GenericDB2 Field Procedures (FieldProcs) were introduced in IBM i 7.1 and have greatly simplified encryption, often without requiring any application changes. Now you can quickly encrypt sensitive data on the IBM i including PII, PCI, PHI data in your physical files and tables.
    Watch this webinar to learn how you can quickly implement encryption on the IBM i. During the webinar, security expert Robin Tatam will show you how to:

    • Use Field Procedures to automate encryption and decryption
    • Restrict and mask field level access by user or group
    • Meet compliance requirements with effective key management and audit trails


  • Lessons Learned from IBM i Cyber Attacks

    SB PowerTech WC GenericDespite the many options IBM has provided to protect your systems and data, many organizations still struggle to apply appropriate security controls.
    In this webinar, you'll get insight into how the criminals accessed these systems, the fallout from these attacks, and how the incidents could have been avoided by following security best practices.

    • Learn which security gaps cyber criminals love most
    • Find out how other IBM i organizations have fallen victim
    • Get the details on policies and processes you can implement to protect your organization, even when staff works from home

    You will learn the steps you can take to avoid the mistakes made in these examples, as well as other inadequate and misconfigured settings that put businesses at risk.



  • The Power of Coding in a Low-Code Solution

    SB PowerTech WC GenericWhen 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:

    • Discover the benefits of Low-code's quick application creation
    • Understand the differences in model-based and language-based Low-Code platforms
    • Explore the strengths of LANSA's Low-Code Solution to Low-Code’s biggest drawbacks



  • Node Webinar Series Pt. 1: The World of Node.js on IBM i

    SB Profound WC GenericHave 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.
    Part 1 will teach you what Node.js is, why it's a great option for IBM i shops, and how to take advantage of the ecosystem surrounding Node.
    In addition to background information, our Director of Product Development Scott Klement will demonstrate applications that take advantage of the Node Package Manager (npm).
    Watch Now.

  • The Biggest Mistakes in IBM i Security

    SB Profound WC Generic The Biggest Mistakes in IBM i Security
    Here’s the harsh reality: cybersecurity pros have to get their jobs right every single day, while an attacker only has to succeed once to do incredible damage.
    Whether that’s thousands of exposed records, millions of dollars in fines and legal fees, or diminished share value, it’s easy to judge organizations that fall victim. IBM i enjoys an enviable reputation for security, but no system is impervious to mistakes.
    Join this webinar to learn about the biggest errors made when securing a Power Systems server.
    This knowledge is critical for ensuring integrity of your application data and preventing you from becoming the next Equifax. It’s also essential for complying with all formal regulations, including SOX, PCI, GDPR, and HIPAA
    Watch Now.

  • Comply in 5! Well, actually UNDER 5 minutes!!

    SB CYBRA PPL 5382

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

    Request your trial now!

  • Backup and Recovery on IBM i: Your Strategy for the Unexpected

    FortraRobot automates the routine 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:
    - Simplified backup procedures
    - Easy data encryption
    - Save media management
    - Guided restoration
    - Seamless product integration
    Make sure your data survives when catastrophe hits. Try the Robot Backup and Recovery Solution FREE for 30 days.

  • Manage IBM i Messages by Exception with Robot

    SB HelpSystems SC 5413Managing messages on your IBM i can be more than a full-time job if you have to do it manually. 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:
    - Automated message management
    - Tailored notifications and automatic escalation
    - System-wide control of your IBM i partitions
    - Two-way system notifications from your mobile device
    - Seamless product integration
    Try the Robot Message Management Solution FREE for 30 days.

  • Easiest Way to Save Money? Stop Printing IBM i Reports

    FortraRobot 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:

    - Automated report distribution
    - View online without delay
    - Browser interface to make notes
    - Custom retention capabilities
    - Seamless product integration
    Rerun another report? Never again. Try the Robot Report Management Solution FREE for 30 days.

  • Hassle-Free IBM i Operations around the Clock

    SB HelpSystems SC 5413For over 30 years, Robot has been a leader in systems management for IBM i.
    Manage your job schedule with the Robot Job Scheduling Solution. Key features include:
    - Automated batch, interactive, and cross-platform scheduling
    - Event-driven dependency processing
    - Centralized monitoring and reporting
    - Audit log and ready-to-use reports
    - Seamless product integration
    Scale your software, not your staff. Try the Robot Job Scheduling Solution FREE for 30 days.