After a little overview on the history of RPG language in the previous post https://linkedibmi.com/2018/04/28/from-rpg-to-rpgle/ I would introduce basic components and concepts about RPG ILE language.
An ILE PROGRAM in general consists in one or more MODULE and every module consist in one or more PROCEDURES called subprocedures. If a subprocedure can be used in more then one place it belongs in a SERVICE PROGRAM.
Now we could have a deeper analysis on these components trying to understand their meaning and their use.
RPG ILE COMPONENTS
When we talk about subprocedures we could refer to different kind of objects:
- ILE modules
- Main procedures
- Built-in functions
I would examine a little bit the different meaning of these components:
An ILE MODULE is a single unit od code that could be grouped in one of the following:
- with a main procedure and no subprocedures
- with a main procedure and one or more subprocedures
- with no main procedure but with one or more subprocedures
The main procedures are procedures that could be called both by a dynamic CALL or by a bound CALL. Subprocedures must always be called by a bound call: this is because subprocedures can only be used in programs that are created by Create Program (CRTPGM) or by Create Bound RPG Program (CRTBNDRPG) commands.
These are subprocedures that are defined to return a value as functions or user-defined functions.
Subroutines are different from subprocedures even if they have the same meaning because they are used to wrap re-usable code in a bigger part of code. Subprocedures offer more advantages respect to the subroutine. For example they can define local variables, they can accept parameters, they can provide parameters checking, they can be used as a function.
Service programs are collections of modules, especially if the modules contain subprocedures to share. The main advantage to use service program is to avoid to bind the modules that contain the procedures, by copying the compiled code into every program. Service programs are object of kind *SRVPGM and cannot directly called but must be called by ILE programs or other procedures.
ILE programs and service programs are created by using the process called “binding”. This process copies the compiled code from module objects to create program and service program. The binding process can also bind a program to a service program by reference, to use it at run time.
An ILE program can be created by using the CRTPGM command from one or more module objects. CRTPGM can also bind the program to ONE OR MORE SERVICE PROGRAM.
The “Module parameter” of CRTPGM lists all the modules that are copied into the bound program.
The “Service program parameter” of CRTPGM lists all the service programs that are to be referenced by the program at run time.
Service program object are created by using Create Service Program (CRTSRVPGM) in the same way of creating programs. RPG ILE programs can also be created by using the Create Bound RPG Program (CRTBNDRPG) command: this command performs both compilation and binding in a single step. If the program needs to copy any modules or to reference any service programs, then a Binding Directory is required.
A binding directory (object type *BNDDIR) is a list of modules and service programs that could be binded into a program that needs them.
The binding directories are created by two CL commands:
- Create Binding Directory (CRTBNDDIR)
- Add Binding Directory (ADDBNDDIRE) or Work with Binding Directory Entries (WRKBNDDIRE)
The CRTBNDDIR creates an object of *BNDDIR type. The ADDBNDDIRE command adds an entry to the directory list.
The activation group is a part of the job structure and let to run programs in isolated environments. It is created when an ILE program or a service program is started or activated. It is recommended to run ILE program in an defined activation group, used when the program is created, instead of leave the default activation group: this will let you to scope the commitment control and the file overrides.
There are three types of activation groups: default, named and new.
About the default activation group there are two default activation group:
- activation group 1, reserved for many system programs
- activation group 2, for the RPG IV programs that are created with DFTACTGRP(*YES) of the CRTBNDRPGM
The other types of activation groups are created by CRTPGM and CRTSRVPGM at creation time of the program.
An activation group is created when the program starts and it could include these entities:
- static and automatic variables
static variables are those that are defined in a main procedure or they come externally from DDS and SQL specifications; or are defined as STATIC in a subprocedure.
Automatic variables are local variables defined in subprocedures.
- open data paths
these are open files to program, for example data buffers and pointers to records.
- dynamically allocated storage
these are temporary objects created by the %alloc built-in functions
- error handling routine
these are modules that handle error messages
The CRTPGM and CRTSRVPGM and the CRTBNDRPG let to define the activation group with these values:
- NEW: a new activation group is created every time that the program is called. This could be a cause of PERFORMANCE PROBLEMS because a new set of static variables and open data paths are created each time the program is called.
- *ENTMOD: in this case the program entry procedure module is examined to estabilish which kind of activation group must be used (please consult the help to discover all the cases)
- NAME a named activation group is created if it doesn’t exists. This is the best situation because it enables separation of applications in efficient way. It should be used on the main program and all the other should use *CALLER or the same name.
- *CALLER: the ACTGRP(*CALLER) parameters indicates that the service program runs in the same activation group as its caller.