Brief: ILE is IBM's vision for the future of AS/400 application development. V3R1 includes a new compiler that brings CL into the family of ILE-compliant languages. This article tells you what you need to know to get started using ILE CL right away.

In V2R3 of OS/400, IBM introduced the concept of the Integrated Language Environment (ILE). One of the main reasons it developed this environment was to increase the performance of applications that use multiple programming languages. However, in that release the only ILE language available was ILE C/400. Now that V3R1 is available, new ILE languages are beginning to emerge, such as the long-awaited ILE RPG/400 and the soon-to-be-released ILE COBOL/400. But, without much fanfare, IBM has also rolled out another ILE language-ILE CL.

ILE CL is a significant step in the evolution of ILE since most applications contain some CL code along with another language. What this means is that you'll be able to write a single executable program that contains CL and andother language (e.g., RPG) RPG in the same program object. This has the potential to greatly increase the performance of certain types of application programs. In this article, I'll explain some of the benefits of ILE CL and show you how to implement it on your system. (For additional information on ILE, see "The Integrated Language Environment," MC, May 1993 and "An Introduction to Program Binding," MC, August 1994.)

ILE Benefits

One of the biggest advantages of ILE is that it significantly improves the performance of modular applications. The result from a design viewpoint is that you can break down your applications into small reusable modules without the overhead normally associated with external program calls.

This modular design means that your applications will tend to be easier to maintain and higher in quality. In a large program it's often difficult to determine the program logic. Smaller pieces of code are easier to understand. They're also easier to test and debug. If you make a change to a large program, you may inadvertently introduce errors in another part of the program. This is less likely to happen if you're only dealing with a single routine at a time. Also, compile time is often reduced since you may only need to recompile a single module rather than an entire program.

Another advantage of ILE is that IBM ships OS/400 with a collection of off-the- shelf ILE routines that you can incorporate into your programs. These routines are in the form of bindable APIs. Using these APIs, you'll have access to date and time routines, advanced mathematical calculations, and routines to perform dynamic screen manipulation. In the future, IBM will add new routines to this collection and you may be able to purchase sets of routines from third-party vendors.

ILE Concepts

Before jumping into the details of ILE CL, I'll give you a little background information on ILE concepts. When you compile a source member using an ILE compiler, it doesn't create a program. Instead, it creates a non-executable object called a module. You can then combine multiple modules created in different languages into a single executable program. There are two types of ILE programs you can create. One is the familiar program (*PGM) object and the other is an object type unique to ILE, called a service program (*SRVPGM). Both types of programs consist of one or more modules. Each module is made up of one or more procedures. A procedure is the result of binding a module into an ILE program using either the Create Program (CRTPGM) or Create Service Program (CRTSRVPGM) command.

With ILE CL, and most other ILE languages, a module can only contain one procedure. In this case, the module and procedure both have the same name. For this reason, the terms module and procedure are often used interchangeably. Currently, only an ILE C/400 module can contain multiple procedures.

When you use the CRTPGM command, you can specify the names of the modules you want to bind together. A copy of each module is created in the resulting program. This is called static binding (also known as bind by copy). With static binding, if two or more programs use the same module, then each program contains a copy of the module. This is a rather cumbersome method since you may end up with many copies of a module throughout your application. It can also make application maintenance difficult because, if you change a module, you'll have to update or recreate each program that uses that module.

A better approach is to create a service program. In this case, the module is only copied once. From then on, any ILE program can access the service program when it needs to execute one of its procedures. This is called dynamic binding (also known as bind by reference). Using this method, there is only a single copy of the executable code on the system. If you need to modify the code, you only need to replace it once in the service program and the programs that call it use the new copy without being updated or recreated.

ILE CL

Now that you've seen some of the benefits and concepts of ILE, I'll explain how ILE CL is implemented on the AS/400. ILE CL source code is stored in a source member with a member type of CLLE. After entering the source code, compile it with the Create CL Module (CRTCLMOD) command (or use option 15 against a CLLE member type in PDM).

To create an executable program you'll also need to run the CRTPGM command (or use option 26 against a *MODULE object in PDM). Here you specify the names of the modules used in the program. You can also specify the name of a service program that contains additional modules. If your program only has one module, you can combine this two-step process by using the Create Bound CL Program (CRTBNDCL) command (or running option 14 against a CLLE member type in PDM). This creates an executable program from a source member without requiring you to create the intermediary module object.

As an alternative to creating an executable program, you can place one or more modules into a service program. This gives other ILE programs access to those modules. To allow an ILE program to execute the procedures in a service program, specify the name of the service program in the BNDSRVPGM parameter of the CRTPGM command when you create the ILE program.

If a module already exists in a program or service program and you simply want to replace it with a newer version, you don't always have to recreate the program or service program. You can use the Update Program (UPDPGM) command to replace one or more modules of an ILE program with other modules on the system. Similarly, you can use the Update Service Program (UPDSRVPGM) command to replace modules of an ILE service program.

ILE CL Procedures

As I mentioned earlier, a procedure is created when you bind a module into an ILE program. You can think of these procedures as being similar to subroutines; they're small pieces of executable code within a program. When you want to execute one of these procedures from within a CL module (whether it's in the same program or an external service program) use the Call Bound Procedure (CALLPRC) command.

When you prompt the CALLPRC command, you'll notice that it looks very similar to the CALL command. The difference is that instead of requiring a program name it prompts you for a procedure name. The procedure must exist in the same program or in a service program specified when the program was created. The procedure name can be up to 256 bytes long and is case sensitive.

The procedure name is followed by a list of parameters you want to pass to the procedure. You can pass up to 300 parameters using the CALLPRC command; however, some languages limit the number of parameters a procedure can accept. For instance, a CL procedure accepts a maximum of 40 parameters. You can omit parameters by passing the special value *OMIT, in which case the procedure receives a null pointer as the parameter value. This can be useful when calling the OS/400 bindable APIs because the APIs often supply default values for omitted parameters.

Putting the Pieces Together

So far I've told you what you need to know to get started using ILE CL. Now I'll show you a working example to demonstrate how some of the pieces fit together. This example shows how to create a program containing a CL module that calls a procedure in a service program. 1 shows a conceptual view. I could have written this application using a single program containing two procedures, but I wanted to demonstrate the use of a service program since it's a better design approach, for reasons mentioned earlier.

So far I've told you what you need to know to get started using ILE CL. Now I'll show you a working example to demonstrate how some of the pieces fit together. This example shows how to create a program containing a CL module that calls a procedure in a service program. Figure 1 shows a conceptual view. I could have written this application using a single program containing two procedures, but I wanted to demonstrate the use of a service program since it's a better design approach, for reasons mentioned earlier.

Figures 2 and 3 show the source code for modules ILE001CL and ILE002CL. The purpose of these modules is to repeatedly perform a dynamically bound procedure call. ILE001CL passes a counter to ILE002CL, where the counter is incremented. When the counter reaches a value of 1000, the program ends.

To compile the example, perform the following steps:

1. Use the CRTCLMOD command to create module ILE001CL. 2. Use the CRTCLMOD command again to create module ILE002CL. 3. Use the CRTSRVPGM command to create the service program ILE002SV. In the MODULE parameter specify that you want the service program to contain module ILE002CL. (A service program can contain multiple modules.) 4. Use the CRTPGM command to create program ILE001PG. In the MODULE parameter specify that you want the program to contain module ILE001CL. In the BNDSRVPGM parameter specify that you want the program to be able to access procedures in the service program ILE002SV.

You have to create the service program ILE002SV before you create program ILE001PG. The reason for this is, if you specify the name of a service program on the CRTPGM command, the system checks to make sure the service program exists. If it does not, the command fails.

To test the difference in performance be-tween an ILE application and a non-ILE application, I wrote this example twice. One is the ILE version shown here, which uses the CALLPRC command. The other is a non-ILE program (not shown) that uses the traditional CALL command. The ILE version was almost twice as fast-it took 17 CPU seconds to execute, while the non-ILE version took 33 CPU seconds.

It's clear that ILE is the future of AS/400 application development, and ILE CL will play an important part in its success. With ILE CL, IBM has given us a powerful new tool to increase the performance, functionality, and quality of AS/400 application programs.

Robin Klima is a senior technical editor for Midrange Computing.

REFERENCES CL Reference (SC41-3722, CD-ROM QBKAUP00). ILE Application Development Example (SC41-3602, CD-ROM QBKAQ400).

ILE CL

Figure 1 ILE CL Example Overview

 UNABLE TO REPRODUCE GRAPHICS 
 
 ILE CL
 
 Figure 2 ILE CL Module ILE001CL
 
 /*==================================================================*/ /* To compile: */ /* */ /* CRTCLMOD MODULE(XXX/ILE001CL) SRCFILE(XXX/QCLSRC) */ /* */ /* CRTPGM PGM(XXX/ILE001PG) MODULE(XXX/ILE001CL) + */ /* BNDSRVPGM(XXX/ILE002SV) */ /* */ /*==================================================================*/ PGM DCL VAR(&COUNTER) TYPE(*DEC) LEN(10 0) LOOP: CALLPRC PRC(ILE002CL) PARM(&COUNTER) IF COND(&COUNTER *LT 1000) THEN(GOTO CMDLBL(LOOP)) ENDPGM 
 
 ILE CL
 
 Figure 3 ILE CL Module ILE002CL
 
 /*==================================================================*/ /* To compile: */ /* */ /* CRTCLMOD MODULE(XXX/ILE002CL) SRCFILE(XXX/QCLSRC) */ /* */ /* CRTSRVPGM SRVPGM(XXX/ILE002SV) MODULE(XXX/ILE002CL) + */ /* EXPORT(*ALL) */ /* */ /*==================================================================*/ PGM PARM(&COUNTER) DCL VAR(&COUNTER) TYPE(*DEC) LEN(10 0) CHGVAR VAR(&COUNTER) VALUE(&COUNTER + 1) ENDPGM