Carbon/400
Sign in

docs ILE Concepts

Shared Open Data Path—Scenario

Shared Open Data Path—Scenario

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.