Understanding ILE objects -- Part I

With this tip Ron Turull gives you get a basic understanding of the different ILE-related objects and how they interrelate.


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.

 




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


This was first published in April 2005

Dig deeper on iSeries ILE programming

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchEnterpriseLinux

SearchDataCenter

Close