Re: ILE CL vs. OPM CL

["Mark S. Waterbury" <mark.s.waterbury@xxxxxxx>]

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