The Shared Library

IBMBPSR (or its multitasking counterpart).

All references by compiled code to entry points in the shared library have been resolved by the linkage editor to IBMBPSR (or IBMrpSR).

IBMBCCS

Special string conversion

V module. Contains WXTRNs for:

IBMBCCAA, IBMBCACA, etc.

IBMBSFI F-format input conversion director. ./

"

Contains WXTR Ns for:

IBMBCCSA, IBMBCTHD, etc.

IBMBCTH

i'....

E- or F-format-to-arithmetic conversion module. Contains

I WXTRNs for:

I IBMBCEZX, IBMBCHZD, etc.

I

Figure 3.3. Example of use of WXTRNs

Chapter 3: The PL/I Libraries 45

r r

I I

I

,

I

I

I I I

t

.-Dummy IBMBCCAA

----,

\

PROGRAM REGION

Compiled code TCA

V(lBMBCCAA) _~ A(lBMBPSM)

Pick up address of I BMBPSM from TCA.

Pick up address at offset and branch.

Figure 3.4. The shared library during execution

I

~

I

Irt--I I

I I I

I

I

I I

LINK PACK AREA

IBMBPSM

A(IBMBCCAA)

IBMBCCAA

The compiled code address constant for I BMBCCAA is resolved to the dummy IBMBCCAA in the module IBMBPSR. This dummy module picks up the address of IBMBPSM from the TCA, adds a known offset, and picks up the address held at this offset. This is the address of IBMBCCAA in the shared library link pack area.

-

r--Program region IBMBPSR and IBMTPSR

VCONs and WXTRNs for all modules that may be called from shared library but are not included in it.

Dummy entry points for all modules in the shared library, followed by addressing code that passes control to the real modules.

Transfer vectors

Library routines

Figure 3.5. The format of shared library modules

Link pack area (shared library) IBMBPSL, IBMBPSM & IBMTPSM

VCONs for all modules held in the shared library.

Dummy entry points for all modules that may be called from the shared library but are held in the program region. These entry points are followed by addressing code tl1at passes control to the real modules.

Individual modules in the shared library.

---

----~--- - - - - - - - - - - - - - - - -

^-

--Chapter 3: The PL/I Libraries 47

communication between the link-pack-area and the program region is handled by the transfer vectors that are held at the head of each module. communication is necessary in both directions. The compiled program will need to call library subroutines that are held within the link-pack modules in the link-pack-area. Similarly, certain of the modules in the link-pack-area may need to call modules that are not included in the shared library.

The link-pack-area modules IBMBPSL and IBMBPSM, are headed by transfer vectors, which are followed by the individual

library modules in the shared library. The individual modules and the transfer vector are link- c3dited to form one module when the shared library is created. The program region module IBMBPSR consists only of a transfer vector,. (The format of the shared library modules is shown in figure 3.5.) During program initialization, the

addresses of the three modules being used the program region transfer vector contains dummies for all entry points that are held in the shared library;

the link-pack transfer vector contains entry points for all modules that the linkage editor statement INCLUDE PLISHRE. PLISHRE is an alias for the program region modules IBMBPSR and IBMTPSR.

The appropriate module will therefore be loaded by the linkage editor (IBMBPSR for non-multitasking programs; IBMTPSR for multitasking programs). All compiled code external references to shared library module entry points are then resolved to initialization routine. This entry point will, in fact, be a dummy entry point in the link-pack modules.

It is the standard action of the initialization routines to load these parameters into the appropriate fields in the TCA. When the shared library is not in use, meaningless information is loaded into

PROGRAM REGION LINK PACK AREA R12

---

TCA

I I

r - - TPSR

I

Link pack module Link pack module

TPSL

-

^IBMBPSM IBMBPSL or IBMTPSL

Transfer vector

-

Transfer vector TPSM

I

Dummy entry Dummy entry

points with points with

duplicate names duplicate names

I

