Re: ILE CL vs. OPM CL

Hello, Donna:

(Cross-posted from RPG400-L)

In my opinion, there are really two separate and somewhat independent topics to consider here ... the compilers/languages and their environment.

1. there is the Integrated Language Environment (ILE) where programs run in activation groups other than the *DFTACTGRP -- and in those cases, I agree that there are many other issues to consider, such as "activation group scoping" of overrides, etc., when converting from OPM to ILE.

-and-

2. there are the newer (ILE-enabled) languages and compilers, with member types such as CLLE and RPGLE. Note that you do not have to use the ILE environment (running in a true ILE activation group) to use these languages, because all of the IBM ILE compilers support commands such as CRTBNDCL, CRTBNDC, CRTBNDCBL and CRTBNDRPG that allow you to specify (or default to) ACTGRP(*DFTACTGRP). This causes the resulting *PGM to run in the default activation group, which is the same place where all OPM *PGMs run, so you do not have to deal with all of those issues like override scoping, etc., because these programs are running in what I call "OPM compatibility mode".

Someone could convert RPG/400 programs to RPG IV, to take advantage of some of the new features and functions, and potentially to gain some performance by using these improvements, while still running in the default activation group (with all the other OPM programs). However, simply converting with CVTRPGSRC and recompiling is probably not going to gain much (or any) performance, in my opinion.

If this is how someone is using "ILE" then there is probably not much real benefit to converting from OPM CL to ILE CL at this time. Later on, once they have converted most of their RPG/400 to RPG IV, and they start looking at using service programs, etc., that might be a better time to evaluate converting to CLLE.

Someone at your shop should be looking at those jobs that are experiencing "poor performance" to understand the true causes, rather than just blindly attempting to "fix it" by converting to ILE. For example, the problems could be due to overhead such as OPNQRYF having to build a new access path each time, because no existing logical file has the desired key sequence. This problem will persist, even after converting to ILE, unless the application design is changed (add another LF with the correct keys). (That's just one example.)

Regards,

Mark S. Waterbury