ILE 'Mythconceptions'

As many of you know, when not writing articles such as this, we spend most of our time providing training in the ins and outs of RPG IV and ILE. During these classes, we often find ourselves "myth busting"-correcting some of the erroneous information that students have collected over the years. Weve gathered quite a collection of "mythconceptions," so we decided to share some of them. Well concentrate on ILE myths here; next month well look specifically at RPG IV myths.


Myth: Changing the number and/or type of parameters to a procedure in a service program changes its signature.

Reality: Changing the parameters has zero effect, because a service programs signature is related to the whole service programs interface and not to any individual procedure within it. Parameters represent the interface to an individual procedure, so changing them cannot affect the signature.

The most common cause of a signature change is that one has added a new procedure to the service program. However, removing a procedure or resequencing the list of exports (typically procedure names) in the service programs binder language would have the save effect, because the signature is based on the exported names and their sequence. For more on using binder language to exert control over a service programs signature, click here.

The best way to protect against parameter mismatches (in RPG IV, anyway) is to always prototype calls to programs and procedures, use procedure interfaces in the called programs and use /COPY to bring the prototypes into both the called and calling code. This requires recompiling the calling programs and procedures, however, to catch the mismatches. For more on writing prototypes and their advantages, click here.

Myth: Using a binding directory to create ILE programs affects the programs size and/or performance.

Reality: Not true. A binding directory is used only at binding time. It has no effect at runtime. And it wont bind all the modules and service programs listed in the directory to the program. It binds only those objects containing procedures that have actually been referenced in the program, typically by a subprocedure invocation or other bound call (e.g., CALLP or CALLB).

Binding directories simply save developers the trouble of remembering and typing module and service program names on the Create Program (CRTPGM) or Create Bound RPG (CRTBNDRPG) commands. A future EXTRA article will cover using binding directories for those who havent learned the joys of letting the system do the work for you.

Myth: The name of the Default Activation Group is QILE.

Reality: The proper name is "The Default Activation Group." Its understandably confusing. QILE is a named ILE activation group. Only ILE programs can run there and its only created if and when an ILE program that requests it is called. The Default Activation Group exists in every job from the beginning and is where all non-ILE programs (called Original Program Model or OPM) run.

Why the confusion? Because most of us think of default as the value thats assigned to a parameter if we dont key in a value. In this case, however, it refers to the fact that this is the activation group that will be in the job automatically-by default-even if we dont call any ILE program requesting a specific activation group.

So where does the QILE name enter the picture? Its the shipped default value for the Activation Group (ACTGRP) parameter on the CRTBNDxxx commands, but will only be in effect if you first override the shipped default value for the Default Activation Group (DFTACTGRP) parameter from *Yes to *No. In other words, whenever you tell the compiler that you want to create a "real" ILE program.

There are also the special values of *NEW, which, to confuse the issue further, is the shipped default value for ACTGRP on the CRTPGM command, and *CALLER. Its beyond the scope of this article to explain where and when these values should be used. However, we can say that we dont recommend using either of those values as your shops default value for CRTPGM or CRTBNDRPG. Well explain what we do recommend, and why, in a future article.


Jon Paris is a technical editor with IBM Systems Magazine and co-owner of Partner400.

Susan Gantner is a technical editor with IBM Systems Magazine and co-owner of Partner400.

comments powered by Disqus



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Are You Multilingual?

Rational enables development in multiplatform environments

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters