May 2007

Integrated Language Environment (ILE)

ILE is an architectural change to language compilers and the runtime characteristics of AS/400 programs. It is an extension to the architecture which means that your existing programs continue to run without changing and recompiling. ILE is available with Version 2 Release 3 of OS/400. Integrated Language Environment is tightly integrated into the Operating System/400. The key benefits for the new ILE environment are:

Language Integration: Application programs are developed using the language mix best suited to perform each required function.

Reusability: Code from supported languages is divided into smaller, reusable, more logical modules that compile faster and require less maintenance over their life.

Performance: Capability is provided to optimize code in compute-intensive applications and to reduce the time to perform inter-program calls Integrated Language Environment increases developer productivity by providing the capability to divide code into smaller, more logical units that compile faster. The system binder combines the compiled modules to create the application program. In addition, the separation of compilation and bind steps provides more flexibility packaging the application. The new source level debug tool that supports the ILE languages provides enhanced capability over the system debugger with the new feature to debug at the source or listing level of the program. Step, breakpoint, and conditional breakpoint functions have been provided. Expressions are entered and evaluated using the syntax of the programming language being debugged. The current system debug facility remains unchanged for programs developed outside ILE.

New family of compilers for AS/400

1. New RPG IV Compiler (The next generation of RPG) 2. New ILE C/400 compiler (Improved performance) 3. New ILE COBOL/400 compiler (Improved structured programming support) 4. New ILE CL compiler

ILE Benefits
ILE offers numerous benefits not found on previous releases of the AS/400 system. These benefits include: 1. Better call performance 2. Modularity 3. Multiple-language integration 4. Enhancements to the ILE compilers 5. Reusable components 6. Control over application run-time environment 7. Code optimization 8. Tool availability 9. Foundation for the future In addition, ILE offers common run-time routines used by the ILE-conforming languages. Many of the application program interfaces (APIs) are also provided as bindable (service) programs. This allows your applications to use APIs and to get faster ILE call performance. These off-the-shelf components provide such services as: Date manipulation Message handling Math routines Activation Groups Service Programs

1. Better Call Performance

An ILE compiler does not produce a program that can be run. Instead, it produces a module object (*MODULE) that can be combined, or bound, with other modules to form a single runnable unit, or program. ILE programs are called just as you call programs in your current applications. A benefit of this binding process is that it helps to reduce the overhead associated with calling programs by reducing the number of external calls. Before ILE, only dynamic (or external) program calls were available to the application

programmer. With ILE, two kinds of calls are available: Dynamic (or external program) calls [E.g. Program Calls] Static (or bound) calls [E.g. Service Program Calls] The performance of dynamic calls in ILE programs is fairly close to existing call performance. However, bound calls offer better performance than dynamic calls. Thus, the binding capability and the improved call performance that results may encourage you to develop your applications with a more modular design.

2. Modularity

A more modular approach to programming provides numerous benefits to you, including: Faster compilation because the units of code to compile are smaller (especially in recompiling during development). Better programmer work load distribution. Opportunities to both purchase and sell individual modules of code. Increased ability to reuse a piece of code in a variety of applications. Modules written for a specific function can be bound into several program objects. Simplified maintenance. Maintenance may be required in only a single module.

3. Multiple-Language Integration

With your current application, you can mix different language programs, such as RPG, COBOL, and C. However, to access code written in another language, your current application must perform a dynamic call to a separate program. The performance cost of the dynamic call to a program and the inconsistencies between language behaviors sometimes complicate the mixing of languages. With ILE, modules written in any ILE language can be bound to modules written in the same or any other ILE language. For example, a module of code written in ILE C/400 (perhaps a floating-point calculation) can be bound with modules written in ILE RPG/400, ILE COBOL/400, ILE C/400, or ILE CL. This produces a better performing, and more easily managed application. In addition, you can acquire modules written in a variety of languages, without needing to produce the code yourself. The APIs that IBM provides for ILE are just the beginning. Vendors have more freedom to sell (and application programmers to buy) libraries of routines for any commonly used function, such as tax calculations. They can be written in any language and can be bound for better performance.

4. Enhancements to the ILE Compilers

The ILE compilers have some significant new function included as part of the language. This is particularly true for ILE RPG/400, which is based on the RPG IV language definition. Many long-standing requests from RPG programmers have been addressed in the ILE RPG/400 compiler, including the following: 10-character field names Free-form logical and math expressions Date and time data types and operations External data items (data export) Uppercase and lowercase source File-level field prefix support Pointers For many programmers, the primary motivation for moving to ILE is to get access to the function that ILE language support provides.

