Test268 Section 8

<< Previous Section | Home | Next Section >>

Section 8 - ILE (11%)

Create and use Binding Directories

The following command creates binding directory L in library MYLIB:

    CRTBNDDIR BNDDIR(MYLIB/L)

The following command adds the names of modules M1 and M2 and of service programs S and T to binding directory L:

    ADDBNDDIRE BNDDIR(MYLIB/L) OBJ((M1 *MODULE) (M2 *MODULE) (S) (T))

The following command is used to create program A

  CRTPGM PGM(TEST/A)
  MODULE(*LIBL/M1)
  BNDSRVPGM(*LIBL/S)
  BNDDIR(*LIBL/L)
  OPTION(*DUPPROC)

• At the time of creation of binding directory if no library is mentioned then by default it will get created in QGPL.
• If binding directory may get changed no need of recompiling the programs.

Differentiate bound procedure calls from dynamic program calls

The benefit of binding is that it helps reduce the overhead associated with calling programs. Binding the modules together speeds up the call. The previous call mechanism is still available, but there is also a faster alternative. To differentiate between the two types of calls, the previous method is referred to as a dynamic or external program call, and the ILE method is referred to as a static or bound procedure call.

Differentiate "bind by copy" from "bind by reference"

Binding by Copy The modules specified on the MODULE parameter are always bound by copy. Modules named in a binding directory specified by the BNDDIR parameter are bound by copy if they are needed. A module named in a binding directory is needed in either of the following cases: v The module provides an export for an unresolved import v The module provides an export named in the current export block of the binder language source file being used to create a service program If an export found in the binder language comes from a module object, that module is always bound by copy, regardless of whether it was explicitly provided on the command line or comes from a binding directory. For example,

  Module M1: imports P2
  Module M2: exports P2
  Module M3: exports P3
  Binder language S1: STRPGMEXP PGMLVL(*CURRENT)
  EXPORT P3
  ENDPGMEXP
  Binding directory BNDDIR1: M2
  M3
  CRTSRVPGM SRVPGM(MYLIB/SRV1) MODULE(MYLIB/M1) SRCFILE(MYLIB/S1)
  SRCMBR(S1) BNDDIR(MYLIB/BNDDIR1)

Service program SRV1 wil<nowiki>Insert non-formatted text here</nowiki>l have three modules: M1, M2, and M3. M3 is copied because P3 is in the current export block.

Binding by Reference Service programs specified on the BNDSRVPGM parameter are bound by reference. If a service program named in a binding directory provides an export for an unresolved import, that service program is bound by reference. A service program bound in this way does not add new imports. Note: To better control what gets bound to your program, specify the generic service program name or specific libraries. The value *LIBL should only be specified in a user-controlled environment when you know exactly what is getting bound to your program. Do not specify BNDSRVPGM(*LIBL/*ALL) with OPTION(*DUPPROC *DUPVAR). Specifying *LIBL with *ALL may give you unpredictable results at program run time.

Determine appropriate use of activation groups

All ILE programs and service programs are activated within a substructure of a job called an activation group. This substructure contains the resources necessary to run the programs. These resources fall into the following general categories:

Static program variables 
Dynamic storage Temporary data management resources 
Certain types of exception handlers and ending procedures

The separation of these resources among activation groups supports a fundamental concept. That is, the concept that all programs activated within one activation group are developed as one cooperative application. Software vendors may select different activation groups to isolate their programs from other vendor applications running in the same job. Activation groups increase the ease of integration by isolating the resources associated with each vendor package. There is a significant consequence of assigning the above resources to an activation group. The consequence is that when an activation group is deleted, all of the above resources are returned to the system. The temporary data management resources left open at the time the activation group is deleted are closed by the system. The storage for static and automatic program variables and dynamic storage that has not been deallocated is returned to the system.

Determine causes of and ways to avoid Signature Violation errors when using Service Programs

Don't EXPORT(*ALL) when creating a service program.

Determine appropriate use of the RCLACTGRP (Reclaim Activation Group) command

The Reclaim Activation Group (RCLACTGRP) command deletes a specified activation group and frees the resources that are scoped to it. It does not reclaim resources scoped to the job or scoped to the default activation group. This command is normally used only in the controlling program of the application.

An activation group is eligible to be reclaimed if it meets the following criteria:

   * The activation group is not the default activation group.
     The default activation group cannot be reclaimed.
   * The activation group is not active.
     An activation group cannot be reclaimed if there are programs or procedures running within the activation    group.
   * The activation group is not one of the debug activation groups.
     When the job is in debug mode, the activation groups in use do not appear as active on the Call Stack or Display Activation Group displays.
   * The activation group is not a shared activation group.
     A shared activation group cannot be reclaimed because it may be in use by another job.

When an activation group is reclaimed, all resources within the scope of the activation group are reclaimed. Resources within the scope of the activation group include static storage for programs in the activation group, open files, user interface manager (UIM) application resources, Common Programming Interface (CPI) Communications conversations, hierarchical file systems (HFS) resources, user-defined communications sessions, and pending changes for the commitment definition.

A close option can be specified on this command, and is used when closing mixed, communications, binary synchronous (BSC), and intersystem communications function (ICF) files. If an activation group level commitment definition has been started for the activation group, and it has pending committable changes, the close option also indicates whether the system implicitly commits or rolls back the pending changes before ending the commitment definition. When specifying a close option of *NORMAL, and there are no errors when closing files using the activation group level commitment definition, a commit is performed. Otherwise, a rollback is performed. See the Backup and recovery topic in the Information Center for information on how the system performs the rollback operation under commitment control.

An activation group should only be reclaimed if it will never be needed again within the same job. Otherwise, errors and unpredictable results may occur if other programs later attempt to access the resources that were reclaimed. Therefore, this command should normally only be used in the controlling program of an application. Specifying ACTGRP(*ELIGIBLE) requires full knowledge of the job environment. Otherwise, unpredictable results can occur.

Determine the appropriate use of the scoping parameters for Override commands and Open commands, such as OPNDBF and OPNQRYF

<< Previous Section | Home | Next Section >>