You've all read about recursion by now, but have you found uses for it? I'm going to discuss a couple of uses I've found.

What Is Recursion, Again?

With the number of articles written about recursion out there, I'm not going to get deeply into what it is. Here is a brief overview:

There are two types of recursion: Direct recursion occurs when a program or procedure calls itself. Indirect recursion occurs when a program or procedure calls another program or procedure already running higher up in the invocation stack, thus starting an additional invocation of the called program. For example, Program A calls Program B, Program B calls Program C, and Program C calls Program A.

So What's It Good For?

The articles you've read usually touch on two applications for recursion. First, of course, is the classic factorial problem. A recursive definition of n! is n * (n-1)!. Within a Factorial subprocedure, this would result in a recursive call:

Then, for a business application, the articles exemplify Bill of Material (BOM) explosion. As a BOM procedure is listing the components of a product, recursion is used to explode the components of a component.

So what else can recursion be used for? Well, here are two ways we use it at my shop.

Direct Recursion and Nested Lists

We have an automated email system. Various programs generate email and then call an emailing program to send the email to a primary recipient. These programs may also send a name of a distribution list of carbon copy recipients. A distribution list contains a combination of actual email addresses, vendor IDs (the emailing program will go to the vendor master to get the address), and/or special instructions for deriving a recipient. The emailing program will send the email to those recipients listed in the distribution list.

Now, one other item these distribution lists may contain is instructions to send the email to the recipients in another named distribution list. And then, that distribution list may have instructions to send the email to the recipients in yet another distribution list. The best way to handle these nested distribution lists? You got it! Recursion.

The distribution list processing subprocedure in the emailing program is initially called with the name of the distribution list sent to the program. The subprocedure reads through the distribution list file and processes each entry. If the entry is an instruction to process another distribution list, the subprocedure recursively calls itself, passing the name of the nested distribution list. And so on and so on.

Because the subprocedure reads a file, it must save the current record pointer before the recursive call. Since files are globally defined, there is only one open data path used by all invocations of the subprocedure.

Indirect Recursion and Automatic Production Scheduling

As my company's products are constructed, phases of the construction can be either scheduled or completed. When phases are scheduled or completed, our system automatically schedules future phases of construction. For example, when Phase A is scheduled, Phase B and Phase C are scheduled automatically. Here's the thing: The scheduling of Phase B may also trigger automatic scheduling of other phases. Then, the automatic scheduling of those phases may trigger the scheduling of still other phases. The scheduling of Phase B may trigger the scheduling of Phase D, which then triggers Phase E. Meanwhile, Phase C may trigger Phase F.

Recursion again. This time, we have an indirect recursion solution. We have two programs (they really should be subprocedures, but they aren't yet). "Schedule" schedules a phase. "AutoSchedule" processes the automatic scheduling of phases triggered by the phase passed to it. You can see where this is going: To schedule Phase A, we send Phase A to "Schedule." "Schedule" schedules Phase A and then calls "AutoSchedule" to automatically schedule phases triggered by Phase A. "AutoSchedule" sees that Phase B must be scheduled. How does "AutoSchedule" do that? It calls "Schedule" recursively, sending it Phase B. And "Schedule," after scheduling Phase B, calls "AutoSchedule" to automatically schedule phases triggered by Phase B. And so on and so on. These two programs keep calling each other until all phases that should be scheduled are scheduled.

Now, it is common knowledge that, on the iSeries, programs cannot be recursive. That's mostly true: OPM programs and ILE programs within the same activation group cannot be recursive. For a program to call itself, directly or indirectly, the recursive invocation of the program must be in a different activation group. So "Schedule," "AutoSchedule," and any recursive program, are compiled with ACTGRP(*NEW). Each invocation of the program will be started in a new activation group, and recursion will be possible. Take Note: This is a big, resource hogging performance hit!

These new activation groups mean that each invocation of a program will have its own open data path to a file, unlike subprocedures.

Another Use for Recursion: Unique ID Incrementer

Browsing through the forums on Bob Cozzi's Web site one day, I came across a question from a programmer who was looking for a way to write a procedure that would increment a unique ID. This wasn't a simple numeric ID he wanted to increment. His ID was alphanumeric, containing sequences of just letters in some positions of the ID, letters and numbers in others, and just numbers in still others.

Think of a license plate in the form of xxxnnnn, with xxx being letters and nnnn being numbers. The sequence would be AAA0000, AAA0001...AAA9999, AAB0000...AAB9999, AAC0000...AAZ9999, ABA0000...ABA9999, ABB0000...AZZ9999, BAA0000 all the way to ZZZ9999. This was the type of ID the poster wanted to increment.

Well, this is another prime example of recursion at work. Here's a subprocedure that would increment our license plate:

The prototype:

@String is the string that is to be incremented. How you define this is up to you. For this example, String is seven characters. @Char is the character position in the string to be incremented. When it is not passed in--as in the case of the initial call--it will be the last (rightmost) character.

A call to the procedure:

The procedure:

1. rString will be the result string that is returned.
2. Here, if the string is at the last possible value, we will return the first possible value.
3. Here, we process the optional second parm, which indicates which string character will be incremented. On the initial call, when it is not passed in, it will be set to the last (rightmost) string character position--the length of the string.
4. Here, we determine the sequence to be used for the string character. For our license plate, characters 1,2, and 3 are letters, and characters 4 through 7 are numbers. You can define any sequences or combination of sequences that you like to each character position.
5. Here, we put the passed-in string into the result string.
6. Here, we find the position of the string character within the sequence.
7. Now things get interesting: 1) If the string character is the last character in the sequence, we set the string character to the first character in the sequence. Then, we pass the string to a recursive call of Incr. Note that this call is passing the second parm--the preceding string character position. 2) Otherwise, we set the string character to the next character in the sequence.

Recursion is a powerful programming technique that has many uses beyond factorials and Bill of Materials. With some imagination, you can find uses for recursion in your own programming.

Doug Eckersley is the iSeries programmer with a premier homebuilder in Columbus. He has been programming on the iSeries for 10 years and has been in the business for 15. He is certified by IBM. As an exchange student host father, he has kids all over the world.