5. Reusable components

ILE allows you to select packages of routines that can be blended into your own programs. Routines written in any ILE language can be used by all AS/400 ILE compiler users. The fact that programmers can write in the language of their choice ensures you the widest possible selection of routines. The same mechanisms that IBM and other vendors use to deliver these packages to you are available for you to use in your own applications. Your installation can develop its own set of standard routines, and do so in any language it chooses. Not only can you use off-the-shelf routines in your own applications, you can also develop routines in the ILE language of your choice and market them to users of any ILE language.

6. Control over Application Run-Time Environment

ILE allows you to use better control over your application and the resources it uses. You can specify that a given ILE program run in a particular area within a job. This area within a job is called an activation group. You can assign a name to the activation group within the job. Then, ILE programs and service programs can be created to use the named activation group. Thus, you can use activation groups to set up logical boundaries within the job to separate the applications. Within these boundaries, an activation group has exclusive use of the resource, such as open data paths for the files used in the application. Using activation groups to isolate applications can also make it easier to end an application in a job. It aids in cleaning up its resources (such as open files and active programs) without disturbing resources associated with other applications active in the job. RPG programmers might think of this technique as a kind of application-level LR indicator. For example, it is a way to end an entire application rather than ending one program at a time.

7. Code Optimization

The new ILE compilers and the associated OS/400 translator have more advanced optimization techniques built into them. In some cases, these new levels of optimization may lead to improved performance of existing code. At compilation time, the programmer can select the desired level of optimization for each piece of code.

8. Tool Availability

The majority of tools for developers in the computer industry today are written in the C language. With ILE binding capability and improved optimization, these C language applications run faster. In addition, they perform better than they did with the previous C/400 compiler. Therefore, we anticipate that many tool vendors will begin to add their tools to the AS/400 to attract a new marketplace for their products. Making use of the C language offers you a greater choice of: CASE tools Fourth-generation languages (4GLs) Editors Debuggers

9. Foundation for the Future

In addition to the increased opportunity to optimize your applications with the current ILE compilers, you can look forward to even more significant enhancements. The move toward object-oriented programming languages and visual programming tools increases the need for the capabilities provided by ILE. Applications constructed of large numbers of small, modularized, reusable components that efficiently transfer control among themselves offer you maximum flexibility. You can use them multiple ways in multiple applications.

ILE Objects

ILE object type ILE program (*PGM)

Function

Key benefit

Caveats

