 | |
 |
|
| Ron Turull | |
| |
For anyone who has spent a career developing applications on IBM midrange platforms, ILE will definitely prove to have quite a learning curve. Ask any C programmer who made the leap to programming Windows applications from the old DOS platforms, and you will be told that learning ILE is akin to learning C and Windows programming in one fell swoop (except, of course, you do not need to worry about general protection faults, and "hanging" an iSeries is almost completely unheard of).
The first step to learning ILE is to understand all the new object types involved in ILE. This is important not only for programmers, but also for administrators who will be managing ILE objects. The chart shown below summarizes the ILE object types. This chart will give you a basic understanding of the different ILE-related objects and how they interrelate.
In Part II of this two-part series, we'll discuss these ILE objects in more detail. Later, we will look at ILE-related commands. It is important to realize that these are the basic building blocks for developing ILE applications and administrating ILE objects. It is, therefore, essential to have a very clear understanding of them.
ILE object type |
Function |
Key benefit |
Caveats |
|
ILE program (*PGM) |
The executable object. Same object type as for OPM programs (*PGM) but
program type attribute is ILE. |
Can run in any activation group (OPM programs can
only run in default activation group). Supports mixed-language programs. |
Errors/conditions are handled differently. |
|
Activation group (not an
i5/OS object) |
Job-related object used for executing programs Similar to the PAG but can be controlled much more
(OPM programs used to execute in the job's PAG, all programs -- ILE & OPM -- now execute in
activation groups). |
Activation groups isolate programs and resources
with the activation group. Multiple activation groups per job. |
Activation groups consume system resources. Control boundaries between activation groups can
get complicated |
|
Module (*MOD or *MODULE) |
An intermediate object used to hold the result
of compiling a source member before it becomes part of a program Contains only MI instructions, not an executable
object |
Calls between modules execute much quicker than
calls between programs Can combine multiple modules to create an ILE
program. Reusable: can include in more than one program. Takes modular programming on the iSeries to the
next level |
Increases program size More disk space also required to store the module
object itself. |
|
Service program (*SRVPGM) |
Provides the fast module-to-module call without
increasing program size |
Activation group in which to execute can be specified
(as for ILE programs) Similar to DLLs on the PC but with more features
(except no initial control procedure like the DLL LibMain function). |
Design must be well thought out No support for an initial routine (i.e., *INIT
in RPG). |
|
Binding directory (*BNDDIR) |
Allows saving and reusing some of the information needed to build an ILE program.
Similar to the object-list in a make-file (make-files
are used on other platforms to automate program creation). |
Speeds application development Can be used to store creation information for
multiple programs. More than one binding directory can be used to
create a single program. |
Can lengthen program creation time if used carelessly. |