Commonly Asked Questions About ILE Activation Groups PDF Print E-mail
Programming - RPG
Written by Susan Gantner   
Tuesday, 17 July 2007 18:00

In my teaching about ILE at conferences and in classes, the subject that tends to generate the most questions is activation groups. In this article, I'll take a look at the answers to some of the most commonly asked questions I've heard.

First, a very brief definition of activation groups may be in order as a level set. An activation group is a logical grouping of programs and/or procedures within a job. Perhaps the easiest way to envision them is to think of them as smaller jobs nested inside the bigger "real" job. However, unlike with "real" jobs, you can do program or procedure calls directly from one activation group to another.

Activation groups have two primary purposes:

  1. To provide an easy way to clean up (reclaim) program storage and close files associated with a specific group
  2. To provide an ability to make shared resources (such as file overrides, shared open data paths, and commitment control transactions) private to a specific group if you want or need to do so

Q: Aren't all my RPGLE programs ILE programs?

A: It depends on what options were used when the RPGLE programs were compiled. If the RPGLE source members were compiled with the Create RPG Module (CRTRPGMOD) command (which can be done via option 15 if compiling from PDM), then the programs created from those *Module objects are definitely ILE.

On the other hand, if the source was compiled with the Create Bound RPG Program (CRTBNDRPG) command (which can be done via option 14 if compiling from PDM), then it depends on the value of the Default Activation Group (DFTACTGRP) parameter at the time of the compile. The possible values for this parameter are *YES and *NO. *YES means that the program will run in the special Default Activation Group that exists in every job for the purpose of running non-ILE programs. But it affects more than just where the program runs; it also means that the program will be created with options that make it behave more like a non-ILE program than an ILE program. In other words, DFTACTGRP(*YES) means it is a program created with an ILE-capable compiler, but it is really not an ILE program and cannot take advantage of ILE facilities, such as having subprocedures defined in it or calling procedures or functions from a service program or running in an ILE activation group.

The IBM-shipped default value for DFTACTGRP is *YES, so if no one has changed this default on your system and the parameter wasn't changed at compile time, then programs created with CRTBNDRPG are not true ILE programs.

By the way, in case you use other ILE languages in your shop, the CRTBNDCL command also has the DFTACTGRP option, but CRTBNDCBL and CRTBNDC do not. So all programs created from source member types CBLLE or CLE are ILE, regardless of the way they were compiled.

Q: Isn't QILE the default activation group?

A: No. The use of the term "default" is unfortunate here because it has different meanings. While it is true that QILE is the shipped default value for the Activation Group parameter on many of the commands that are used to create ILE programs, it is not the same thing as the special activation group that exists in every job by default, which is called the Default Activation Ggroup (often abbreviated, as I will do here, as DAG).

