In Part 1 we looked at activation group basics.  Part 2 at types.

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

So, How Should Activation Groups Be Used?

Oh, I know what you want.

You want me to tell you exactly how to use the activation groups. What to use and when. Yeah, that sounds like a win-win for me. It will be almost like being at home with my family. They love to get advice from me.

But, I suppose there are some things I could say.

First, let’s consider the two values *NEW and named.

We said before that the difference between them was that *NEW assigns the name automatically, and named leaves that assignment up to you. But there is one other difference, too.

If you use *NEW, then the activation group ends when the last program in that group ends. It polices its own existence very nicely. That is because IBM assigns the name and so feels a certain responsibility for it.

But if you use named, then you have to do a RCLACTGRP to get it to stop. You name it, you reclaim it. Oh, yeah.

What seems to be important here is: how often is the stinkin’ job going to run? If it runs once every time the moon occults Arcturus, (one of my favorite stars), then I would think that it makes sense to have this run under *NEW so that cleanup occurs automatically when it is done. Chances are it is not going to run twice in a day, so you don’t lose anything by using *NEW and letting the system name the activation group.

On the other hand, if it is going to run repeatedly all day, then it makes sense to have an activation group just sitting out there waiting for the program to show up. In this case, make it named. But just remember to do a RCLACTGRP at the end of the day or whenever this job is likely to be done.

What does matter is the use of the *CALLER activation group. Anytime you have a situation where you have one program calling others in a group and you want to share resources (including overrides), the first program should be either *NEW or named, and the others should be *CALLER. Which option you use (*NEW or named) will depend on how you feel about being the one who cleans up the activation groups.

And what about QILE?

While you could use it to run your programs, it is probably the worst option to use simply because everybody might be using it, and you could very easily end up in a reclaim situation or an override situation that is not in the best interests of your application. The smart money here is on *NEW/named and *CALLER.

As I said earlier, the cool kids do not recommend using QILE, but the truth is I have seen references that go both ways.

One source that I consulted thought QILE was fine even though it required the reclaim.

Another source thought it was the worst option, and the author became visibly agitated when it appeared someone was going to use it. So much for the experts.

If it matters, IBM does not recommend QILE, and instead suggests the use of named activation groups. IBM make a good point in that activation groups were designed to represent applications, and so using a generic one is not exactly what they had in mind. Although the way they have marketed the i is not exactly what I had in mind (I would consider using the blonde, British girl from the Viagra commercials as their spokesperson), so you can decide. Plus, there is a difference between IBM technical advice and marketing advice.

In the end, the general rule of thumb is to start the first program in a sequence (like the C of an MVC) in a *NEW or named activation group, depending on whether you want to do the cleanup or have it done for you and how likely it is that the job will be rerun (and so can take advantage of an activation group that is just sitting out there waiting).

And most things that are called from that first program should be *CALLER.

And Service Programs?

The exception to this is service programs. Remember, service programs can be potentially called from a large number of other programs. So if you have a service program that is called by many apps and you use *CALLER for it, it could result in a copy of it being in many different activation groups.

But by naming the activation group of the service program when it is called, that activation group could stay open and be available to those many calls. The connection to the calling programs is still intact, as that is set up through the EXPORT keyword and the binding language entries. You would have to remember, however, that if you did this, then the static and global variables of the service program are going to be available to other environments, something that could be either good or bad. Or a non-issue. Plus, of course, you would have to clean up after it yourself. You should never let the need to clean up determine your choice of activation group types. Just remember to not forget it. Setting up the RCLACTGRP in a CL program that runs automatically once a day or whatever is probably the best way.

Bottom Line

But most important of all, pay attention to what needs to be done, if anything, to end an activation group. Don’t just assume it will happen because as we have seen in some cases, it doesn’t. And also pay attention to your programs, and to setting INLR on if you want the activation group to end.

Yeah, that’s the bitch of ILE: it gives you flexibility, but it forces you to take ownership and make some decisions. Welcome to the new millennium. Glad I could help simplify things.

WRKJOB: Work with Job Command

Just a final note about this command, as you may have not thought about it.

With this command you can see the activation groups that are involved with your job. Specifically, option 11 shows you the programs in the job and the activation group they are running in. Option 18 then shows you a list of the activation groups involved.

Want to learn more?  You can pick up Dave Shirey's book, 21st Century RPG: /Free, ILE, and MVC, at the MC Press Bookstore Today!