ILE activation groups are not difficult to understand or to use, but some AS/400 programmers still seem to think they are. We asked veteran ILE RPG and COBOL programmer Mario Martinez to explain the nitty-gritty of activation groups in his own way. We hope his presentation of activation group fundamentals is helpful to many of you. For further reading, we recommend Don Denoncourt’s article “Activation Groups Demystified” (MC, November 1997) and Glen Sakuth’s “Everything You Ever Wanted to Know About Activation Groups” (MC, June 1995).
Making the most of the Integrated Language Environment (ILE) requires a mastery of the concept of activation groups. Activation groups allow applications to isolate data and system resources so that two or more programs can use the same object without getting in each other’s way.
Activation groups are not difficult to use. You can use activation groups in several different ways, and more than one strategy may be right for a given situation. If you understand a few fundamental ILE activation group concepts, your programs can use an activation group definition that will optimize application performance.
Getting Activated with ILE
The process of getting a program or service program ready to be executed is called activation. You activate a program or service program within an activation group, which exists inside a job.
When you create an ILE program, you determine in which activation group the program will run by how you fill in the Default activation group (DFTACTGRP) or Activation group (ACTGRP) parameters of the Create Program (CRTPGM), Create Service Program (CRTSRVPGM), and the various Create Bound Program (CRTBNDxxx) commands. A table listing these commands and information about their activation group- related parameters appears in Figure 1.
When you create a program, you must choose among several different activation group options. These options are the default activation group, a named activation group, the calling program’s activation group, and a temporary activation group. The option you
choose is important because it affects the creation and destruction of activation groups, which requires substantial system overhead.
For now, I’ll take a closer look at the different types of activation groups options available and what they can do for your applications.
Default Activation Group
When a job begins, it has one activation group, called the default activation group. All Original Program Module (OPM) programs run in the default activation group. ILE programs run in the default activation group if they are compiled to do so. That is, DFTACTGRP(*YES) is specified in the appropriate CRTBNDxxx command, or the program is compiled to run in the caller’s activation group, and the caller is running in the default activation group.
Although it can be done, running ILE programs in the default activation group is not the most efficient option. In addition to slow performance, certain specific ILE features, such as issuing static calls and calling service programs, are not allowed in the default activation group.
Many times ILE programs are intentionally executed in the default activation group in order to maintain some program calling compatibility between OPM and ILE programs. It’s not my favorite method for using activation groups, but it works well in shops that run a mixture of OPM and ILE programs.
Given the defaults of some of the CRTBNDRPG and CRTBNDCL commands, it’s easy to put ILE programs accidentally into the default activation group.
Named Activation Groups
Named activation groups are created when you use a text value with the ACTGRP parameter of the particular ILE program creation command. For example, the following code will place ILE program ILEPGM into the QILE activation group when it is run.
CRTPGM(ILEPGM) .... ACTGRP(QILE)
QILE is a common activation group name because IBM uses this as the default value in the ACTGRP parameter. The name can be any permissible text value.
In general, I highly recommend using named activation groups for ILE applications because you have access to all the ILE functionality. This functionality includes the ability to issue static calls and call service programs.
The Caller’s Activation Group
When the ACTGRP value of *CALLER is used with the ACTGRP parameter of the ILE program (or service program) creation command, the called program uses the activation group that the calling program uses. This makes using *CALLER activation group quite versatile. If the calling program runs in the default activation group, the called program also runs in the default activation group. And, if the calling program runs in a named activation group, the called program also runs in the same activation group.
Temporary Activation Groups
When you use the ACTGRP value of *NEW with the CRTPGM or CRTSRVPGM command, then that program will use a system-generated activation group name every time it is called. When the program ends, the activation group is destroyed. This process takes a lot of system overhead and is not recommended except in special cases. For instance, using an activation group value of *NEW forces the job to allocate new and separate resources to that activation group. This ensures that the program does not use resources already in use by other programs within the job. Also, when an activation group is defined as *NEW, the ILE program can call itself.
Comparing the Options
To demonstrate what system overhead was for running programs under different activation groups, I ran some performance tests on the Midrange Computing’s AS/400.
The test application consisted of one RPG IV driver module that dynamically called three programs that used different activation group strategies and statically called a service program. All the called programs, including the service program, made a simple numeric assignment, and then returned to the caller program with the last record indicator left off. Each of these test cases was executed 10,000 times. The execution times using the different activation group options, in elapsed clock time, not CPU seconds, are illustrated in Figure
2. These numbers are relative. Performance can vary dramatically, depending on the system. If you are interested in how your system handles activation groups, I strongly encourage you to conduct your own tests. I drew the following conclusions from my tests:
• Avoid running ILE programs in the default activation group. Although it’s not the worst performing option, it’s not the best performing option, either—and it is the most limited.
• Static calls to the service program executed most quickly.
• Calling a program or service program that runs in the caller’s activation group is the best choice from a performance perspective.
• Running a program in a temporary activation group is the slowest method of all, due to the expense of creating and destroying activation groups.
Activation Group Resource Scoping
The performance aspect of the different activation group options is important, but even more critical is the fact that you can design an application so that its use of system resources will not affect other programs in the same job.
You can accomplish this by resource scoping. Resource scoping pertains to how applications use resources such as (but not limited to) database files, file overrides, and open data paths (ODPs). Resource scoping of the application will not conflict with other programs running in different activation groups.
The OS/400 commands listed in Figure 3 can help you manage activation groups. You can incorporate these commands into ILE CL modules. Experienced AS/400 programmers will recognize these commands because most of them existed before ILE. As ILE developed, these commands were modified to help applications interact with ILE activation groups.
Many of the OVRxxxF commands, such as Override with Database File (OVRDBF) and Override with Printer File (OVRPRTF), now support resource scoping by means of the Override scope (OVRSCOPE) parameter. The three possible values for this parameter are Job (*JOB), Call level (*CALLLVL) and Activation group definition (*ACTGRPDFN).
Using an OVRSCOPE value of *JOB means the resources will be scoped to the specific job running. The value *CALLLVL means resources will be scoped up to the level the program call was issued in the program call stack. If the OVRSCOPE value is *ACTGRPDFN, then the outcome depends on what activation group is being used. If the ILE application is running in the default activation group, call level scoping will take place. But if the program is not running in the default activation group, the resources will be scoped to the ILE activation group being used.
Implementing ILE Activation Groups with OPNQRYF
To demonstrate how to create and use activation group definitions, I created a small ILE application consisting of an ILE CL module (shown in Figure 4) and an RPG IV module. Figure 5 lists the commands to create the application. Notice that the OVRSCOPE parameter in the ILE CL module in Figure 4 has a value of *ACT-GRPDFN. This causes the file, printer, and open data paths to scope to activation group LPCOSTAG.
LPCostQry sets up the necessary file overrides and executes an Open Query File (OPNQRYF) command against a physical file named LPurchases. The OPNQRYF command selects records issued for one day.
OPNQRYF creates an ODP that the RPG IV service program LPAvgQry will use. Notice the CL module statically calls the RPG IV service program by using the Call
Procedure (CALLPRC) command. After the RPG service program prints a report, the CL driver module closes the ODP, deletes the file overrides, and executes the Reclaim Activation Group (RCLACTGRP) command to destroy the activation group. All of the commands issued in this ILE CL module were effective only within the activation group.
Because of space considerations, I’m not publishing the source code for the LPAvgQry RPG IV module, but it is available on Midrange Computing’s Web site (www.midrangecomputing.com/99/03). An ILE COBOL version is available as well.
Moving into the ILE Future with Activation Groups
I asked other AS/400 programmers on the MC Web site discussion forum (www.midrangecomputing.com/forums) how they were using activation groups. Their responses were proof that more than one activation group strategy is acceptable for the same application. Shop requirements differ considerably.
From my experience, and the experience of other programmers, I learned that, when you use activation groups in accordance with a few sound fundamentals, applications can use the resources they need without fear of interference from unrelated programs, with performance results being, generally, quite favorable.
References
“Activation Groups Demystified” MC, November 1997 AS/400 ILE Concepts V4R2 (SC41-5606-01, CD-ROM QB3AQ701) “Everything You Ever Wanted to Know About Activation Groups” MC, June 1995 ILE Application Development Example V4R1 (SC41-5602-00, CD-ROM QB3AQ400)
ILE RPG for AS/400 Programmer’s Guide (SC09-2507-01, CD-ROM QB3AGY01)
Moving to ILE RPG (GG24-4358-00, CD-ROM EZ324300)
Command Description DFTACTGRP ACTGRP parameter parameter? permissible values CRTPGM Create Program No name, *NEW, *CALLER CRTSRVPGM Create Service No name, *CALLER
Program CRTBNDC1 Create Bound No
C Program CRTBNDCBL Create Bound No name, *NEW, *CALLER2
COBOL Program CRTBNDCL Create Bound Yes name, *NEW, *CALLER2
CL Program CRTBNDRPG Create Bound Yes name, *NEW, *CALLER
2
RPG Program
1 The CRTBNDC command does not permit selection of activation groups.
2 Documentation for these commands also includes the value QILE, a default name for an activation group.
Figure 1: These are the OS/400 commands that use the Activation group (ACTGRP) parameter.
Program DFTACTPGM CALLERPGM NEWPGM CALLSRVPGM Call Command CALL CALL CALL CALLB Type of Call Dynamic Dynamic Dynamic Static Activation Group Default *CALLER *NEW *CALLER Number of Calls 10,000 10,000 10,000 10,000 Time (Seconds) 19 2 409 1
Figure 2: These are the relative performance statistics for using different activation group options.
Command Description Parameter Parameter name description DLTOVR Delete Override LVL Level OPNDBF Open Database File OPNSCOPE Open scope OPNQRYF Open Query File OPNSCOPE Open scope OVRDBF Override with OVRSCOPE Override
Database File scope OVRDKTF Override with OVRSCOPE Override
Diskette File scope OVRDSPF Override with OVRSCOPE Override
Display File scope OVRICFDEVE Override ICF Program OVRSCOPE Override
Device Entry scope OVRICFF Override ICF File OVRSCOPE Override scope OVRPRTF Override Printer File OVRSCOPE Override scope OVRSAVF Override Save File OVRSCOPE Override scope OVRTAPF Override Tape File OVRSCOPE Override scope RCLACTGRP Reclaim Activation ACTGRP Activation
Group group STRCMTCTL Start Commitment Control OPNSCOPE Open scope ENDCMTCTL End Commitment Control OPNSCOPE Open scope
Figure 3: Here's a list of the activation group related CL commands.
/*================================================================*/
/* */
/* To create : */
/* */
/* CRTCLMOD MODULE(*LIBL/LPCOSTQRY) SRCFILE(*LIBL/QCLESRC) */
/* */
/* Module - LPCostQry */
/* Purpose - ILE CL driver module that will execute an */
/* Open Query File (OPNQRYF) command within an */
/* ILE-named activation group. */
/* After the OPNQRYF command has completed, */
/* service program LPAvqQry will print out a */
/* report. */
/* */
/*================================================================*/
PGM
/* Override database file */
OVRDBF FILE(LPURCHASES) OVRSCOPE(*ACTGRPDFN) +
SHARE(*YES)
/* Override printer file, change user data to "LPCostQry */
/* hold and save spooled file */
OVRPRTF FILE(QSYSPRT) USRDTA('LPCostQry') HOLD(*YES) SAVE(*YES) +
OVRSCOPE(*ACTGRPDFN)
/* Execute OPNQRYF one day's purchases - 1998-11-29 */
OPNQRYF FILE((LPURCHASES)) QRYSLT('LPURDATE *EQ 19981129') +
OPNSCOPE(*ACTGRPDFN)
/* Execute static call to LPAvgQry service program */
CALLPRC PRC(LPAVGQRY)
/* Close the open data path */
CLOF OPNID(LPURCHASES)
/* Delete file overrides */
DLTOVR FILE(*ALL) LVL(*ACTGRPDFN)
/* Reclaim the activation group */
RCLACTGRP ACTGRP(*ELIGIBLE)
END_PGM:
ENDPGM
Figure 4: This ILE CL driver module handles activation groups using resource scoping.
Create Modules :
CRTRPGMOD MODULE(xxx/LPAVGQRY) +
SRCFILE(xxxx/QRPGLESRC)
CRTCLMOD MODULE(xxx/LPCOSTQRY) +
SRCFILE(xxxx/QCLSRC)
Create RPG IV Service Program :
CRTSRVPGM SRVPGM(xxx/LPAVGQRY) +
MODULE(xxx/LPAVGQRY) +
EXPORT(*ALL) +
ACTGRP(*CALLER)
Create ILE Program :
CRTPGM PGM(xxx/LPCOSTQRY) +
MODULE(xxx/LPCOSTQRY) +
BNDSRVPGM(xxx/LPAVGQRY) +
ACTGRP(LPCOSTAG)
Figure 5: Use these CL commands to create the example ILE application.
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