Difference between revisions of "Test268 Section 8"
Kjburkhalter (talk | contribs) (→Differentiate "bind by copy" from "bind by reference") |
Kjburkhalter (talk | contribs) (→Differentiate bound procedure calls from dynamic program calls) |
||
| Line 11: | Line 11: | ||
=== Differentiate bound procedure calls from dynamic program calls === | === 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" === | === Differentiate "bind by copy" from "bind by reference" === | ||
Revision as of 19:42, 20 November 2006
<< 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
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.
