• Resources were not trained in the new techniques.
• There was no budget for training resources.
• The existing code was working just fine, thank you very much.

To add to IBM's consternation, the initial feedback from those who tried ILE was mixed at best and, in some cases, disastrous. Promised performance advantages did not materialize for many users. Working programs mysteriously stopped working or gave inaccurate results. It reached the point where IBM ILE RPG presentations began with the statement that you did not have to use modules and binding to use the features of RPG IV!

This brings us to CL programming. An ILE CL program has the source type of CLLE, as opposed to CLP, for OPM CL programs. Once a CLLE module is created, it is bound into a program with all called and calling modules. In almost all cases, the default activation group is not used.

Today, the performance level of ILE modules is far greater than it was in Version 3. ILE has been greatly enhanced with user-written procedures, C language functions, CEExxx, and other APIs. Most require a different activation group than the default, so an ILE program is necessary to use these functions, but is it always necessary or even preferable to use ILE CL over OPM CL?

ILE performance benefits are most profound on repeated calls of a module, but a CL program is usually at the top of the stack. There would be no performance gain here. Placing the opening of files in different activation groups enhances performance, but this is not true in all cases. Then there is the added problem of overrides. Nearly every day, there is a post on a forum or bulletin board about modules using a file that's different from the one specified in the override. This problem is solvable, but it has caused a great deal of consternation and confusion. Then there is the RTVCLSRC command. If you lose the source to a CLLE and want to retrieve it using this command, you can forget about it. The program is a bound object consisting of various modules, not just the CL. It won't happen.

So what should you do? I would recommend using CLLEs under the following circumstances:

• The CL calls a procedure or API that requires binding.
• Other programs or modules call the CL repetitively.

Other than that, I can find no compelling reason for a conversion project that would, in essence, reinvent the wheel. In fact, I can think of reasons to stay with CLPs:

• I might need to retrieve the source one day.
• The CL is at the top of the program stack; there is no performance benefit.
• Overrides may be confusing, or incorrect.
• I don't have the time or the budget.
• Right now, it's working fine, thank you very much.

--David G. Abramowitz

 This email address is being protected from spambots. You need JavaScript enabled to view it.