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.

*NEW

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

“Name”

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.

*CALLER

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.

QILE

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.

RCLACTGRP

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.