× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.