The executable object. Same object type as for OPM programs (*PGM) but program type attribute is ILE. Job-related object used for executing programs Similar to the PAG but can be controlled much more (OPM programs used to execute in the job's PAG, all programs -- ILE & OPM -- now execute in activation groups). An intermediate object used to hold the result of compiling a source member before it becomes part of a program Contains only MI instructions, not an executable object

Can run in any activation group (OPM programs can only run in default activation group). Supports mixed-language programs. Activation groups isolate programs and resources with the activation group. Multiple activation groups per job.

Errors/conditions are handled differently.

Activation group (not an i5/OS object)

Activation groups consume system resources. Control boundaries between activation groups can get complicated

Module (*MOD or *MODULE)

Calls between modules execute much quicker than calls between programs Can combine multiple modules to create an ILE program. Reusable: can include in more than one program. Takes modular programming on the iSeries to the next level

Increases program size More disk space also required to store the module object itself.

Service program (*SRVPGM )

Provides the fast moduleto-module call without increasing program size

Activation group in which to execute can be specified (as for ILE programs) Similar to DLLs on the PC but with more features (except no initial control procedure like the DLL LibMain function).

Design must be well thought out No support for an initial routine (i.e., *INIT in RPG).

Binding directory (*BNDDIR)

Allows saving and reusing some of the information needed to build an ILE program. Similar to the object-list in a make-file (make-files are used on other platforms to automate program creation).

Speeds application development Can be used to store creation information for multiple programs. More than one binding directory can be used to create a single program.

Can lengthen program creation time if used carelessly.

1. ILE programs ILE programs are significantly different from OPM programs. Although they do not represent a new object type -- they are still just *PGM objects -- they are a different type of program object. (An ILE program will have a Program Type attribute of ILE, whereas an OPM program will have a Program Type attribute of OPM.) The main advantage ILE programs enjoy over OPM programs is their ability to access all the new features that were introduced with ILE (e.g., ILE-specific language enhancements, ILE-specific APIs, etc.). But the real difference between program objects of type OPM and type ILE is the way they execute. ("Activation groups")

2. Activation groups With the introduction of ILE came activation groups -- a new type of process object. A process object is a temporary object used by a process (i.e. a job) during the life span of the process. It's not a persistent, storable type of object such as a program or a file; when a job ends, its associated process objects are, for all intents and purposes, deleted.

Programs do not run in program activation groups (PAGs) any more; they run in activation groups, which

can be thought of as "mini-PAGs." Even OPM programs run in an activation group -- a special activation group called the default activation group, which every job automatically has. The default activation group is an ILE activation group, but it has the ability to emulate the OPM environment hence allowing OPM program to run on an ILE-based machine. However, as with any type of emulation, performance is slowed by the extra processing necessary to simulate the OPM environment.

In addition to the default activation group, there are non-default activation groups. Non-default activation groups do not have any of the overhead of the default activation group that is necessary to run OPM programs. You can give your own names to activation groups or let the system name activation groups for you. Unlike OPM programs, which must run in the default activation group, ILE programs can run in any activation group you choose. Use this to your advantage to isolate applications in their own activation group. You can even specify that a program should run in the same activation group as the program that calls it. This is done by specifying the value of *CALLER for the activation group attribute when creating the program.

3. Modules These new objects, object type *MODULE, are the building blocks of all ILE programs, including service programs. They are intermediate objects between source code and programs. They represent the result of compiling source members (with one of the CRTxxxMOD commands) before they are ultimately incorporated, or bound, into programs with either the CRTPGM or CRTSRVPGM command. Even the CRTBNDxxx commands create a module object -- albeit a temporary one in QTEMP -- before finally creating a program out of that temporary module.

Modules are reusable. The word module is derived from the term modularize, which we should all know by now is the most advantageous way to build reusable code. With OPM RPG, for example, the only ways we had to modularize were the following: 1. Create subroutines in copy-members and include them in programs with the /COPY compiler directive. This provides a fast calling interface, but parameters have to be simulated using global variables. It also increases the size of program objects. 2. Create stand-alone programs and call them from other programs. This provides for true parameters, but it is a slow calling interface.

Modules combine the advantages of these two methods, giving us true parameter support and a fast call interface. Since a module is a reusable object, it can be bound into both a service program and a regular program.

Modules have one disadvantage, though. Like the first OPM method, they increase program size.

4. Service programs Service programs are to the iSeries what DLLs are to PCs. They provide a fast calling interface without having to include code in your program. For example, in RPG the fastest calling interface is the EXSR opcode, but the subroutine that is called must be part of the calling program, adding size to both the source and executable program.

A procedure in a service program (a procedure is a kind of self-contained subroutine or a mini-program) can be called with almost the same speed, but the source and executable code of the procedure are not part of the calling program. This is especially advantageous when many programs call the same procedure.

Procedures in a service program are called using the CALLB or CALLP op-code (or in-line as part of an expression) in RPG, the CALLPRC command in CL, or the CALL PROCEDURE statement in COBOL. Service programs used by programs must be bound to the program using the CRTPGM or CRTBNDxxx command.

It has an object type of *SRVPGM. It is created similarly to how programs are created, except the CRTSRVPGM command is used instead of the CRTPGM command or one of the CRTBNDxxx commands. Service programs can be bound to (i.e. used by) other service programs.

In short, a service program is a collection of runnable procedures and available data items easily and directly accessible by other ILE programs or service programs. In many respects, a service program is similar to a subroutine library or procedure library. Service programs provide common services that other ILE objects may need; hence the name service program.

5. Binding directories ILE programs and service programs are created by binding one or more modules and/or service programs together using the CRTPGM or CRTSRVPGM command. As programs become more modular, the complexity of the CRTPGM (or CRTSRVPGM) command becomes burdensome.

For example in OPM, the create program command was fairly simple:

CRTRPGPGM PGM(MYLIB/MYPGM) SRCFILE(MYLIB/QRPGSRC) SRCMBR(*PGM)

However, in ILE the complexity of the create program command grows proportionately to the number of modules and service programs that compose the program. For example, without the use of a binding directory, a program that is made up of four modules (MYPGM, MOD1, MOD2 and MOD3) and three service programs (SRVPGM1, SRVPGM2 and SRVPGM3) would require a CRTPGM like following at a minimum: CRTPGM PGM(MYLIB/MYPGM) MODULE(MYLIB/MYPGM MYLIB/MOD1 MYLIB/MOD2 MYLIB/MOD3) BNDSRVPGM(MYLIB/SRVPGM1 MYLIB/SRVPGM2 MYLIB/SRVPGM3)

The solution is to use a binding directory. A binding directory, object type *BNDDIR, is nothing more than a stored list of module and service program names. When a binding directory is specified on the CRTPGM (or other command), as in CRTPGM PGM(MYLIB/MYPGM) MODULE(MYLIB/MYPGM) BNDDIR(MYLIB/MYPGM) the system uses the list of modules and service programs in the binding directory as if they had been specified individually on the create command.

Binding directories can also be used to group modules and/or service programs into logical groups. You can even create a "super" binding directory that contains the names of all the modules and service programs on your system, but remember as the number of entries in a binding directory goes up, so does the program creation time.

Modules or service programs listed in a binding directory are used only if they provide an export that can satisfy any currently unresolved import requests.

ILE-related Commands

Module and program creation commands

1. CRTxxxMOD

These Create Module commands compile source members of the various ILE languages into ILE modules, intermediate non-executable objects that can be bound into ILE programs. The xxx is replaced with the appropriate language designator, such as RPG, CBL, C, or CL, to produce CRTRPGMOD, CRTCBLMOD, CRTCMOD, or CRTCLMOD.

2. CRTPGM

The Create Program command allows you to bind together one or more modules -- created with the CRTxxxMOD commands -- into a single executable program. The modules can be of different languages.

3. CRTBNDxxx

These Create Bound Program commands combine the function of the CRTxxxMOD and CRTPGM commands. They can be used to quickly compile a source member and automatically bind the resulting (temporary) module into an executable ILE (i.e., bound) program in one step.

These commands can also be used to create an ILE program that runs in the default activation group, which

is not an option when you use the CRTPGM command. Like the CRTxxxMOD commands, you should replace the xxx in CRTBNDxxx with the appropriate language identifier. Note: You cannot list any other modules on the CRTBNDxxx commands to bind into the program (as you can on the CRTPGM command). You must use binding directories to reference other modules or service programs on the CRTBNDxxx commands.

4. CRTSRVPGM

The Create Service Program command is similar to the CRTPGM command except it creates a service program.

Binding directory commands

5. CRTBNDDIR

The Create Binding Directory command creates a "shell" to hold binding directory entries that you add later using the ADDBNDDIRE command. Binding directory entries are references to modules and service programs. Binding directories can be specified on the CRTPGM, CRTBNDxxx, and CRTSRVPGM commands. The binding directory entries are then used to locate unresolved procedures. Using binding directories can significantly reduce the amount of information required on the CRTPGM, CRTBNDxxx, and CRTSRVPGM commands, thus increasing productivity.

6. ADDBNDDIRE

The Add Binding Directory Entry command can be used to add module and service program names to a binding directory. Only the names are stored in the binding directory, not the actual module or service program. The stored names are then used as references to locate unresolved externals (i.e. procedures and variables) when the binding directory is specified on a CRTPGM, CRTBNDxxx or CRTSRVPGM command.

7. RMVBNDDIRE

The Remove Binding Directory Entry command is the opposite of the ADDBNDDIRE command; it removes a specific entry or group of entries from a binding directory.

8. DSPBNDDIR

The Display Binding Directory command is used to display the entries stored in a binding directory.

9. WRKBNDDIR

The Work with Binding Directories command allows you to interactively work with a list of binding directories.

10. WRKBNDDIRE

The Work with Binding Directory Entries command allows you to interactively work with the entries of a binding directory, adding and removing them with simple menu commands.

Module and program maintenance commands

11. CHGMOD, CHGPGM and CHGSRVPGM

These commands allow you to change certain attributes of modules, programs and service programs, respectively. They are similar to the "old" CHGPGM. For example, they can be used to optimize or remove observability from a module, program or service program.

12. DLTMOD, DLTPGM and DLTSRVPGM

These commands delete modules, programs and service programs, respectively.

13. DSPMOD, DSPPGM and DSPSRVPGM

These commands display information about a module, program or service program, respectively.

14. WRKMOD, WRKPGM and WRKSRVPGM

These commands allow you to interactively work with a list of modules, programs or service programs, respectively.

15. UPDPGM and UPDSRVPGM

These commands allow you to replace one or more modules in a program or service program with new modules without requiring you to recreate the entire program. The new modules must have the same name as the ones to be replaced.