Test268 Section 8
<< Previous Section | Home | Next Section >>
Contents
- 1 Section 8 - ILE (11%)
- 1.1 Create and use Binding Directories
- 1.2 Differentiate bound procedure calls from dynamic program calls
- 1.3 Differentiate "bind by copy" from "bind by reference"
- 1.4 Determine appropriate use of activation groups
- 1.5 Create and use Service Programs
- 1.6 Create and use multi-module programs
- 1.7 Determine the impact and appropriate use of the DFTACTGRP (Default Activation Group) parameter on the CRTBNDRPG (Create Bound RPG) command
- 1.8 Determine causes of and ways to avoid Signature Violation errors when using Service Programs
- 1.9 Determine appropriate use of the RCLACTGRP (Reclaim Activation Group) command
- 1.10 Determine the appropriate use of the scoping parameters for Override commands and Open commands, such as OPNDBF and OPNQRYF
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)
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.
Create and use Service Programs
Create and use multi-module programs
Determine the impact and appropriate use of the DFTACTGRP (Default Activation Group) parameter on the CRTBNDRPG (Create Bound RPG) command
Determine causes of and ways to avoid Signature Violation errors when using Service Programs
Don't EXPORT(*ALL) when creating a service program.