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

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

Activation groups can be an administrator's nightmare. A poorly designed app can spawn dozens of groups, end normally and leave all the groups open, locking up precious resources.

When you break it down, the Integrated Language Environment (ILE) is nothing more than a new program run-time environment, a new model for how the system executes programs. The compilers made for ILE (C, CL, COBOL and RPG) create programs that will execute in this new run-time environment, but the compilers themselves are not technically part of ILE. It you were forced to embody ILE in a system object, that object would most certainly be the activation group.

Activation groups are an AS/400 programmer's dream come true. Activation groups provide programmers with tremendous application design flexibility. As designed, an ILE program could not run without activation groups. An activation group's sole purpose is to help run ILE programs. They are truly the foundation of ILE and it is, therefore, very important to thoroughly understand what these things do and to know how to control them before tackling any major ILE development.

Ron Turull

Activation groups can also be an administrator's worst nightmare. An improperly designed application can spawn dozens of activation groups, end normally, and leave all those activation groups open, locking up precious resources. Multiply that scenario by hundreds of users and you have the makings of an administrator's headache.

Activation group: A definition

If you are familiar with the function of a job's process access group (PAG), you are already familiar with at least the basic function of an activation group. An activation group is a chunk of system memory and other resources dedicated to a specific job for the purpose of executing programs. It is a substructure of the job to which it is assigned and contains the following resources:

  • Memory for static and automatic program variables. Static variables retain their values and memory locations from one call to the next. Automatic variables lose both their values and memory locations when the procedure that contains them ends; if the procedure is called again, its automatic variables are assigned new memory locations and are initialized anew. Support for automatic variables in RPG procedures was implemented in V3R2.
  • Memory for dynamic storage. Dynamic memory gives you the ability to dynamically create, delete and change the size of "variables." For instance, say you need to use an array in a program, but you cannot predict the number of elements you will need. Dynamic memory lets you allocate space for the array (essentially determine the number of elements) at run-time. If, while the program is executing, you need more elements, no problem -- simply reallocate (i.e., change the size of) the memory, while leaving intact any existing data already in the array. Dynamic memory is new to many AS/400 programmers, but it has always been available on the AS/400 to C and MI programmers.
  • Temporary data management resources. These are temporary objects created by the data management subsystem on behalf of a program. For example, when you open a file, data management creates an open data path (ODP) "object" that "links" the file to the program. Other things that rely on data management resources include commitment control definitions, local SQL cursors, hierarchical file systems, user interface manager (UIM), query management (QM) and communication links such as CPI-C connections.
  • Resources needed for exception handlers and other exit points. These give you the ability to add a tremendous amount of flexibility to your applications. You can create a standard exception handler and attach it to all your activation groups. You can also attach an exit program to an activation group that will be called automatically before the activation group "ends."

All those resources are kept separate for each activation group, allowing you to isolate applications in activation groups. When an activation group is deleted, all its resources are freed up and returned to the system.

Two types of activation groups

There are two basic types of activation groups, ILE and non-ILE (the latter is called the default activation group).

  1. Default activation group (non-ILE activation group). Every job has a default activation group. It is automatically created when the job starts and destroyed when the job ends. You cannot manually create or destroy the default activation group. Its main purpose is to run non-ILE (i.e., OPM) programs, although you can, with some limitations, have ILE programs run in the default activation group as well. It is the only activation group that can run non-ILE programs.
  2. ILE activation group. You create ILE activation groups and are responsible for deleting them (although the system will delete all of a job's activation groups automatically when the job ends). ILE activation groups come in several flavors, which we'll discuss in Part II.

In the next installment, we discuss how to control activation groups, the different types of activation groups, and some strategies for using them effectively and efficiently.

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.


  • .ODt2a1K9u6U.0@.ee84636/171>How do you use activation groups?
    One member said activation groups seem like a nice feature but that they require more effort than they're worth. How can they be used, he wondered. A few other users described what they use them for and pointed out their benefits.
  • The trouble with Reclaim Resources
    It isn't uncommon for an application to execute the Reclaim Resources command (RCLRSC) periodically as a "garbage-collecting" device to improve performance. And programs sometimes rely on the command to free static memory, close open files and free other resources. But watch out if you need to have the program start fresh and execute a RCLRSC in the calling program before calling the RPG program. The RCLRSC command will not work if you convert the whole thing to ILE and tell it to run in an activation group other the default.
  • Ten important things to remember about heaps
    Memory for dynamic variables is allocated off an internal structure called the "heap." The heap is simply a chunk of memory that the system allocates for an activation group when the activation group is created. The Alloc, Dealloc, and Realloc op-codes are pretty straight-forward once you understand a few things about heaps.

Dig Deeper on Implementation