ILE as a feature of OS/400 and i5/OS has been around for a decade and a half. It conceptually started life as something called the Extended Program Model, written to provide better performance for C-type languages on the System/38. ILE went through a couple of iterations before it came to its current state, and it's definitely come a long way.

In this article, I'm going to define ILE as best I can, provide a wee bit of history, and show how it allows iSeries developers to perform unprecedented feats of programmatic legerdemain. Next, I'll touch on the relationship between ILE and J2EE. Finally, I'll compare and contrast it with .NET.

What Is ILE?

Summing up ILE in a single phrase is nearly impossible. Back in my college days, I took some physics classes in which we discussed the various fundamental forces, including the Strong Force; this is the force that holds protons and neutrons together in the nucleus of an atom. ILE is sort of the Strong Force of OS/400 application programming. With it, you can bind together small components of an application. (For those still following this line of thinking, a better analogy might be a covalent bond in chemistry, combining the "atoms" of code into "molecules" of software.)

Other metaphors apply: a framework, a translator, a foundation. In one sense, you can think of ILE as a framework on which all (non-OPM) OS/400 and i5/OS applications rely, providing various services that they can all share. This is especially true when dealing with system-level functions like critical error handling. In another sense, ILE acts as a translator, allowing modules written in different languages or even different architectures to communicate seamlessly with one another.

Historically Speaking

A better view of ILE may be gotten by reviewing its history. Back in the early 1980s, a couple of brilliant folks in Rochester (Dan Hicks and Dick Bains) decided to make Pascal run on a System/38. Pascal is a block-oriented language, like C or Java, and requires certain features from its operating environment. Since CPF (Control Program Facility, the operating system of the S/38) didn't support features like a parameter stack or dynamically allocated storage, these two guys had to essentially write that framework. They did, and it was christened Extended Program Model (EPM).

The EPM supported a number of features, including scoped variables and the ability to code multiple procedures in a single source member (up until this point, a source file was compiled to a program, which in turn had a single entry point). However, the EPM was originally just meant as a proof of concept, and retrofitting it to RPG and COBOL was deemed unfeasible. Instead, the EPM was retired and a new concept, ILE, was born. ILE was designed from the beginning to allow all languages, from RPG to C, to work with one another. I imagine one tough part was figuring out how to take an old cycle program with matching record logic and allow it to work, while at the same time allowing a programmer to write a module that contained just procedures. The H-spec option of *NOMAIN (for NO MAINline) does this quite nicely.

ILE Today

In short, ILE today allows any compiled language to talk to any other language. The IBM philosophy is to provide common data types that all languages can use; this was accomplished primarily by adding standard binary data types (integer and unsigned, as well as floating point) to the RPG language (they already existed in COBOL). In addition, where necessary (such as in RPG), extensions were made to the language to support multiple entry points in a source module.

Why Is This Important?

The primary importance of ILE-type program definition is the ability to create small, standalone pieces of programming logic that can be reused by any other program in the system. While the OPM CALL instruction did an excellent job for languages with single entry points, that concept wasn't easily translated for use with block-structured languages like C. But putting a generic procedure concept into place opened up a whole new world of functionality.

Technically Speaking

First, the ILE parameter-passing mechanism is in some ways far more flexible than that of other languages. For example, the ability to pass values as modifiable parameters is simply unknown in most other languages, and that makes for some great programming shortcuts. To modify an object in a calling routine in a language like C, you have to pass a pointer and go through all the issues of referencing and dereferencing. Of course, having modifiable parameters also introduces quite a bit of danger, but the ILE designers were very savvy about that, making sure that you had fine-grained control over how your parameters were handled, through the keywords CONST and VALUE.

In order to mitigate some of the danger, the ILE structure provides for the concept of a prototype, which strictly defines the interface for a procedure. Unlike loosely typed languages like JavaScript or Python, the ILE languages require variables to have predefined types, and the variables passed to a procedure must exactly match what the procedure is expecting. There are a couple of exceptions; for example, the *NOPASS keyword allows you to specify that a parameter might not be passed (only valid for the last parameters), while the *OMIT keyword allows a special value of *OMIT for unused parameters.

Also, a prototype using the CONST or VALUE keyword allows the compiler to do some cool internal processing, such as converting between different types. Numeric values are automatically converted from one type to another, and other conversions can be triggered with keywords such as *STRING and *VARSIZE.

From a Functional Standpoint

What ILE provides to an application developer is the ability to write code in whatever language best suits the task and then combine those bits of code as necessary. For example, while OS/400 and i5/OS provide APIs for just about any system function you might need to execute, some of them are awfully complicated to invoke from RPG and in fact are easier to use via their CL command counterparts. For example, I far prefer using CHKOBJ to check for the existence of a QSYS object as opposed to the QUSROBJD API. Every application I write has access to a CLLE (the ILE version of CL) module that checks for an object's existence. You pass in four parameters: the object, library, type, and return code. The module sets the return code appropriately. CLLE is not yet totally synchronized with the ILE environment. You cannot have multiple procedures in a single module, and you cannot return values. That's why my CHKOBJ module requires a return code parameter. On the positive side, V5R3 adds call-by-reference to the CLLE language, which makes CLLE a lot more functional in the ILE world. You can't have everything.

OK, What About Java?

This is where it gets interesting. IBM is pushing Java as a great replacement language for everything. Those who know me know I disagree heartily with this statement, since I think RPG is the best language available for programming database-driven business rules. At the same time, I've been an advocate of Java for nearly as long as it has been around: I was writing articles about Java on the midrange back when the iSeries was still called an AS/400!

The trick, then, is to make the two languages work together. Well, isn't ILE supposed to make any language talk to another language? Unfortunately, it's not that easy. The basic ILE procedure-calling mechanism works only with statically compiled languages: languages like C and RPG and COBOL that are compiled into modules and eventually bound into machine-language programs. Java doesn't fall into that category.