to all entry points to all entry points called by shared called by shared

library modules library modules

I

but not in shared but not in shared

Program region module library. library.

Compiled Code IBMBPSR or IBMTPSR

~

I

Transfer vector Housekeeping and

Dummy entry

I

Shared library environment

dependant

points with routines.

modules in the

duplicate names shared library.

to all entry points

I

in the shared library

I

- - - -

-Address constant

-

-Dummy Entry

I

- - - -

-Point

-I I

Figure 3.6. Addressing a module in the shared library

Chapter 3: The PL/I Libraries 49

these fields. However, as they are only accessed by the shared library modules, this doe:s no harm.

Initial!~ing the Shared Librar~

The shared library is initialized cy the use of special macrO instructions, as described in the System InformatiQ~ manual.

All five modules must be created at the same time. During the process, the table of VCONs in the link-pack modules, transfer vectors are generated, and the offsets to these VCONs from the head of the transfer vector are placed in the code following the dummy entry points in the program region modules. A similar process is carried out for addresses in the program region. The VCONs within the link-pack modules are resolved by the linkage editor when the link-pack modules are created. The VCONs within the program region modules are qualified by WXTRNS, and are only resolved if compiled code generates an EXTRN for the entry point. such EXTRNs are generated when required, as a normal part of the compilation process, regardless of whether the shared library is being used. The VCONs in the program region modules are resolved by the linkage editor when the

program is link-edited.

The shared library has been designed so that multitasking does not affect it. If PLI.TASK is specified hefore PLI.BASE, the linkage editor statement INCLUDE PLISHRE will result in the module IBMTPSR being loaded and linked in the program re9ion.

When control passes to tbe code following the IBMBPIR entry pOint in IBMTPSR, a request is made to the system 'to load the multitasking shared lii:>rary module IBMTPSM.

The program then runs in the usual manner, with the multitasking modules.

An installation caD specify a shared library that includes only the multitasking or the non-multitasking modules. However both multitasking non-multitasking versions of the program region module will still be created. The module for the \.1nwanted

environment will be a dammy. This prevents problems should an INCLUDE PLISHRE

statement be included in a program that is intended to run in the environment with no shared library. If this process was not carried out, such a statement could result in the incorrect environment being

initialized.

PL/ I Statement DCL TABLE (10) FLOAT DECIMAL (6);

Storage

TABLE (0)

TABLE (1)

TABLE (9)

TABLE (10)

Address of TABLE

Address of descriptor

*RVO=4

Mu Iti plier=4

Upperbound-10 Lowerbound=1

* R VO (Relative virtual origin) is the offset of the actual origin of the array from the virtual origin (the position that element TABLE (0) would hold if it existed)

Virtual origin

Array TABLE (10)

OED

Aggregate locator

Array descriptor

Figure 4.1. Example of descriptor, locator, OED, and storage location of an array

Chapter 4:

PL/I allows the programmer the choice of a large number of data attributes. Normally there is no need for explicit attribute information to be retained until execution, because the methods used to handle the data can be resolved during compilation.

However, there are certain situations where this cannot be done. For example,

adjustable bounds or extents may prevent the data attributes being fully known at compile time, or the data may be being passed to another PL/I procedure or library subroutine. When these situations arise, it is necessary to retain some or all of the data attributes in an explicit form

throughout execution.

The names of variables fall into a similar category. Normally, they need not be explicitly known during execution.

However, for data-directed input/output and the CHECK condition, the names of the

variables need to be known so that they can be associated with the correct values.

When such information must be retained until execution, special control blocks are set up for the purpose. These control logical structure levels, dimensions, and lengths, of all elements within a

appropriate storage locations during execution.

2ymbol ~eblg_~~Q~: This associates symbol tables with the block in which they are known.

Q~criptQr/Loc!to~: This is a term used to describe the control block consisting of a descriptor concatenated with a locator.

Dans le document OS PL/I (Page 58-67)