The DAG exists in every job and is also the starting place for all jobs. By that, I mean that unless and until an ILE program that requests a different activation group is called, all programs will run in the DAG. The DAG is the only non-ILE activation group in any job. (Don't be surprised if you see two DAGs when displaying the activation groups for a job. One is for system state code only, so there is only one DAG that is usable for your application programs.)

QILE, on the other hand, is simply the name of an ILE activation group that IBM made up, and, as we all know, IBM likes to begin their names with "Q." It is intended to be a generically named activation group for ILE programs when the programmer doesn't specify a name but also doesn't want to use *NEW.

QILE is the shipped default value on the CRTBNDRPG and CRTBNDCL commands, but it will not appear if *YES is specified for DFTACTGRP. As of V5R3, QILE is also the default for programs created with Create Program (CRTPGM) if the entry module of the program is RPG, CL, or COBOL. The shipped default value of *ENTMOD on the CRTPGM command says that the activation group value of *NEW will be used for C programs, but for any of the other ILE languages, the value will be QILE. Prior to V5R3, the default value on CRTPGM was *NEW. So many RPG programs created prior to V5R3 may still have an activation group value of *NEW by virtue of that default.

*NEW was found to be a bad choice for the default value because it was inconsistent with the CRTBNDRPG command and because it meant that too many programs were being created with *NEW. When overused, *NEW can be a source of performance and program behaviour issues. When used intentionally, *NEW is great, but when used by default, its effect is often negative.

Q: Our production code uses the command RCLACTGRP(*Eligible). What does this mean, and is it a good idea?

A: Specifying *Eligible with the Reclaim Activation Group (RCLACTGRP) command is never a good idea in production code. You can get some indication of the danger that can arise from using the *Eligible option by prompting the command in an emulation session. Normally, special values that are allowed in a command are included on the prompt screen, but you'll find that *Eligible is not listed. It is included in the help text (F1) behind the screen because it is a valid option for the command, but its use is discouraged by not showing it on the prompted command. Let's just say that when IBM first introduced this option, it seemed like a good idea at the time....

Don't misunderstand me: There is nothing at all wrong with using the RCLACTGRP command. It is a great way to clean up programs, close files, etc. in a manner similar to the old non-ILE RCLRSC command. However, it is best used by specifying the activation group (e.g., QILE or your own name) rather than using the generic *Eligible.
Why? An ILE activation group is considered "eligible" to be reclaimed if there is no program or procedure in that group currently in the call stack of the job. The problem with using the generic *Eligible option is that you can never be sure what groups are there, and it is far too easy to reclaim some code that will be needed later in the job. Even if your own home-grown applications use only one ILE activation group, IBM often creates activation groups in the users' jobs, as do other software vendors whose applications your users may have either now or in the future. So take the extra time to include the specific activation group name you want to reclaim each time to avoid problems.

I must confess that I do sometimes use RCLACTGRP(*Eligible) in my own development jobs as a sort of quick and dirty way to clean up the job between test runs of an application I'm developing. But I never put it into a CL program that might at some point become included in a production application.

Q: On our system, the default value for the Activation Group parameter on the CRTPGM and the CRTBNDRPG (or CRTBNDCBL and/or CRTBNDCL) commands has been changed to *CALLER. What group are our programs running in? Is this a good idea?

A: It depends on whether all the programs in your application have the *CALLER attribute or if one or more "driver"-type programs use either a named activation group or *NEW. The *CALLER attribute means the program will run in any activation group where it is called.

If all the ILE programs in a job have *CALLER for the activation group, then the ILE programs will run in the DAG (i.e., the job's non-ILE activation group) because all jobs begin in the DAG. This practice can cause some very bad problems in applications over time and should be avoided. ILE programs should not, at least as a general rule, be run in the DAG.

The use of *CALLER by sub-programs that are always called by a program that uses either a named activation group or a *NEW one is fine. By the way, this technique was well-illustrated back in March by Joe Pluta.

Q: Why doesn't my OPNQRYF command work with my ILE program?

A: While there are a couple of scenarios that could cause this, by far the most common one is that the CL program containing the OPNQRYF is still a CLP member type and therefore is running in the DAG. Your RPG program is running, as it should, in an ILE activation group, whether that's a named activation group (e.g., QILE or a name of your own design) or *NEW. The problem that has occurred here is one of scoping of the shared open data path (ODP) used by the OPNQRYF command. The ODP created by the OPNQRYF is scoped to (meaning it can only be seen by) the DAG. So programs running in the DAG will be able to see the results, but those running in any other activation group will not.

The best solution to this problem is definitely not to run your ILE program in the DAG. While that option will solve this particular problem, it will almost certainly cause other, more insidious problems over time. There are two recommended solutions:

Solution 1: You can put your OPNQRYF command in a CLLE source member and either bind it with the RPG that runs in the ILE activation group or just create the CLLE program to run in the same ILE activation group.

Solution 2: You can specify OPNSCOPE(*JOB) on the OPNQRYF to ensure that the ILE program(s) running in different activation groups from the CL can use the shared ODP created by OPNQRYF. In this case, your CL program can remain a CLP running in the DAG.

Q: Can I mix ILE and non-ILE programs in the same application?

A: Yes. Technically, you can mix them. However, you will need to know much more about the details of how ILE works and how to make it work the way you want it to. That's the only way to have the two environments live happily ever after in the same application.

If it is at all practical to do so, running all the code for a particular application in an ILE activation group is the far easier answer. The primary issues that arise from mixing program types are ones related to scoping of file overrides, shared ODPs, and commitment transactions. The OPNQRYF question above is just one common example of the kinds of issues that arise. While those issues do have relatively simple solutions designed for the purpose, you need to know that the issue exists in order to solve it. Scoping parameters include not only OPNSCOPE, as mentioned above, but also Override Scope (OVRSCOPE) and Commit Scope (CMTSCOPE). However, the shipped defaults for the scoping parameters, which exist on many commands (such as OVRDBF, OPNDBF, OPNQRYF, and STRCMTCTL) are set primarily for an all-ILE (or all-non-ILE) environment. If all the programs, including CL, run in the same ILE activation group, there are no scoping issues to worry about.

Questions, Questions, Questions

I hope this article has answered some of your questions about activation groups, and perhaps it has even raised a few more questions in your mind. Feel free to ask those other questions. I look forward to exploring more topics related to developing ILE applications in future RPG Developer articles. If there are specific aspects that you want to see covered, let me know in the forum associated with this article.

(c) System i Developer, LLC

Susan Gantner’s career has spanned over 30 years in the field of application development. She began as a programmer, developing applications for corporations in Atlanta, Georgia, and working with a variety of hardware and software platforms. She joined IBM in 1985 and quickly developed a close association with the Rochester laboratory during the development of the AS/400 system. She worked in Rochester, Minnesota, for five years in the AS/400 Technical Support Center. She later moved to the IBM Toronto Software Laboratory to provide technical support for programming languages and AD tools on the AS/400 and iSeries.

Susan left IBM in 1999 to devote more time to teaching and consulting. She co-authored one of the most popular System i Redbooks ever, Who Knew You Could Do That with RPG IV? She and partner Jon Paris make up Partner400, a consulting company focused on education and mentoring services related to application modernization. Susan is also part of System i Developer, a consortium of top educators on System i technology who produce the RPG & DB2 Summit events. Visit www.SystemiDeveloper.com for more information.


Susan Gantner
About the Author:

Susan Gantner's career has spanned over 30 years in the field of application development. She began as a programmer, developing applications for corporations in Atlanta, Georgia, and working with a variety of hardware and software platforms. She joined IBM in 1985 and quickly developed a close association with the Rochester laboratory during the development of the AS/400 system. She worked in Rochester, Minnesota, for five years in the AS/400 Technical Support Center. She later moved to the IBM Toronto Software Laboratory to provide technical support for programming languages and AD tools on the AS/400 and iSeries.

 

Susan left IBM in 1999 to devote more time to teaching and consulting. She co-authored one of the most popular System i Redbooks ever, Who Knew You Could Do That with RPG IV? She and partner Jon Paris make up Partner400, a consulting company focused on education and mentoring services related to application modernization. Susan is also part of System i Developer, a consortium of top educators on System i technology who produce the RPG & DB2 Summit events. Its members include Jon Paris, Paul Tuohy, Skip Marchesani, and Susan Gantner.

Read More >>

< Prev   Next >
Last Updated on Tuesday, 17 July 2007 18:00
 
Guest.Visitor
Activation groups always seemed to be a solution in need of a problem. Long ago when I studied Linux I learned an interactive command that created an independent session immediately beneath the current session. This environment was completely independent of the initial level. Unfortunately, I have been away from Linux for years and I don\'t remember it ... the command is a pretty basic one, as I recall. Once I learned the Linux command, I developed the impression that activation groups were a complicated emulation of this simple Linux feature. When programming on the AS/400, I gave up on activation groups because I had problems getting common program features to communicate with other common program features. Also, and most importantly, I could not see any obvious value. Yes, I read explanations such as yours that advertised great improvement being added by keeping program levels separate. On a practical level, it actually seemed to add complexity without adding any value ... at least with regards to most programming situations. All articles about activation groups seem to take the position your programs will be \'better\' if you use them. The revelation is always followed by a complicated and technical analysis that rarely makes the value seem obvious or practical. Te overall impression is that IBM is trying to sell computers and keep programmers busy by creating a false impression of some kind of technical snobbery and a vague sense of superiority for those who use this obscure feature. So, to come to the point, Please provide a list of moderate length that illustrates common program situations where adding programming to support activation groups will demonstratively improve the use of the program ... and I don\'t mean by using a stopwatch to measure program runtime. Prove me wrong.
jerry.goldson@abbott.com
One could, and some have, raised the same objections about ILE in general. It seems to boil down to the ability to run C modules.
JonFParis
Since I was involved in the design and introduction of ILE from the beginning, perhaps you\'ll allow me to at least partly address this. With the massive increases in power/$ ratio over the years it is easy to forget that back in the CISC hardware days, program to program calls were an expensive business. There was no way to efficiently perform high volumes of calls. The need to run C programs on the box in order to attract new tools and applications etc. made it imperative to address the call speed issue. We were also wrestling with a number of other issues relating to isolating and protecting resources. A new program model was needed to achieve this. It was simply not possible/practical to get what was needed out of the old model. ILE was born out of these needs. Subsequently the decision was made to introduce a new version of RPG that embraced this model and RPG IV was born. This too was vital since more and more RPG programmers were becoming familiar with languages like C and Pascal and wanted the ability to have fast calls to functions written in RPG. Similarly ILE COBOL and CL came along for the ride. Had RPG not moved to this new world, RPGers would have screamed long and loud and would probably still be screaming today some 12+ years later. Unlike COBOL, RPG can very effectively live in both worlds. If you don\'t want the new features such as subprocedures and the ability to bind to procedures in other languages (C, COBOL, Java) then you don\'t need to use them. If you choose to live in this world you run in compatibility mode i.e. DFTACTGRP(*YES) and Activation Groups can be ignored. If you want to exploit the new features then you need to be aware of ILE concepts such as Activation Groups and scoping. You can make it as simple or as complicated as you like. If you don\'t want or need the application isolation capabilities provided by AGs don\'t use them. Simply run all of your ILE code in QILE and leave it at that. Hope this provides a little perspective.
jrbromm
The way I understand activation groups, the following practices seem to me to be the way to go. I hope someone with more understanding will correct me as needed. A job that is to be run from the command line, a menu, or as a submitted job should start with a program set to activation group *new. Any program called by this initial program should be set to activation group *caller unless it has has some special need for overrides that would be outside that of the initial program, in which case it also should be in activation group *new. When a program is created to run in a named activation group, a bunch of garbage (overrides, work space, and who knows what else) is left over when it ends that has to be cleaned up, either by running RCLACTGRP or by signing off the session. When a program is created to run in activation group *new, all this garbage is automatically cleaned up when that program ends. Sometimes you see indications of this garbage when you run a program, notice some changes that need to be made, make those changes and recompile the program, and when you run the program again, the changes don\'t seem to be there. It\'s not until you sign off and sign back in and then rerun the program that the changes show up. Signing off is a way of getting that garbage cleaned up. By having the initial program set to activation group *new and programs called by this initial program set to activation group *caller, not only is all the garbage caused by the initial program cleaned up when that program ends, but all the called programs\' garbage is also cleaned up. This means that I no longer need to delete overrides done in those called programs. I also don\'t have to do a final call to any reentrant programs (programs that return to the caller with *INLR left off) in order to set *INLR off. There may be cases where overrides have to change several times during the running of a job. In this case, I may want to treat each of these cases as a separate job and have the starting program there also set to activation group *new. An example might be an inquiry program showing a list of items where each time an item is selected from the list, a report is printed to a different printer based on the class of the item. The inquiry program would be in a *new activation group, and the print program with its overrides to the printer would be in its own *new activation group so its overrides would be cleaned up as it ends and returns to the inquiry program. Most of the literature I\'ve seen seems to say to avoid using *new as an activation group because of the overhead in creating and cleaning up after itself, but I would think that overhead is insignificant when used as above. The place where you would not want that overhead is in a report or posting program where thousands or millions of records are being processed and a program is being called for each of these records. That called program should not be set to *new. There may be cases where named activation groups might be useful. A service program which is used throughout the system might be an example. Its activation group could start as you go into your first task of the day and stay active until you sign off at the end of the day while each task would be doing its own cleanup as it ended leaving the service program active for other tasks to use.
gantner
I\'m new to the MC Press team, but based on some of the articles I\'ve read I was left with the impression that many of the readers are into using ILE already and so I didn\'t feel it was necessary to start at the beginning. The purpose of this article was to provide some answers for some of the questions I get asked all the time. These are questions from people who apparently do see some benefit in utilizing ILE features. This piece wasn\'t intended to "advertise" anything so if it that\'s the way it came across, perhaps I wasn\'t clear enough. I had no intention of convincing anyone who wasn\'t using ILE that they should. If you are not convinced of the usefulness of ILE, then there\'s no reason to use it and therefore no reason to use Activation Groups. Perhaps the whole “why ILE” question could be explored in a future article, although I prefer these days to write about more practical tips for those who have already made the decision for ILE. In my experience, most folks who have a need for ILE seem to understand the “why” without my help and have more need for the “how”. Bottom line, if you\'re going to use ILE facilities in your applications, then you should use at least one ILE activation group simply because that\'s the way the environment was designed to work. That means that you should also understand some of the facts discussed in this piece.
Guest.Visitor
In some circumstances, I have seen ILE programs call older OPM programs. Personally, I don\'t like that architecture, but I wondered if you could comment generally on the interoperability of two. For example, do you highly recommend the OPM programs be converted to ILE with the activation group set as *CALLER, or set as the same named activation group? Thanks for your input. Erick
gantner
I happen to think the ability to call C functions from RPG is very useful, but it’s far from the only reason – not even the best reason - to use ILE, IMHO. Far more useful to me, for example, is the ability to write my own functions in RPG – true functions that return values and are used much like RPG’s built-in functions from expressions. It’s almost like allowing me to extend RPG for my own specific application needs. It doesn’t need to have anything at all to do with calling C. I don’t think ILE – including using Activation Groups – is particularly complex. It’s just different from our pre-ILE world and that involves learning new things. As I alluded to in the response to the last FAQ in the article, it is often made more complex than it needs to be by trying to mix ILE and non-ILE in the same application. But the best part, to me, is that we, as RPGers, are able to take advantage of so many of the features of the advanced language (e.g., dates, built-in functions, expressions, XML parsing) without any need of learning about ILE, binding, Service Programs or Activation Groups. The ILE COBOL compiler doesn’t have a DFTACTGRP(*Yes) option so COBOLers must learn, to some extent, ILE in order to use the new language features.
foxj@mscdirect.com
We make extensive use of ILE and have a huge legacy of non-ILE programs that go back to the days of the System 38 running on our i5 system. All of our ILE programs are DFTACTGRP(*NO) ACTGRP(*CALLER) and in most cases, our ILE programs are called from the non-ILE programs. You mention that it is not recommended to call ILE programs and allow them to work within the default activation group (which is how the majority of our solution works today by virtue of the settings above) because there are problems that could occur. Unfortunately, you do not elaborate on any details as to what problems could occur. I am very concerned that I may be sitting on top of a ticking time-bomb and would greatly appreciate it if you would elaborate on the kinds of problems that can occur in this setting so that I can understand how they could potentially impact my systems. Thanks.
Guest.Visitor
Yeah, I\'d sure like a more detailed explanation of "can cause some very bad problems" too. I did have an issue once with using an ILE feature inside an RPG IV *CALLER program where the caller was an OPM CL. I registered the cancel handler \'CEERTX\' and the program would inexplicable zero out an order number in a file, about 1 per day. I yanked that mod out of production after about 3 days. And I always code my service programs as activation group QILE or something named anyway. But most of the RPG IV programs that only contain one procedure (the main procedure) run as *CALLER and so in the DAG. Chris
gantner
The scenario you describe – using *NEW for specific programs in combination with *CALLER for others is fine. I believe this is a similar idea to the architecture that Joe Pluta described in his Tech Tip in March. If this approach is working for you, go for it. My biggest concern about this approach the requirement for enough consistency and discipline within the shop to stick to this architecture. What I mean is that it only takes one of those *CALLER programs being called from one OPM program to start an entire string of them in the DAG. The fact that you’ve witnessed the dreaded “I recreated the PGM and it’s still doing the same thing as before” situation indicates to me that it may have happened in your shop. Maybe it was before you had this architecture in place. By the way, speaking of that “it’s still doing the same old thing” situation – it is not necessary to sign off to fix that situation. You need only reclaim the activation group the programs are running it. Unless, of course, if they are running in the DAG, because it’s the only Activation Group that can’t be reclaimed. A good enough reason not to use it for me. Personally, my own preference is to use a named Activation Group for everything – just one unless I have a need for scoped overrides as you describe. Then if/when I feel I need to reclaim the Activation Group for some reason, I just do it. It doesn’t seem like a big chore to me to code RCLACTGRP(QILE) after the call to that first ILE program in the stack (the one you code as *NEW). In my experience, if someone forgets to do the reclaim the results of that error are usually less dangerous and/or at least more predictable than the situation where ILE pgms are running in the DAG by mistake.
lujate
Virtually all of our in-house developed programs are compiled with DFTACTGRP(*NO) ACTGRP(*CALLER), and we have not experienced any problems. That allows us to use procedures without having to worry about Activation Groups. Every time the question of Activation Groups comes up at department meetings, the big question is "Why bother?". The only answer so far has been for minor performance gains.
gantner
The scenario you describe – using *NEW for specific programs in combination with *CALLER for others is fine. I believe this is a similar idea to the architecture that Joe Pluta described in his Tech Tip in March. If this approach is working for you, go for it. My biggest concern about this approach the requirement for enough consistency and discipline within the shop to stick to this architecture. What I mean is that it only takes one of those *CALLER programs being called from one OPM program to start an entire string of them in the DAG. The fact that you’ve witnessed the dreaded “I recreated the PGM and it’s still doing the same thing as before” situation indicates to me that it may have happened in your shop. Maybe it was before you had this architecture in place. By the way, speaking of that “it’s still doing the same old thing” situation – it is not necessary to sign off to fix that situation. You need only reclaim the activation group the programs are running it. Unless, of course, if they are running in the DAG, because it’s the only Activation Group that can’t be reclaimed. A good enough reason not to use it for me. Personally, my own preference is to use a named Activation Group for everything – just one unless I have a need for scoped overrides as you describe. Then if/when I feel I need to reclaim the Activation Group for some reason, I just do it. It doesn’t seem like a big chore to me to code RCLACTGRP(QILE) after the call to that first ILE program in the stack (the one you code as *NEW). In my experience, if someone forgets to do the reclaim the results of that error are usually less dangerous and/or at least more predictable than the situation where ILE pgms are running in the DAG by mistake.
J.Pluta
In a recent article (Forum Decorum) I focused on "forum decorum", that nebulous concept of appropriate behavior in an online forum. In it, I noted that phrases that concentrate more on the poster than the post are not really welcome here. For example, above you state that activation groups are a source of "technical snobbery" and provide "a vague sense of superiority for those who use this obscure feature". Well, since Susan is writing about activation, that would imply that she\'s a technical snob. Even if that wasn\'t your intent, it\'s the predictable result of a response like this that starts out with an antagonistic tone. It\'s particularly ironic that you chose Susan to unload upon, since she is perhaps the least snobbish of any of the "name" writers in this community. Susan is perhaps the best in the industry at making advanced topics accessible and productive for new users. Anyway, enough on this. I just wanted to point out that your tone could be taken as somewhat rude and needlessly confrontational. Add to that the fact that you did it anonymously taking advantage of the bug in the forum software and the entire post is just a wee bit on the combative side for me. Joe
JonFParis
This DFTACTGRP(*NO) ACTGRP(*CALLER) combo often "works" for as long as you don\'t have service programs (SPs) in the mix. Particularly SPs that use files. As soon as you have that situation then we\'re into a scenario of driving the wrong way down the highway. It is no longer a question of _if_ you have an accident but _when_. As I believe Susan noted earlier - ILE programs were not designed to run in the DAG. They _can_ run there, but in order to run them in all combinations with any degree of safely you need to know a heck of a lot more about ILE than I do - and I helped design it! On the other hand, to use ILE the way it was designed to be run - i.e. ILE programs run in AGs other than the DAG - requires little knowledge of ILE and is perfectly safe requiring only basic knowledge of resource scoping rules. If you use a software combination where even IBM can\'t tell you exactly what can go wrong and when, then you have a problem, why take the risk when the "proper" option is easy and avoids all of this?
jacobus
Hi, I "use" activationgroups all the time, for every ILE program, i.e. i\'m aware of activation groups. In practice, to me they have added value, and only introduce one more choice. Each time i create a program, i make a conscious descision about whether to choose *NEW or *CALLER for the activationgroup. In principle, the default choice for me is *NEW, because this ensures that everything is cleaned up when the program ends, e.g. allocated memory. In some cirumstances, when performance is critical, i use *CALLER, so that all resources are kept in memory when the program ends, and will be still there when the program is called again. So, with activation groups you have more control over the system\'s behavior regarding allocating and releasing resources. If you don\'t make use of dynamically allocated memory or any other resource you have to allocate yourself in the program besides files then setting LR on will have the same effect as choosing *NEW. However, with *NEW it\'s guaranteed that alle resources are clean-up, especially because you can\'t know everything (like what happens in that program you call which is not yours). Activation groups are not complicated and quite essential in the ILE environment. jacobus
jrbromm
Actually the programs that don\'t seem to be fixed after changing them are OPM programs, since we have very few ILE programs, and signing off and back on seems to be the only way to get the machine to recognize the change when that happens. So far, about the only places we have been able to use ILE programs are where we need functions that are not available in OPM. We don\'t want to be on the bleeding edge of technology, you know.
David Abramowitz
I understand your sentiments concerning ILE implementation. OTOH I believe that after thirteen years of ILE being around, the bleeding has stopped. Dave
Guest.Visitor
The default activation prompt now showing when compiling SQLRPGLE (option 14 or 15) program. Do I have to manually insert it on H Specs. Thanks, TIKI
gantner
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
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.
Barbara Morris
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
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
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
"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.
Please login to make comments.
User Rating: / 1
PoorBest 

   MC-STORE.COM