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.

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

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.

Stay tuned for Part 2, coming soon in an upcoming issue of MC RPG Developer. Can't wait?  You can pick up Dave Shirey's book, 21st Century RPG: /Free, ILE, and MVC, at the MC Press Bookstore Today!