One of the pieces of contemporary RPG is the ILE version of CL, or CLLE. Unlike RPG, however, CL didn't have a syntax change in the ILE program model. In fact, only one new CL command has been added in the CLLE. This new command, CALLPRC, allows you to call procedures and receive a return value back from those procedures.

But in the days of "CLP," CL programs were simple, one-to-one relationships. That is, one CLP source member equated to one CL program. This is, of course, the same program model used by the old RPG III language.

Today, CLLE supports multiple source members per program, and a CLLE source member equates not to a program but rather to a module, which is virtually identical to the way RPG IV for ILE is designed.

You can create modules, programs, and service programs from CLLE source members (I'm not sure what good it is to store ILE CL modules in a service program, however).

The CRTCLMOD command is use to compile CL. Of course, if you're using PDM to compile, as nearly everyone is, then PDM option 15 is used to compile CLLE source members into *MODULE objects. You can also use PDM option 14 to generate a *PGM object from CLLE source.

Unlike RPG IV, however, CLLE does not have syntax that allows you to create multiple procedures in the same source member. Instead, it permits only one procedure per source member. It does this using a one-to-one-to-one-to-one relationship between the source, module, procedure, and program.

Figure 1 contains an illustration of how CLLE goes from a source member to a module to a program.

Figure 1: CL source, module, and program relationship

We are all familiar with the structure of a CL source member. The first line is the PGM statement and the last line is the ENDPGM statement. The CLLE compiler uses this as a boundary for procedures written in CL. Since we can currently specify only a single PGM/ENDPGM pair in the source for CL, the compiler is inhibited when it generates the *MODULE object (the middle graphic in Figure 1). It generates exactly one procedure; never more, never less.

The structure of a module, therefore, contains just the one procedure. The procedure name is the same as the CL source member name, which is also the same as the module name. Figure 2 illustrates the structure of a *MODULE object created from a CLLE source member.

Figure 2: CL module structure

You have no control over the procedure name in CLLE; it is always the same as both the module and the source member name.

Of course, the name and structure doesn't really matter unless you are going to create a *PGM object from multiple programming languages, such as RPG IV, C, and CLLE.

For example, if you have an RPG IV source member with three procedures in it, when it is compiled, you end up with a module structured like the one illustrated in Figure 3.

Figure 3: RPG IV module with three procedures

If you combine a CL module and an RPG IV module, you end up with a program similar to what is illustrated in Figure 4.

Figure 4: Bound program with two modules

In Figure 4, the module named MYRPG is an RPG IV module. The other module, named MYPGM, is the CL module that is illustrated in Figure 2.

The RPG module has three procedures, MYPROC1, MYPROC2, and MYPROC3. The CL module has one procedure named MYPGM.

Calling Procedures in CL

The ability to call procedures was added to CLLE with the CALLPRC command. The command allows you to call procedures, written in any ILE-targeted language, from within CL.

The syntax for the CALLPRC command is identical to the CALL command with the exception of the RTNVAR parameter. This parameter is used when the called procedure returns a value to the caller. The return value is stored in a CL variable specified on the RTNVAR parameter.

For example, to call a procedure named MYPROC2 that returns a logical value ('1' or '0'), the following CLLE source and CALLPRC command would be used.

Unfortunately (or fortunately, depending on your philosophy), CLLE does not have the prototyping capability that C and RPG IV have. Therefore, if you specify incorrect parameters, you won't know about it until runtime, when the CALLPRC blows up.

The following is a simple, one-procedure RPG IV source member that contains the procedure GetDOW(). This procedure will be called from the CL module that follows:

To call the GetDOW() procedure from CL, the following CLLE source can be used:

Once the CALLPRC returns, the &DAYOFWEEK field contains the day of the week as a number, from 1 to 7.

Note that I quoted the procedure name. This is required when the procedure name is not mixed case. Usually, RPG IV procedure names are always uppercase, so GETDOW and 'GETDOW' are identical.

When using CLLE, consider the CALLPRC command as an option for integrating RPG IV procedures with CL to make things easier.

Bob Cozzi has been programming in RPG since 1978. Since then, he has written many articles and several books, including The Modern RPG Language--the most widely used RPG reference manual in the world. Bob is also a very popular speaker at industry events such as RPG World and is the author of his own Web site and of the RPG ToolKit, an add-on library for RPG IV programmers.

Bob Cozzi is a programmer/consultant, writer/author, and software developer. His popular RPG xTools add-on subprocedure library for RPG IV is fast becoming a standard with RPG developers. His book The Modern RPG Language has been the most widely used RPG programming book for more than a decade. He, along with others, speaks at and produces the highly popular RPG World conference for RPG programmers.

---

MC Press books written by Robert Cozzi available now on the MC Press Bookstore.

		RPG TnT Get this jam-packed resource of quick, easy-to-implement RPG tips! List Price $65.00 Now On Sale
		The Modern RPG IV Language Cozzi on everything RPG! What more could you want? List Price $99.95 Now On Sale

Also Read

Programming in ILE RPG - Defining Data Structures, Part I

H and F Position-less Specs

Practical RPG: AI and IBM i