Understanding ILE objects -- Part I

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.

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