Over the past 20 years, ILE for RPG has gone from being something new and startling to being almost legacy. Lots of us are now using RPG ILE concepts on a regular basis. But what about CL? Can it be ILE too?

Everyone knows about ILE for RPG.

Or at least everyone knows how to spell it, and a lot of people have adopted ILE practices as part of their regular routine. But I don't think the same can be said for CL. While most of us are now doing our programs in QRPGLESRC versus QRPGSRC, how many of those same people are still using QCLSRC for their Command Language source? My guess is quite a few.

But CL has an ILE side to it, one that has not gotten nearly as much press as its RPG cousin, and it's about time we took a look at it.

The Source File

The most obvious reminder that you're doing ILE is the naming of the source file where the programs are being kept.

On the RPG side of the house, we used to keep things in QRPGSRC, but now most people are doing their new program development in QRPGLESRC. And there's a CL parallel there. You can create a QCLLESRC source file, just like your RPG counterpart, and put your new CLs in it. This would be a 112-byte record versus the 92-character record that is being used currently in QCLSRC.

The object type in this new source file will be CLLE versus CL from the OPM type of source file.

One question that's liable to come up is "What do I do with my old QCLSRC CLs?" Many people will leave them in the current file and just put any new ones in the QCLLESRC file. The problem with that is now if you're looking for a CL and you don't know which of the two files it's in (and that can happen quicker than you think), then you have to check both source files. And that can get annoying. Unlike the RPG situation where you had to go through a conversion, you can just move your CLs from QCLSRC to QCLLESRC and recompile them in the new source file. That way, you always have everything together, and everything compiles as ILE. When you do the move, it will automatically reformat the CL into the 112-byte record and also automatically change the object type from CL to CLLE. What could be simpler?

Compile Commands

Of course, what makes a program ILE is not what source file it's stored in but rather the compile command that creates its object.

So, in RPG, OPM objects were created by the CRTRPGPGM command. It did not have any information in it about activation groups or binding, things that are central to the ILE experience.

And the situation is pretty much the same in CL. Up to this point, the default compile command was CRTCLPGM, and the object created was a straight OPM CL with no ILE icing.

To activate the ILE functionality in CL, you have to use either CRTBNDCL or the CRTCLMOD/CRTPGM combination. Both of these commands have a spot to determine if you want to use the default activation group (*DEFACTGRP = *YES or NO) or enter what activation group you want to use (*ACTGRP).

The interesting thing is that if you're still using PDM, then the commands associated with the 14 and 15 options are set based on the value of the object type. If it's CL, then it defaults to the OPM compile command, CRTCLPGM. But if you have set things up in QCLLESRC and the object type is CL, then the default for 14 is CRBNDCL, and for 15 CRTCLMOD.

Calling a CL Program from an RPG Program

Let's start with the simplest direction. You're in an RPG ILE program and you want to call an ILE CL program (or even an OPM CL program).

To do so, simply set up the Prototype D-spec (PR) for the name of the CL and the parms that need to be passed into it to get it to run.

D clname       PR        EXTPGM('clname')

D   Parm1           5    

D   Parm2           10  

Then add in the CALLP and call the CL.

CALLP 'clname' parm(Parm1: Parm2);

No changes or special setup are required. So it's pretty simple.

Calling a Subprocedure from a CL Program

There isn't nearly as much difference in the ILE version of CL as there is in RPG, which might be one reason that people haven't really embraced CL ILE the way they have RPG ILE.

But there's one new command that allows you to call a procedure from within an ILE CL program. This is the CALLPRC command. Basically, it looks like this.

Callprc prc('name of procedure')  +

       parm(&parm1 &parm2)       +

       rtnval(&field1)

Obviously, &Parm1k, &Parm2, and &Field1 must be defined in the CL.

The parms passed (&Parm1 and &Parm2) must match those of the PR in the procedure being called.

What is the rtnval (return value)? Good question. One parm that does not show up on this call is the parameter value parm, which defaults to "by reference." Hence, if you just use the defaults with this command, the parms that are passed are passed by reference, not value. As a result, any changes to &Parm1 and &Parm2 aren't returned to your CL program. This is just as it is in PHP, so if you're doing any coding in that area, this won't seem so weird. The upshot is that if you want to get any information back from the subprocedure, it will come back through the rtnval field (&Field1 in our example.

Need more than one field returned? Can't. You're limited to one field. But that field could be the concatenation of several fields, which you could then take apart once you get back in the CL.

Or you could just change the default on the parm value so that it sends things over by value, not by reference.

There's one very important caveat with respect to the CALLPRC command. If you're on a release below 6.1 and you put the CALLPRC command in a QCLLE, to get the CL to compile, you need to do CRTCLMOD and CRTRPG. Running just CRTBNDCL won't work. If, however, you're on 6.1 or above, using CRTBNDCL will work just fine.

Use as Directed

We still haven't answered the question of why more people don't use ILE techniques as much with CL as they do with RPG. And much of that may relate to how many people use CL.

CL is used mostly to run functions that aren't called directly from a menu or another app interface, things like reports, or SQL queries. And often that turns out to be a one-on-one type of situation; a given CL program will kick off one incidence of one or more output modules. You often just don't get the calling frequency that makes ILE worthwhile, cases where you're repeatedly calling a CL program from an RPG program or calling one or more subprocedures repetitively from a given CL program.

But the capabilities are there and available for you to use them. So keep an eye out for situations where this information could be of use. After all, CL and RPG both have specific situations that they're best for, so you might as well be ready to take advantage of it. Can't hurt.

David Shirey is president of Shirey Consulting Services, providing technical and business consulting services for the IBM i world. Among the services provided are IBM i technical support, including application design and programming services, ERP installation and support, and EDI setup and maintenance. With experience in a wide range of industries (food and beverage to electronics to hard manufacturing to drugs--the legal kind--to medical devices to fulfillment houses) and a wide range of business sizes served (from very large, like Fresh Express, to much smaller, like Labconco), SCS has the knowledge and experience to assist with your technical or business issues. You may contact Dave by email at This email address is being protected from spambots. You need JavaScript enabled to view it. or by phone at (616) 304-2466.

---

MC Press books written by David Shirey available now on the MC Press Bookstore.

		21st Century RPG: /Free, ILE, and MVC Boost your productivity, modernize your applications, and upgrade your skills with these powerful coding methods. List Price $69.95 Now On Sale

Also Read

TechTip: Printing from a CL Program (the PRTLN Command)

TechTip: Date Arithmetic in CL Programs

TechTip: Entering Quotes in CL Variables — A Better Way?