What exactly is ILE?

So what exactly is ILE?

Sure, the term ILE has been used extensively in the IBM i market for some time but what exactly is does it mean? According to Big Blue, ILE stands for Integrated Language Environment. Great, but what does that mean? Well, let us refresh our memories.

Before ILE was born programs in the AS/400 environment were said to belong to the OPM which stands for Original Program Module which is still in use. OPM was sufficient for creating, compiling, and managing RPG programs but did not allow calling procedures in other languages. EPM, or Extended Program Module, served this purpose temporarily prior to ILE.

In simple terms, ILE was a massive upgrade with a multitude of improvements to the programming environment and was designed to be compatible with the existing RPG III environment. The IBM explanation is that these changes were necessary to "meet the changing needs of applications programmers". As you know upgrades in the IBM i workspace are usually very significant as opposed to some other software companies that just move things about. What IBM calls an "architectural extension" was a major step forward for application developers.

ILE became available with release V2R3 of OS/400 and the ILE RPG/400 compiler was released with V3R1. The ILE RPG/400 compiler brought ILE RPG, also known as RPG IV or RPGLE, into the ILE family of languages which helped RPG remain viable going forward. Adding ILE RPG enhanced the ability to integrate multiple languages. For example, ILE provides better integration between RPG, COBOL, C, and C++. All of these enhancements have remained highly relevant for years including the current 7.1 release.

The benefits of ILE versus OPM should be understood by the IBM i developer. In ILE a source member can be compiled to a new object type called a module and then these modules can be used in one or more ILE programs. In other words, CRTRPGMOD creates object type *MODULE and CRTPGM binds modules to create a program. The benefit of binding these non-runnable modules is modularity and re-use. Modularity provides smaller code segments which means easier testing and maintenance. The modules (and "service programs" *SRVPGM) can be stored and referenced via binding directories (*BNDDIR). Many useful bindable APIs are provided in ILE.

Another key enhancement in ILE is the ability to scope resources to an activation group. The activation group is similar to sharing open data paths but allows limiting the sharing to certain groups of programs. For example, the Purchasing Department programs might share an open data path (ODP) to the vendor master but the same physical file access path should not be shared by the Payables Department programs. The two departments programs can run in separate activation groups which will protect any shared paths from the other departments group of programs which enhances data integrity between the two departments.

Other significant enhancements include vastly improved source debugging capabilities and some major run-time performance gains.

Conclusion: RPG programmers should realize the massive benefits that ILE offers. ILE is 100% compatible with OPM so the only limiting factor is the learning curve. That is, developers can start enjoying the benefits of ILE while legacy OPM code does not require any modification. Modularity and reuse, easier debugging and testing, better maintenance, more efficient processing and enhanced performance could be your keys to success. Furthermore, it is nice that IBM is providing such a backwardly compatible and, at the same time, forward thinking integrated programming environment.