Introduction to ILE RPG Activation Groups

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

Learn how activation groups can help your ILE RPG programs run more efficiently, how to specify the type of group to use, and closing and reclaiming activation groups

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

Several times so far, we have mentioned that one of the reasons for going to ILE is to have more control over the application and how it runs. And nothing exemplifies this more than the use of activation groups.

The activation group is nothing more than a sub-environment in which an application runs. It defines a set of resources that support a program app. Things that run in the same activation group share the same resources (e.g., files that are open, overrides).

You can also look at the activation group as a process that occurs when you kick off a program. This process sets up the environment, opens files, opens SQL cursors, defines static variables, and binds service program modules to applications associated with the activation group.

Basic Activation Group Facts

In the OPM world, every program that is invoked runs in its own little environment. If it needs a file, or an override, the program has to open that on its own. Plus, if the same program runs and finishes and then runs again later, that is two times that the run environment has to be set up. Can you spell “overhead”?

ILE programs use activation groups as their run environment, and every ILE program must have an activation group (environment) to run in. What separates ILE from OPM is the ability of ILE programs to share activation groups and to keep an activation group open even though a program ends, so that it can be used over again if that program restarts.

That is, the goal of ILE activation groups is twofold. First, to minimize the amount of time and resources spent creating and destroying run environments. Or at least to give you the control to make intelligent decisions about when that happens.

Second, to run related programs together in the same activation group (keep thinking “environment”), like BFFs, sharing resources and stuff like some sort of ’60s hippie commune. Except for the sex and drugs part. And that is both good and bad (the sharing part, not the sex and drugs; RPG programmers don’t go for that kind of stuff).

The good part is that sharing is good. Whether it is file opens, overrides, storage space, whatever, it helps the system be more productive overall.

And how could that be bad? Seriously, dude. Is there anything that we can develop that someone can’t screw up?

Even though OPM was not very imaginative, it was consistent. A program started, an environment was created. A program ended, an environment was deleted.

But things are not always so simple with ILE. Initially that flexibility gave ILE kind of a bad name with some folks. The activation group gives you more control, which means it also gives you more opportunities to screw yourself over. Below, we will talk about several types of activation groups. Not all of them just go away automatically when the program ends, so be sure to pay attention to that because if you chose those alternatives (and you very well might for good reasons), then you will have to clear off those environments periodically.

And that’s the bad news: you will actually have to think about what you are doing and the relationships between your modules, so that you do not create a bunch of unnecessary activation groups that linger after the original program is done.

The other thing that activation groups do is draw boundaries. If we think of file overrides or file cursor settings (SQL cursors, that is), then if there are multiple programs using the same override or cursor, we could actually have one program changing a cursor that is being used in others. By using named activation groups for each of these applications, we are able to set a boundary between the two apps and keep them from hurting each other.

In some ways, this is a slight shift in the way we think about resources. In OPM, the resources seem to be associated with the program. Programs have open files, and so on. But with ILE, the resources clearly belong to the activation group. Programs can come and go and depending on how things are defined; the activation group, and the resources associated with it, can keep on keeping on.

Activation groups may sound intimidating, but they really aren’t all that bad. Let’s take a look at them.

Default Activation Group Parm (DFTACTGRP)

The starting point for activation groups is the *DFTACTGRP parm on the compile commands. We have already talked about this, but a review is always nice.

If you are in a pure OPM environment (using RPG object-type source modules, QRPGSRC source files, and CRTRPGPGM), then you will not find this parameter on the compile command. OPM doesn’t give you the option; it doesn’t use activation groups, and “that’s the fact, Jack.”

ILE uses them, but it does not force you to use a complex activation group. So, if you are using an RPGLE object type, and the CRTBNDRPG command, you will see the DFTACTGRP parm. There are two potential values for this command.

If you specify *YES, that is bad, because that means you are using the default activation group, which is what OPM uses, so there is no chance of you sharing resources or doing other stuff. In essence, you have an “ILE” program that operates just like an OPM program. A lot of people are doing this (especially if they are on an older release of the system) and don’t even realize it. They probably think they are doing ILE because they have RPGLE modules. But if you say *YES to this parm, you are totally doing OPM.

If, on the other hand, you say *NO, then you are saying you don’t want to use the default activation group—that is, you want to use a real activation group, and so you are going to have a program that is true ILE. And that is what we want you to do.

It is fair at this point to wonder why IBM set this up backwards. I mean, they want you to use ILE. And normally if you want to use something, you answer in the affirmative. But they set this up so that you had to say *NO to get the ILE stuff. But I want you to think about this for a moment. This is IBM, the people who have had 20 years to turn the 400/IBM i into the default operating system for the known universe. ’Nough said.

Activation Group Types

If you set the DFTACTGRP parm to *NO (I want to be ILE), then another parm will miraculously appear on the compile command: the ACTGRP parm, which lets you set the type/name of the activation group that will be associated with this program. That is, this is where you tell the compile what activation group the program will run in and will be started (unless it already exists) when the program is kicked off. Let’s take some time and carefully go through each option.

Just so you know, one of the most important things to notice about each group is how it is ended. With OPM, the environment died when the program did (INLR on), but ILE is not that clear-cut because it wants to give you more control over what happens. In other words, ILE trusts you to make the right decision for your app. Oh, that’s so sweet. And yet, sad, oh so sad.


If *NEW is specified, then a new activation group will be created for this program when it is run. The name of that activation group will be assigned by the system and will be something weird and freaky.

As a result, if two people call the same program with a *NEW activation group, two differently named activation groups will be started.

