Commonly Asked Questions About ILE Activation Groups

[gantner]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
Hi Erick, It is typically easier and simpler to manage an application environment that is either all ILE or all OPM. This is due primarily to the Activation Group scoping issues than can/will arise when there are 2 groups (and ILE one and the DAG) involved. So if you have some ILE programs in an application, I would say yes, it would be easier to convert the OPM programs to ILE and have them all running in the same Activation Group. It requires less knowledge of ILE to work that way. Besides, if the OPM programs are not even RPG IV, I would advise converting them if only to gain access to a more powerful language. That said, the 2 environments can interact - it just takes more knowledge of and attention to things like scoping of overrides, shared opens and commitment control definitions.

[gantner]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
Hi jacobus, I agree with your point that Activation Groups are not that complicated and can be quite useful. Thanks for voicing some of the the positive sides of them for this discussion. I'd like to comment on one of your points. Your comparison of *NEW to setting on LR is close but not 100% accurate. Setting on LR in an ILE program does close the files and sets the static fields in the program up for re-initialization. But it doesn't clean up or deallocate the static storage for the program in the user's job. Reclaiming the Activation Group - either explicitly or implicitly by means of using *NEW - does actually clean up all the storage of the program. Most of the time, this subtle difference doesn't matter to the behavior of the program, although it can make a performance difference.

[B.Morris]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
tiki wrote: > The default activation prompt now showing when compiling SQLRPGLE > (option 14 or 15) program. Do I have to manually insert it on H > Specs. TIKI, it's best to put it in the H specs, since that way you don't have to always remember to use CRTSQLRPGI correctly. But if you really want to do it on the SQLRPGLE compile, you can use the COMPILEOPT parameter of CRTSQLRPGI, COMPILEOPT('DFTACTGRP(*NO)'). (COMPILEOPT is available starting in V5R3 for all the CRTSQLxxx commands.)

[jacobus]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
Hi, I'm not sure if using *CALLER as the default instead of *NEW is a good idea. I think it makes a big difference if *NEW is used "by default" and only to use *CALLER in performance critical situations. Using *NEW results in more robust programs because all resources are automatically cleaned up and memory is reinitialized when the program is called again (to which we are used to in the OPM environment). With *CALLER the programmer has to make sure that variables are properly initialized. In any case, it takes some thought using *CALLER. Using *NEW is simple and behaves the way we are used to. All variables are initialized so there is no chance one is missed. But using *NEW has impact on performance, but general wisdom says that 80% of the time is spent in 20% of the code. So one could use *CALLER only in these 20% of the code, or if it is needed for some special functional requirement. Using *CALLER by default seems to me a bad thing. gr. jacobus

[gantner]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
Hi jacobus, I agree with your point that Activation Groups are not that complicated and can be quite useful. Thanks for voicing some of the the positive sides of them for this discussion. I'd like to comment on one of your points. Your comparison of *NEW to setting on LR is close but not 100% accurate. Setting on LR in an ILE program does close the files and sets the static fields in the program up for re-initialization. But it doesn't clean up or deallocate the static storage for the program in the user's job. Reclaiming the Activation Group - either explicitly or implicitly by means of using *NEW - does actually clean up all the storage of the program. Most of the time, this subtle difference doesn't matter to the behavior of the program, although it can make a performance difference.

[JonFParis]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
"Actually the programs that don't seem to be fixed after changing them are OPM" There are two main causes for this: 1) The OPM program was called by another OPM program and that program has not yet set on LR. As a result the pointer it has stored to the changed program still points to the old PGM object. This is situation normal and has nothing to do with ILE. RCLRSC should cure it - there should be no need to sign off. 2) The OPM program was called from a *CALLER ILE program running in the DAG which has not set on LR. Scenario is as at 1 except the ILE program is unaffected by RCLRSC and therefore sign-off is the only solution. This is the kind of situation that both Susan and I have mentioned. ILE programs are not designed to run in the DAG and you need to know a lot about ILE to do it safely and consistently. "So far, about the only places we have been able to use ILE programs ..." Do you mean the only place you have been _allowed_ to use it? You could convert your entire system to RPG IV tomorrow, compile with DFTACTGRP(*YES) and you probably wouldn't notice the difference. Well you would notice a difference. The programs would be more readable, probably run faster, be easier to modify, and you'd be able to use the improved language features. And by the way you wouldn't have any of the problems you seem to associate with ILE - because you wouldn't be running ILE programs. Just RPG IV pretending to be OPM. This is really a no-brainer. "We don't want to be on the bleeding edge of technology, you know." I'm hoping and praying that you said that tongue in cheek - or at least as a dig at your management. RPG IV stopped being leading edge (it never was bleeding edge) at least 10 years ago.