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:
- To provide an easy way to clean up (reclaim) program storage and close files associated with a specific group
- 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.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online