This month, I am going to take a look at an area of RPG programming I have been vaguely aware of but I have never really had the opportunity to use. During an interview for a job, and in an effort to impress, I said that I had used it in the past, without really knowing that much about what I was talking about. Naturally, I was questioned about what I had said and I managed to explain my mistake, but that was my first realisation that there was more to RPGLE than using an EVAL statement instead of MOVE, and having more characters available for subroutine names.

The ILE (or Integrated Language Environment) has been around for over ten years, yet many System i users still consider it new technology. The primary reason, I believe, is that in its theory, it is quite different from what we are used to, but I would also say that a lot of end-users still believe that ‘if it ain’t broke, don’t fix it’, and why bother converting lots of code when the code we have works OK.

After my interview, I  looked into ILE briefly and there were activation groups, binding directories, modules and service programs; all these new concepts in RPG to consider while I was learning the intricacies of Java and JSPs. Now, I had started off learning Java skills by looking at the Java for RPG programmers articles on the System i Network website and that gave me another glimpse of RPGLE. The comparisons introduced there between ILE modules and procedures with Java classes and methods were ones that stuck with me during my training and now that I am looking into ILE RPG, the comparisons make a lot of sense. Perhaps you will see how we can step away from the traditional methodology behind RPG design and programming, and maybe move to more agile-based development.

So, what is RPGLE and how does it differ from RPG III? To call the programming language RPGLE is really a mistake, as I found out in my interview. If you tag an LE to the end of the name, the program type indicates that the code can be run in an ILE environment. So can RPGLE be considered as the compiler that allows RPG IV code to be run in an activation group other than the default one? And what is an activation group anyway, and why is it important that you run ILE programs outside the default one?  

Well, according to American System i guru and author Joel Cochran, an activation group can be considered to be ‘…a container for memory and other resources…this container is considered to be a “substructure of a job”.’ You use an activation group every time you run a program, even if you’re not using the ILE. Next time you compile a normal OPM program have a look at the parameters in the CRTBNDRPG command. One of these is the DFTACTGRP parameter and the default value for this (*YES) indicates that your program is to be run in the default activation group.

The other value for this allows you to specify one of several activation groups, which then allows you to get right into ILE programming. As a simple example, setting DFTACTGRP = *NO and changing your activation group to *CALLER allows you compile your programs (or rather, modules) for use in an ILE environment. This gives you the ability to call other programs or modules written in many other languages, such as C++, Java, COBOL and CLLE (simply CL for the ILE environment). 

Now, what makes the ILE so special is that you can bind two or more modules, perhaps written in different languages, together into a single program: a bit like using the CALL op-code in a regular program to join one program to another.  When you use a CALL operation, though, neither program knows about the other until the CALL occurs. This is known as dynamic binding, and it is supported in the default activation group. However static binding is the method by which you join the objects together before they ever use each other, and is not supported within the default activation group. 

The main problem with dynamic binding is that it can be very heavy on resources. Every call to a program must go through certain program resolution and start-up tasks, which can obviously be cut down if there is no binding whatsoever, but the problem with this is that it leads to huge unwieldy programs with no real effective code reuse. In order to encourage more modular programming, and to cut down on the overheads related to dynamic binding, we now have static binding, and if you want to read more, there’s a great article at www.itjungle.com/mpo/mpo031402-story02.html. 

So, to recap, an activation group is a part of a job and if we compile a module outside the default activation group, we can subsequently bind it to other modules in order to create a larger program from several smaller ones. There is a lot to get into if you really want to know more about activation groups, so Cochran explains more at http://www.itjungle.com/fhg/fhg021104-story01.html.

I previously mentioned modules. You can consider a module the equivalent of an ordinary OPM program in ‘normal’ RPG. When you CRTBNDRPG, you will see in the job log that the compiler actually creates a module before creating a program. A module is really a collection of procedures (more accurately known as subprocedures) that carry out functions, store values and produce output. If you consider your ‘normal’ OPM program again, you could equate subprocedures to the subroutines that you code now.

There is one major difference, though, and it is the key to understanding the concepts behind ILE. A subprocedure has an interface and a subroutine does not and this allows you to bind the subprocedure, as I mentioned earlier. You define the subprocedure using a new RPG spec, known as a P-spec, with a beginning and an end (a bit like the BEGSR and ENDSR op-codes), but also with an interface, allowing it to be called within a module or by other service programs (another term I will come back to shortly). This interface should detail the input parameters and any return values, and should be named well. The subprocedure could potentially be called from many different callers and, as with Java classes, taking time to name it will make it much easier to use in the future. Craig Pelkie has some really useful information on subprocedures and parameters here on his website at http://www.web400.com/download/ilerpg.

The fact that a subprocedure has a defined interface with parameters and return variables means that the compiler knows how to bind it to other subprocedures and modules. The subprocedure can exist within a module to be called exclusively by that module, but you can also put a few of them together into another program, called a service program, to be made available to any other program that the service program is bound to. This is when it starts to get fun.

Service programs are basically collections of subprocedures with defined interfaces, or prototypes, which can be bound to other service programs or modules, thus providing a fully modular application in accordance with how programs should be designed today. They also provide us with a great way to maintain the application, because if we had a bug in one of our subprocedures, and we had bound this module to every program that needed to use it, then if we changed the subprocedure, we would have to update every program we had used the module in.

Service programs allow us to group modules together in order that we may bind the whole group, but also allow us to update any program that uses the module by simply updating the service program. So if we change one of the subprocedures, we can update the service program and all the programs that use it will be updated automatically. Of course, problems may still occur if the procedure interface or prototype is altered. You will need to recompile any program that uses the procedure in order to pick up the new prototype. 

So there we have it; a very basic introduction to ILE concepts including activation groups, service programs and subprocedures. As I learn more about this subject, I will keep you informed. Already I have come across more and more ILE code in articles on API programming and within some of the latest ATS courses which I may get to reviewing in a later article. There is a lot more for me to learn but I am looking forward to it.

This article originally appeared in the January, 2007, edition of System i NEWS UK magazine