Ü Activation group

·         Activation group is a resource container within a job where the container holds a bunch of activations.

·         Activation is a reference to the storage allocation and runtime program binding activities that the operating systems perform when a program executes.

·         As designed, an ILE program could not run without activation groups. An activation group's sole purpose is to help run ILE programs.

The activities performed by the activation group are:

·         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

·         Memory for dynamic storage: Dynamic memory gives you the ability to dynamically create, delete and change the size of "variables." E.g. an array in a program

·         Temporary data management resources: ODP

·      Resources needed for exception handlers and other exit points: exit program to an activation group that will be called automatically before the activation group "ends."

Ü  Two types of activation groups

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. It is the only activation group that can run non-ILE programs.

·          If you try to create a program with DFTACTGRP (*YES), that program can't use any ILE features: no procedures (not even internal), no service programs, no binding directories. This sort of program is considered OPM even if it is written in RPG IV.

·         As a result, you frequently see examples that include an H-spec of DFTACTGRP (*NO) for ILE.

·         I mentioned earlier that ILE programs can run in the DAG. You do so by specifying *CALLER, then executing the program directly from a command line or calling it from an OPM program. Since you are in the DAG when you do so, the program executes within the DAG. This is generally considered a poor practice, for several reasons.

§  First, it defeats the purpose of having activation groups by lumping all resources together into a single group.

§  Second, it unnecessarily clutters up the DAG: Remember that the DAG's main job is to run operating system code,

2.  ILE activation group. ILE activation groups come in several flavors as shown below:

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

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

                                         The default for CRTSRVPGM is *CALLER. Any program or service program invoked with *CALLER will run inside the activation group of the calling program or procedure. This can really improve performance in your applications, because it removes the overhead of creating the activation group.

·         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. The activation groups names are system-generated and change every time.

·         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).

¤ Activation group scenario example

·         CLP has a OVRDBF command and calls a RPGLE program

·         RPGLE program performs a read operation and the pointer is now in the second program and now call the program 3

·         RPGLE program that also do a read operation which will read the second record

·         Since the pointer is in the second position and then return to 2nd   program in the above situation when the control transfer from 3rd record since the 2nd record is already read in program 3. But we need to need the 2nd record according to the logic but this is not possible in any OPM programs. But in RPGLE there is a solution for this problem by giving a common activation group for 1st and 2nd program and have a separate activation group for the 3rd program while creating the program itself and this will avoid the entire problem we faced before.

ü  In some situation we want to share between 2 program then we can give the activation group in *job level in which the changes in one program will be affected in another program.

¤ To have CL and RPG run in the same activation group

1. Have both the CL and RPG run in the same named activation group

2. Have the CL run in a named activation group, and have the RPG run in the same activation group as its caller (*CALLER)

3. Have the CL run in a new activation group every time it is called (*NEW), and have the RPG run in *CALLER

With 1 and 2, the activation group remains active until it is reclaimed (RCLACTGRP command)