If you specify *NEW on every compile, then every program will run in its own activation group and you will have essentially an OPM system. That is probably not what you want, but there are definitely times when *NEW is the right option.

On the positive side, this type of activation group is automatically ended when the program associated with this group ends. Thus, the cleanup is automatic and timely.

On the negative side, if you use *NEW for every program, then you will end up with a ton of activation groups that do not share, and you will be no farther along than if you were OPM.

*NEW is not available for service programs. Because they are always called from somewhere else and so, are not really “new.”


If a name is entered, one that you have made up, then this name will be used on the activation group. It is basically the same as *NEW except that you are specifying the name rather than letting the system do it, so it might be more intuitive to you. Or it may just be one more thing you have to think about.

Like *NEW, if you specify a specific name on every compile, then you will have essentially an OPM configuration.

The difference is in the end. Named activation groups will persist even after the program has ended. The theory is that if a program whose compile was pointed at this activation group starts up again, it can then grab that activation group and save the overhead of starting one up, so it makes sense if a program ends and restarts pretty regularly. The only way to get rid of one of these is to run a RCLACTGRP (Reclaim Activation Group) command. If you use this for a program that is used frequently, you might want to set up the RCLACTGRP for that name as part of the daily or weekly process. You really probably don’t want it to live forever.

One additional characteristic of the named activation group is that any global variables you are using in that program will also be visible (that is, usable) by programs in other named activation groups.

Whether you think “hey, that is something handy” or “good grief, why did they allow that?” is up to you and says a lot about your personality. It could be either good or bad; just be aware that it can happen. Of course, if you have perfect ILE modules, you shouldn’t have any global variables.


In this case, the program compiled with this will use the activation group of the program that calls it.

Obviously, it makes no sense for *CALLER to be used on the first program in a sequence, but after that it makes lots of sense.

You will find that *CALLER is one of the more popular activation groups that you will use. If you are calling a series of programs in sequence, you might as well run all those programs together, you know, sharing resources and making like you are all friends and everything.

And since it does not really create its own activation group but just gloms you on to an existing one (either a *NEW or named), you don’t have to worry about ending it.

But *CALLER should only be used if the program you want to run was called by another program that set up an activation group first. If *CALLER is the first program in the sequence, then the program involved will end up running in the default activation group—something you don’t want.

And be careful with *CALLER with service programs. The idea of a service program is that it is called from a number of other programs (hopefully a large number), and the result of setting it up as *CALLER is to get a number of versions of it running in different activation groups, which wastes space and resources. You might be better off to set up your service programs to run in a single, named activation group even though you would have to run a RCLACTGRP regularly. It’s something to think about.


This is not the default activation group. The default activation group does not really have a name, it just sort of always exists, and in ILE we do not want to use it.

QILE is simply a name that IBM has assigned (hence the “Q”) to a named activation group, so that if you do not specify a name or *NEW or *CALLER, the program will fall back onto the QILE named activation group. In most compile commands, it is the default value assigned to the ACTGRP parm.

Using QILE still makes the program ILE (that is, determined via the DFTACTGRP parm being *NO, not based on the value in the ACTGRP parm). When a QILE group ends, you must use RCLACTGRP to do the reclaim (because it is really a “named” activation group). It won’t happen on its own as with *NEW.

Generally, using QILE is frowned upon by the cool kids. The main problem is that it is not very discriminating. That is, you might be using it, but it is also possible that some third-party software you are running might be using it, too. Now if you do a RCLACTGRP on QILE (after all, it is a named activation group) to recover your resources, you will also affect other applications that you might not want to have messed with.

The most important thing I want to remind you of is that you do not specify the activation group you want to use when you run the program. You assign it when you do your compile, so it will be the same every time the program runs until you recompile again. Don’t get confused by that.

What Happens When an Activation Group Closes?

So, we have some activation groups where the group goes away when the last program in that group sequence ends, and some activation groups which will live until you use the RCLACTGRP command. In addition, an activation group will go away if every program in that group fails.

But what actually happens when an activation group closes (because what happens will have a direct bearing on how we use them)?

  1. First, any files that are being used in the activation group will be closed.
  2. Second, any file overrides associated with those files will also disappear.
  3. Third, storage (both static and allocated) being tied up by that function will be cleared.
  4. Fourth, commitment control will end. That is, database changes will be committed if you are under commitment control (otherwise the changes will take place as they happen).

I don’t know about you, but all this is very exciting for me. But then I’m a real thrill seeker.


This is the command you will need to use to reclaim an activation group that does not end on its own.

As we said earlier, any activation group created with a user-defined name (“named”) or by using QILE will need to be deactivated manually by the RCLACTGRP command. It will not happen automatically.

This is a very simple command, just the name of the activation group you want to reclaim, plus an option for *NORMAL and *ABNORMAL.

*NORMAL does things in a civilized manner: committing any pending changes and sending a polite close notification message to any attached host systems.

*ABNORMAL just gets you the heck out of Dodge, and if someone gets hurt in the process, that’s their problem. It rolls back any uncommitted changes and sends a rather nasty and abrupt message to any attached host systems.

The command should only be used when the activation group is not in use.

There is an option for the activation group name to use, *ELIGIBLE, in which case the command will close all activation groups not currently running a job. Using this is not a good idea and should be avoided as it can result in your closing groups that you did not mean to (and which you have no control over, such as third-party groups).

As a parting shot, if you are used to using RCLRSC, stop it. Just stop it right now! It doesn’t work well in the ILE world, and you should be reclaiming resources by controlling your activation groups.

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.