ILE benefits include binding, modularity, reusable components, common runtime services, coexistence, and a source debugger.

Binding

The benefit of binding is that it helps reduce the overhead associated with call operations. Binding the modules together speeds up the call. The previous call mechanism is referred to as a dynamic or external program call, and the ILE method is referred to as a static or bound procedure call.

The binding capability makes it far more practical to develop applications in a highly modular fashion. An ILE compiler does not produce a program that can be run. Rather, it produces a module object (*MODULE) that can be combined (bound) with other modules to form a single runnable unit; that is, a program object (*PGM).

Just as you can call an RPG program from a COBOL program, ILE allows you to bind modules written in different languages. Therefore, it is possible to create a single runnable program that consists of modules written separately in RPG, COBOL, C, C++, and CL.

Modularity

The benefits from using a modular approach to application programming include the following:

• Faster compile time: The smaller the piece of code we compile, the faster the compiler can process it. This benefit is particularly important during maintenance, because often only a line or two needs to be changed. When we change two lines, we may have to recompile 2000 lines. That is hardly an efficient use of resources.

• Simplified maintenance: When updating a very large program, it is very difficult to understand exactly what is going on. This is particularly true if the original programmer wrote in a different style from your own. A smaller piece of code tends to represent a single function, and it is far easier to grasp its inner workings.Therefore, the logical flow becomes more obvious, and when you make changes, you are far less likely to introduce unwanted side effects.

• Simplified testing: Smaller compilation units encourage you to test functions in isolation. This isolation helps to ensure that test coverage is complete; that is, that all possible inputs and logic paths are tested.

• Better use of programming resources Modularity lends itself to greater division of labor. When you write large programs, it is difficult (if not impossible) to subdivide the work. Coding all parts of a program may stretch the talents of a junior programmer or waste the skills of a senior programmer.

• Easier migration of code from other operating systems

Reusable Components

With ILE, you can select packages of routines that can be blended into your own programs. Routines written in any ILE language can be used by all ILE compiler users.

Programmers can write in the language of their choice.

You can also develop routines in the ILE language of your choice and market them to users of any ILE language.

Common Runtime Services

A selection of off-the-shelf components (bindable APIs) is supplied as part of ILE, ready to be incorporated into your applications. These APIs provide services such as:

• Date and time manipulation
• Message handling
• Math routines
• Greater control over screen handling
• Dynamic storage allocation

Coexistence with Existing Applications

ILE programs can coexist with existing OPM programs. ILE programs can call OPM programs and other ILE programs.

Similarly, OPM programs can call ILE programs and other OPM programs. Therefore, with careful planning, it is possible to make a gradual transition to ILE.

Source Debugger

The source debugger allows you to debug ILE programs and service programs.

Better Control over Resources

Before the introduction of ILE, resources (for example, open files) used by a program could be scoped to (that is, owned by) only:

• The program that allocated the resources
• The job

In many cases, this restriction forces the application designer to make tradeoffs.

ILE offers a third alternative. A portion of the job can own the resource.

This alternative is achieved through the use of an ILE construct, the activation group.

Under ILE, a resource can be scoped to any of the following:

• A program
• An activation group
• The job

Shared Open Data Path—Scenario

Shared open data paths (ODPs) are an example of resources you can better control with ILE’s new level of scoping.

To improve the performance of an application, a programmer decides to use a shared ODP for the customer master file. That file is used by both the Order Entry and the Billing applications.

Because a shared ODP is scoped to the job, it is quite possible for one of the applications to inadvertently cause problems for the other. In fact, avoiding such problems requires careful coordination among the developers of the applications. If the applications were purchased from different suppliers, avoiding problems may not even be possible.

What kind of problems can arise? Consider the following scenario:

1. The customer master file is keyed on account number and contains records for account numbers A1, A2, B1, C1, C2, D1, D2, and so on.

2. An operator is reviewing the master file records, updating each as required, before requesting the next record. The record currently displayed is for account B1.

3. The telephone rings. Customer D1 wants to place an order.

4. The operator presses the Go to Order Entry function key, processes the order for customer D1, and returns to the master file display.

5. The program still correctly displays the record for B1, but when the operator requests the next record, which record is displayed?

If you said D2, you are correct. When the Order Entry application read record D1, the current file position changed because the shared ODP was scoped to the job. Therefore, the request for the next record means the next record after D1.

Under ILE, this problem could be prevented by running the master file maintenance in an activation group dedicated to Billing.

Likewise, the Order Entry application would run in its own activation group. Each application would still gain the benefits of a shared ODP, but each would have its own shared ODP, owned by the relevant activation group. This level of scoping prevents the kind of interference described in this example.

Scoping resources to an activation group allows programmers the freedom to develop an application that runs independently from any other applications running in the job. It also reduces the coordination effort required and enhances the ability to write drop-in extensions to existing application packages.

Commitment Control—Scenario

The ability to scope a shared open data path (ODP) to the application is useful in the area of commitment control.

Assume that you want to use a file under commitment control but that you also need it to use a shared ODP. Without ILE, if one program opens the file under commitment control, all programs in the job have to do so. This is true even if the commitment capability is needed for only one or two programs.

One potential problem with this situation is that, if any program in the job issues a commit operation, all updates are committed. The updates are committed even if logically they are not part of the application in question. These problems can be avoided by running each part of the application that requires commitment control in a separate activation group.

Better Control over Language Interactions

With activation groups, calling among progarms of Mixed Languages are fine.

Without activation groups( which are introduced by ILE), interactions among OPM languages are difficult to predict.

ILE activation groups can solve that difficulty.

For example, consider the problems caused by mixing COBOL with other languages. The COBOL language standard includes a concept known as a run unit. A run unit groups programs together so that under certain circumstances they behave as a single entity. This can be a very useful feature.

Assume that three ILE COBOL programs (PRGA, PRGB, and PRGC) form a small application in which PRGA calls PRGB, which in turn calls PRGC. Under the rules of ILE COBOL, these three programs are in the same run unit. As a result, if any of them ends, all three programs should be ended and control should return to the caller of PRGA.

Suppose that we now introduce an RPG program (RPG1) into the application and that RPG1 is also called by the COBOL program PRGB. An RPG program expects that its variables, files, and other resources remain intact until the program returns with the last-record (LR) indicator on.

However, the fact that program RPG1 is written in RPG does not guarantee that all RPG semantics apply when RPG1 is run as part of the COBOL run unit. If the run unit ends, RPG1 disappears regardless of its LR indicator setting. In many cases, this situation may be exactly what you want. However, if RPG1 is a utility program, perhaps controlling the issue of invoice numbers, this situation is unacceptable.

We can prevent this situation by running the RPG program in a separate activation group from the COBOL run unit . An ILE COBOL run unit itself is an activation group.

Better Code Optimization

The translator can do many more types of optimization for ILE programs than it can for OPM programs.

An ILE-enabled compiler does not directly produce a module. First, it produces an intermediate form of the module, and then it calls the ILE translator to translate the intermediate code into instructions that can be run. By using an intermediate code that is used as input to the common ILE translator, an optimization added to the translator for one ILE language might benefit all ILE languages.