Problem solve Get help with specific problems with your technologies, process and projects.

Understanding the ins and outs of activation groups -- Part II

Now that you know the basics of activations groups, let's turn our attention to the details: how to create/delete them, different types and more.

In the first installment, we discussed the basics of activation groups. Let us now turn our attention to the details, to understand how to create and delete them, the different types, and some strategies for using them effectively and efficiently.

How ILE activation groups are created and deleted

Currently, ILE activation groups can only be created implicitly. When you create an ILE program, you specify the activation group in which the program will run on the ACTGRP parameter. If, when the program is called, the activation group does not yet exist, it will be created automatically by the system. (Remember, the default activation group is created when the job is started.) It is important to keep in mind that an activation group is part of a job; it cannot be accessed by other jobs.

You have a bit more flexibility when it comes to deleting activation groups. As long as at least one program is activated in an activation group, that activation group will exist. An activated program is one that is either running or has returned to its caller without deactivating itself (e.g., returning from an RPG program without setting on the LR indicator). Under normal conditions, ILE activation groups remain in existence until you explicitly delete them (e.g., by using the RCLACTGRP command or calling the CEETREC API -- more on these in the next issue). Unhandled exceptions -- a.k.a. escape messages -- will also cause an ILE activation group to be deleted. That happens when the last program in the activation group does not handle the exception.

Ron Turull

There is an exception. *NEW activation groups are not so persistent. *NEW activation groups are deleted as soon as the last program (i.e., the first program called) in the activation group returns regardless of whether it deactivates itself. IBM's somewhat flawed logic for this is that, since the system generates the names for *NEW activation groups, you would not be able to re-use the activation group. Apparently the designers were unable (or were too pressed for time) to identify an activated program without knowing exactly which activation group it is activated in; however, they failed to realize that a program can easily return a procedure pointer pointing to itself through which a subsequent call could be made. Oh well.

ILE activation groups come in several flavors

You can name a named activation group anything you want. There are also a few special values for the ACTGRP parameter on the Create Program command (CRTPGM). Here's a summary of valid values for the ACTGRP parameter:

  • User-named activation group. Specify any name you want on the ACTGRP parameter. When the program is called the first time in a job, the system will create that activation group for the job. The activation group will persist after the program returns and will be reused if the same program is called again (or if any program that uses the that same activation group is called).
  • Caller's activation group. Specify *CALLER on the ACTGRP parameter. When the program is called, it will run in the same activation group in which the calling program is running. That means if the program is called by several different programs each running in a different activation group, the program will have several different activations.
  • New activation group. Specify *NEW on the ACTGRP parameter. Each and every time the program is called, the system will create a new activation group for it. As soon as the program returns, the activation group is destroyed. These types of activation groups do have names, but the names are system-generated and change every time. Be careful about using *NEW. Activation group creation is a costly process, laden with overhead.
  • QILE activation group. QILE is a special user-named activation group. It has the exact same characteristics as a regular user-named activation group; the name "QILE" is simply the default for ACTGRP parameter on the CRTBNDxxx commands (create bound program).

Service programs run in activation groups, too

This entire discussion applies to service programs as well. The only exception is that you cannot specify *NEW for the ACTGRP parameter on the Create Service Program command (CRTSRVPGM). That is because the idea of a service program is that it is supposed to be called from several different programs, and you don't want an activation group to be created every time you call it.

Activation group strategies

Someone just getting started in ILE and/or a shop that wants to convert their applications to ILE with as little pain as possible will do themselves a big favor by simply using the default activation group for all their programs. The tradeoff is this: You lose a little performance (ILE programs run a bit slower in the default activation group), but you all but eliminate any ILE issues you need to worry about (e.g., resource scoping, RCLRSC command, etc).

To boost your performance a bit and still minimize your ILE-related headaches, run all your programs in the same ILE activation group. A good one to choose is QILE, since it is the default for the ACTGRP parameter on all the CRTBNDxxx commands. Running all your programs in the same ILE activation group eliminates resource scoping issues, a common problem in ILE.

If you have a firm handle on ILE, then a good strategy is to use a separate user-named activation group for each "application group." For example, run all your accounts payable programs (i.e., the group of accounts payable applications) in an activation group called AP, run all inventory programs in an activation called INVENTORY, and so on.

Unless you have a good reason for it, do not use *CALLER for service programs. This somewhat defeats the purpose of a service program, although there are occasions that call for it. For the most part though, you will want to use user-named activation groups for service programs.

In the next issue, we'll look at the most common commands, APIs, and op-codes that affect activation groups.

About the author: Ron Turull is editor of Inside Version 5. He has more than 20 years experience programming for and managing AS/400-iSeries systems.

Dig Deeper on Performance