How Does Java Work?

Java is a bytecode language and requires a virtual machine to run it. Harkening back to the days of UCSD Pascal, bytecode is a point between interpreted and compiled code. Interpreted languages (like JavaScript or PHP) read their source code and parse it anew every time the code is invoked. There really is no compilation, so interpreted languages tend to be quite slow, relatively. They were, in fact, so slow that until the recent advent of multi-gigahertz processors, interpreted languages were relegated to teaching tools and simple end-user applications. Nowadays, however, CPU speeds have increased so dramatically that interpreted languages are staging a comeback, especially in the world of user interface, where the limiting factor is human reaction time, not processor speed.

However, for transaction-intensive processing such as that done in business environments, interpretive processing simply isn't fast enough. Thus, most business servers rely on compiled languages such as COBOL and RPG. With compiled languages, the source code is actually converted to machine language: the specific binary codes the hardware understands to do its job. The problem with compiled languages is that each computer needs its own compiler, and enhancements to the language often weren't handled the same way by different compilers. The ability to move a program from one platform to another was severely hampered by such inconsistencies.

Java treads the middle road. Initially, the syntax is converted to bytecodes, which are run inside an interpreter, the Java Virtual Machine (JVM). While not as fast as compiled code, the bytecode has a huge advantage over compiled code: It will run on any machine with a JVM. It is this capability that spawned Java's phenomenal growth in the IT industry. And relatively recently, JVMs have started to include something called a Hot-Spot or Just-In-Time (JIT) compiler. The JIT compiler monitors the use of the Java code, and code that has been executed enough times gets compiled into machine code.

So This Can Be Called, Right?

Actually, no. There are still two problems. First, the JIT-compiled code doesn't always exist; it's a temporary artifact created by the JVM itself. Back in early releases of Java on the iSeries, the CRTJVAPGM was used to create a persistent version of the compiled Java code, thus improving performance. This has since been deprecated in favor of the JIT compiler.

More important, though, is the fact that Java is a class-based language. Everything in Java is done via classes and objects. There is no standard linkage between a statically bound language like RPG or C and a class-based language like Java. Instead, you need to develop a framework that allows the instantiation of objects and the invocation of methods in those objects. While this is superficially similar to the standard procedure linkage, a number of additional issues come into play when trying to link procedural and object-oriented languages. Garbage collection is just one of the many problems that need to be addressed.

Currently, the only language that is Java-enabled is RPG. If you choose to develop a multilingual application in which direct calls are made from a non-Java module to a Java method, then you'll need to use RPG for that task. Alternate options include standard techniques like data queues. On the other hand, Java can quite easily call any type of program on the iSeries; the Java Toolbox provides interface classes that allow you to call both normal programs and service programs.

The Ever-Present Microsoft Issue

Whenever you talk about technology, you must include Microsoft in the equation. Even the first line of this article started with ".NET," since .NET is a bit like a Microsoft version of ILE (it's also a bit like a Microsoft version of the JVM and a lot like neither).

These days, it's hard to be objective when dealing with Microsoft. One the one hand, you have to be clear that Microsoft's goal is to wipe both the iSeries and Java off the face of the planet. If you don't acknowledge those points, you're setting yourself up to be whacked upside the head just like Apple or IBM or any of the small vendors crushed by the Microsoft "embrace, extend, extinguish" philosophy.

On the other hand, you have to recognize Microsoft's power in the workplace. While that power primarily derives from the company's stranglehold on the desktop, Microsoft is unrivaled in its ability to play that hold into a perceived ability to write business software. (Author's note: In typical Microsoft fashion, this is done through the dumbing down of the message. A perfect example is the television commercial in which a bunch of people--apparently with deep emotional problems--dump a water cooler on someone's head as he sits in front of a desk that's full of electronic equipment. Evidently, in Microsoft's mind, this is how business gets done, although in the real world this would typically end in a trip to the emergency room and criminal charges.)

The problem is Microsoft marketing. Microsoft has some of the best spin doctors on the planet, second only to the IT press itself. What's good is bad. What's bad is good. What's old is new (to them). Much of .NET is very similar to the JVM concept. .NET languages are compiled to a portable bytecode: the Common Intermediate Language (CIL). This bytecode is executed by the Common Language Runtime (CLR), which is a stack-based virtual machine, much like the JVM. The CLR enforces type safety and supports polymorphism, the memory is garbage collected, and the CIL bytecode is JIT-compiled to native code.

The primary differences are that the CLR is designed to support multiple languages on a single platform (Windows), while the JVM is designed to support a single language (Java) on every platform.

But most of all, from an iSeries standpoint, there is currently zero ability to run .NET code under OS/400 or i5/OS, which means that the integration of .NET with ILE is non-existent. And until some type of i5/OS CLR is available, .NET and ILE will not work together (much like .NET and Java or, basically, .NET and virtually anything non-Microsoft).

Some Observations

Note that the big selling point of .NET is that it supports multiple languages; it's sure not openness, since it locks you into the proprietary Windows platform. Of course, .NET doesn't support Java, and there is no native RPG or COBOL support, either. (You may choose to support a third-party vendor for your mission-critical language support, but if a vendor is willing to bail on a platform, what makes you think they're not willing to bail on a language?)

Meanwhile, the iSeries has offered multi-language support for decades, and a formal inter-language specification, ILE, has been around for almost as long as Windows itself. People shouting about Microsoft's multi-language capabilities are sort of like the trade press saying that Intel now supports 64 bits--something the iSeries has quietly been doing for a long, long time.

Yeah, multi-language is new to Microsoft, but that doesn't make it new.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. Joe is also the author of E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..