ILE Process Model

The ILE process model was first introduced in the AS/400 at V2R3, along with the ILE program model and the ILE compilers. The original process model and the ILE process model coexisted in the AS/400 until the appearance of the RISC processors. The RISC processor systems support only the ILE program model and the ILE process model. (Both the ILE program and process models were created with the RISC processors in mind.)

In this and the following sections, we look at the ILE process model in more detail. Before we do, we need to revisit the changes made on the AS/400 to support the ILE program model. The constructs used at the MI to support ILE programs are program activations, activation groups, procedure invocations, and a new procedure pointer.

In Chapter 4, we looked at the ILE compilers and program model. We saw that ILE changes the way programs are created, and we introduced the idea of a module. The module is the output of an ILE compiler, and a module can contain one or more procedures. The ILE binder packages these modules into programs and service programs. In this way, programs and service programs can contain one or more modules, and these modules in turn can contain one or more procedures. The two types of call instructions (CALLPGM and CALLBP) defined as part of the ILE are used to reference the programs and the procedures within the modules.

A program is an MI system object that is always called with an external call (CALLPGM) instruction at the MI. Similar to the older CALLX instruction, the CALLPGM instruction uses a system pointer to identify the program. The CALLPGM instruction activates the program. This activation operation completes the interprogram binding, as we described in Chapter 4. For example, if a program uses modules that are bound by reference, the links to the service program are resolved at the time the program is activated. Activating a program implicitly creates the activation groups, which provide the working storage for the program. The program activation operation also initializes the static storage for the program.

A program contains one or more procedures. One of the procedures is designated as the program entry point at the time the program is created. Control is passed to this procedure by the CALLPGM instruction as a part of the program activation. This operation of passing control to a procedure is called a procedure invocation.

A CALLBP instruction is used to invoke any other procedures associated with the program. The CALLBP instruction uses a procedure pointer to identify the procedure being called. The procedure being called can be either in the program if it was bound by copy, or in a service program if it was bound by reference. Note that MI tracks call flow invocations by procedures, not by programs.

When an application program is first moved to a RISC processor, the original program is converted to an ILE program containing a single procedure. Thus, a converted original program, like any program with only one procedure, will always be called with a CALLPGM. If a program created with an ILE compiler has more than one procedure, the first procedure is called with a CALLPGM and subsequent procedures are called with CALLBP.

We also introduced activation groups in Chapter 4. Activation groups provide the storage resources for the program activations. Each activation group has its own static storage area, automatic storage stack, and heap storage area. An activation group is the working storage that is allocated to run one or more programs. Because only the ILE process model exists now with the RISC processors, this working storage is also designed to support all original processes, and it replaces the old PASA/PSSA storage areas.

An activation group is not an MI system object; it is part of an MI process object. Each MI process object contains two or more activation groups. One of the activation groups is used by the system. Each process object also contains at least one user activation group. When an original process created on an IMPI processor system is moved to a RISC processor system, that original process is transformed into an ILE process containing a single user activation group.

An activation group does more than just partition the storage used by a process. Each activation group has its own control information, which lets each activation have different protection states, file usage, and commitment control. This gives a great deal of flexibility for jobs above the MI.

All activation groups are named, either explicitly by the user or implicitly by the system. Programs and service programs can specify explicitly as part of the program object definition which named activation group they are to run in and can cause the activation group to be implicitly created under a job when the program object is called.

Inside an ILE Process

In this section, we look inside the ILE process. The ILE process structure is complex and, like many other parts of the AS/400, has a set of names and acronyms that can make even a die-hard computer scientist beg for simplicity and common terminology. While it is not necessary to read this to understand how processes work on the AS/400, I include this section for completeness. So for those masochists who need another dose of acronyms, read on.