13
Wed, Nov
5 New Articles

Practical RPG: Activation Groups and *INLR

RPG
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Although they've been around for quite a while, activation groups remain something of an enigma; this article will begin to dispel that mystery.

 

When RPG ILE was introduced back in 1994, it really consisted of two entirely different components: syntactical changes to the RPG language itself, and the larger underlying change of the entire programming model with the introduction of the Integrated Language Environment (ILE). As usual, IBM did a good job of hiding the complexities of the fundamental architecture change (CISC to RISC, anyone?). So good, in fact, that for a lot of us more "seasoned" programmers, the ILE concepts sort of got overshadowed by the syntactical changes. A lot of it was practical: we got a lot more out of learning the new built-in functions (BIFs) than we did out of activation groups. But I think it's high time that we all learned what activation groups can do for us, and there's no easier way to start than with a simple, practical example.

Effective Use of *INLR

*INLR, the last record indicator, has been an effective tool for decades. I've taken advantage of this particular feature since my System/38 days. By leaving *INLR off when returning from a called program, the next call to that program is significantly faster. The primary underlying reason for this is that the program doesn't get re-initialized. And while speed is a principal benefit of this process, the technique also provides a number of potentially powerful side effects. For example, files stay open and variables keep their values between calls. This can be very powerful.

 

Let's take a simple example. Let's say I have a file with a small number of records with relatively static contents—contents that would be expected to stay the same for the lifetime of a job. An example might be a set of business rules or perhaps a template for formatting output. In either case, the database might change between runs of the job but not during a single run. During the job, these records will be accessed over and over again. Rather than access the file directly, this is an excellent opportunity to use a preloaded table. I call a program to get the appropriate data from the table, and the first time I call the program, I read the entire file into an array of data structures. From that point forward, anytime I need one or more records from the file, I just do a quick lookup in the array. Simple and very efficient.

 

And this isn't the only example of returning without setting on LR. Another case might be calling an RPG program to return a list of records. RPG isn't particularly good about handling dynamic arrays, but languages like Java and EGL are, so one of the design patterns I use throughout my multi-tiered applications is to write a service routine (in the Java/EGL layer) that calls the RPG program in a loop. The first call sets the initial keys and attempts to retrieve a record, while subsequent calls return additional records until I hit the end of the list. By not setting on *INLR, I simply need to do a READE (for RPG; I would use a FETCH NEXT when the program is written using embedded SQL). Each additional call requires literally milliseconds, so I can populate lists quickly and easily. Imagine the overhead of a stateless session in which I had to send a key each time, opening a file (or worse yet, a cursor) and then fetching the next record. A stateful approach will perform far better.

Cleaning Up at Closing Time

So what's the downside to this technique? Probably the biggest problem is file locking. If you never end the program, the file will have an object lock that could affect other processes. Another issue is that sometimes you do have to re-initialize the program, which means you have to force the end of the program.

 

Each problem is more or less prevalent depending on the application, and solutions exist for each one. For example, table preloads can reasonably close their primary files after loading the tables; this gets around the record lock issue but not the re-initialization. Query programs can set on LR when they hit end-of-file; while it does add some overhead, it may not be significant, especially if the program is embedded SQL with an expensive initial cursor build. But in general, the best solution is to have a way to signal to those programs that they should shut down by setting on LR and exiting.

 

The easiest way I've found for this is to use the parameter list. Let's say I have a program called CHKCTRY that checks a country code against a table and does not set on LR. I have an order entry program ORDENT that calls CHKCTRY. When ORDENT ends, I make one additional call to CHKCTRY with no parameters. CHKCTRY has this code at the beginning of its mainline.

 

       // Check for shutdown request

       if %parms = 0;

         *inlr = *on;

         return;

       endif;

 

If no parameters are passed, set on LR and get out. Very simple and neat. I suppose this wouldn't work if the called program had no parameters, but then again I rarely call subprograms that don't require parameters. Even if I did, I could reverse the logic: if I do pass a parameter, then I set on LR and exit. Anyway, you get the idea: a special last call will shut down the stateful called program.

 

The problem is that I need to add that last call. And as I add more and more subprograms, I have to add a bunch of additional calls. It gets even worse if those programs call other programs! In fact, I had a whole utility system in which programs would register themselves with a called program controller, and when the main program ended, it would call the controller, which would in turn call each of the registered  subprograms and tell them to shut themselves down.

Enter the Activation Group!

All of that complexity goes away with the activation group. In many ways, an activation group is a subset of the job, and when you shut down the activation group (an operation known as "reclaim" in ILE terminology), all of the programs within the activation group shut down as well. It's as if each program is set on LR and returned: files are closed, and on subsequent calls to the program, all variables are reinitialized. It's the exact equivalent to the LR technique we used in the pre-ILE days but cleaner and easier. I don't have to keep track of all the called programs; the operating system does that for me.

 

Implementing the activation group technique requires basic knowledge of ILE. I won't spend much time on the theory; instead I'll just give you a concrete example along with an explanation of how it works. I like to use one specific activation group technique: *NEW and *CALLER. In this architecture, the main program is compiled with the attribute of ACTGRP(*NEW), and whenever that program is called (typically from a main menu), the operating system creates a new activation group. All of the called programs are compiled with the attribute of ACTGRP(*CALLER) so that they inherit the activation group of the main program. When the main program ends, it sets on LR and exits, which triggers the reclamation of the activation group that was created when the main program was first called. This in turn shuts down each of the called programs. Simple, efficient, and automatic. I like that.

 

The other type of activation group used in ILE programming is the named activation group. The technique outlined here works with a named activation group, provided all the called programs were either in the same activation group or were marked as *CALLER. The problem is that you have to explicitly reclaim named activation groups. It's not difficult, but it's yet one more thing you have to name and keep track of, and try as I might, I can't understand why someone would go to that trouble if they didn't have to.

 

Let me leave you with a note of caution: a final twist is the so-called "default activation group"; this is the activation group where non-ILE (also known as Old Program Model, or OPM) programs run. It's a bad neighborhood for ILE programs, so we'll avoid it whenever possible. Even so, it's relatively easy to protect yourself: the only way you can really get yourself into trouble is if your OPM programs call ILE programs compiled with ACTGRP(*CALLER). Don't do it!

 

Thanks for letting me introduce you to activation groups. It's a first step into the world of ILE, and I hope I can provide you more guidance in the future.

as/400, os/400, iseries, system i, i5/os, ibm i, power systems, 6.1, 7.1, V7,

 

Joe Pluta

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been extending the IBM midrange since the days of the IBM System/3. Joe uses WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. He has written several books, including Developing Web 2.0 Applications with EGL for IBM i, E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..


MC Press books written by Joe Pluta available now on the MC Press Bookstore.

Developing Web 2.0 Applications with EGL for IBM i Developing Web 2.0 Applications with EGL for IBM i
Joe Pluta introduces you to EGL Rich UI and IBM’s Rational Developer for the IBM i platform.
List Price $39.95

Now On Sale

WDSC: Step by Step WDSC: Step by Step
Discover incredibly powerful WDSC with this easy-to-understand yet thorough introduction.
List Price $74.95

Now On Sale

Eclipse: Step by Step Eclipse: Step by Step
Quickly get up to speed and productivity using Eclipse.
List Price $59.00

Now On Sale

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More 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.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY 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.

  • SB HelpSystems ROBOT GenericForms 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.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA 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:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA 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.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra 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: