Objects Declared in Connection Blocks

The connection objects for a connection library consist of all the objects that are declared in the connection block, including all procedures or variables. The system creates a separate instance of each connection object for each connection of the library.

References Inside the Connection Block

All connection objects can be referenced by any procedures that are declared later in the same connection block.

References Outside the Connection Block

Statements outside the connection block can reference most objects declared in the connection block by prefixing the object with the connection library name and the connection index. The access rules are the same as for structure blocks. See the ALGOL Programming Reference Manual for the details.

Usage Before and After Linkage

For either ALGOL or NEWP, when objects in a connection library are used by statements in the same program, the following rules apply:

Usage by the Matching Library Program

The matching connection library program has more limited access to objects in this connection library. The matching program can access only objects that are exported by the connection library, and can access these objects only after library linkage. The matching program does not have access to any variables declared in the connection block, unless those variables are explicitly exported. However, exported procedures can provide indirect access to connection block variables or procedures that are not exported.

Values Retained between Repeated Linkages

If a connection is linked, delinked, and relinked, all connection objects retain their last value. The connection objects are not automatically reinitialized during linkage. However, you can design a CHANGE or APPROVAL procedure to include statements that initialize connection objects.

Connection Objects Example

The following ALGOL example illustrates several issues regarding the visibility of connection objects:

REAL RVAL;
EBCDIC ARRAY LIBF[0:23];

TYPE CONNECTION BLOCK CL_CSPEC;
   BEGIN
   INTEGER CONN_INT;

   PROCEDURE PROC1;
      BEGIN
      CONN_INT:= * + 10;
      END;

   PROCEDURE PROC2;
      IMPORTED;

   REAL PROCEDURE PROC3;
      BEGIN
      PROC3:= CONN_INT;
      END;
   EXPORT PROC3;
   END;

CL_CSPEC LIBRARY CL_ONE (LIBACCESS = BYFUNCTION,
                         FUNCTIONNAME = “TESTF.”,
                         CONNECTIONS = 2);

CL_ONE[0].PROC1;
CL_ONE[1].PROC1;
RVAL:= CL_ONE[0].PROC3;

REPLACE LIBF BY “LIB1.”;
LINKLIBRARY (CL_ONE[0], INTERFACENAME = LIBF);
REPLACE LIBF BY “LIB2.”;
LINKLIBRARY (CL_ONE[1], INTERFACENAME = LIBF);

CL_ONE[1].PROC2;

Explanation of Example: Objects Visible within Program

In the preceding example, PROC1 is provided to allow statements in the same program to indirectly access the connection object CONN_INT. Any changes made to CONN_INT are local to a single connection of the library.

Explanation of Example: Procedures Invoked Before and After Linkage

Procedures PROC1 and PROC3 can be invoked before library linkage because neither is an imported procedure. Procedure PROC2, which is imported, can be invoked only after library linkage. This illustrates using connection libraries to simultaneously import and export objects. However, the potential performance problems of using two-way connections that contain both imported and exported objects should be considered before designing an application in this way. For more information, refer to Design Strategies for Linking Libraries.

Explanation of Example: Objects Visible to Matching Libraries

Of the objects declared by library CL_ONE, the only object that can be used by the matching libraries is PROC3. This is true because the only object listed in the EXPORT statement is PROC3. However, PROC3 does provide the matching library with indirect access to the connection variable CONN_INT.