Circular connections are library connections that provide the ability to both import and export objects. They are created either by circularly linked server libraries or by two-way connection libraries. Circular connections provide complex and powerful library structures that provide benefits and disadvantages to both server and client libraries.

The benefits of circular connections include the ability to implement advanced concepts such as callback functions and client handlers for service events.

Circular connections have significant limitations that degrade system performance. Performance degradation results from the increased time required to search through the associated process families to ensure that references and environments belonging to the delinking connections do not persist beyond delinkage. When two-way connections are used, the processor overhead of delinkage is proportionally greater.

Limited Scaling

Library connections create graph structures used by the MCP to denote which stacks or processes need to be searched when each connection is delinked. When applications use circular linkages, they can require that every stack be searched every time one of the connections is delinked. In a large application, this could result in the system seeming to pause and perform no work for several seconds to several minutes. For this reason, avoid circular connections unless they are essential to the design of the application. If circular connections are used, isolate other applications from the environment to reduce the size of the process environment that is searched at delink.

Indirect or Implicit Connections

Two-way connections can be indirect or implicit; that is, two processes can use two separate connection libraries to create separate import and export paths between each other. This creates the same set of interconnected processes that is created if there is only one two-way connection library.

Existing Circular Libraries

Existing circular applications based on the standard client/server library model can be converted to use connection libraries to gain the robustness that they provide. However, the redesign of such applications should attempt to eliminate circularity to avoid the potential performance degradation while incorporating the advantages of connection libraries.

One-Way Connection Libraries

Use one-way connection libraries XE “libraries:whenever possible. You can explicitly define a connection library as a one-way connection library using the IMPORTING or EXPORTING modifier to the Connection Library Declaration Statement in both ALGOL and NEWP. This form of library enables a design to take advantage of most of the features of connection libraries without encountering the performance problems that two-way connections and circular linkages can cause. The compilers and the MCP ensure that a linkage operation does not create a two-way import/export relationship with current library and IPC relationships.

Use of either the IMPORTING or the EXPORTING modifier instructs the compiler to issue a syntax error if an importing connection library contains exports or an exporting connection library contains imports. The MCP returns error –26 at library linkage if an importing or exporting connection library has both imports and exports. This error is also returned by the MCP if an explicit one-way connection library had no imports or exports, or if the importing side of the connection is a server library.

When linking importing and exporting connection libraries, the MCP ensures that only a one-way import or export relationship is established; the context of all of the existing library and IPC relationships for the processes being linked are included in this check. If this one-way relationship check fails, a link error of –7 is returned.

A library link error of –27 is returned if an attempt is made to connect either two importing or two exporting connection libraries.

Application design must still avoid linking one-way connection libraries first and then creating loops by linking to either server libraries or connection libraries not specified as IMPORTING or EXPORTING. Loops are checked for only when connections are made that are explicitly marked as IMPORTING or EXPORTING. This kind of inadvertent circularity can be avoided by only using importing or exporting connection libraries within an application. Such an application will avoid the performance drawbacks inherent in two-way connections and circular libraries.

Examples

The use of the IMPORTING and EXPORTING modifiers is illustrated as follows:

Client

TYPE CONNECTION BLOCK SERVICETYPE;
	BEGIN
	PROCEDURE REQUEST (BUF);
		ARRAY BUF [*];
		IMPORTED;	
	END SERVICETYPE;

SERVICETYPE SINGLE IMPORTING LIBRARY SERVICE
	(LIBACCESS = BYFUNCTION,
	 FUNCTIONNAME = “SERVICESUPPORT.”);

SERVICE.REQUEST (BUF);

Server

 TYPE CONNECTION BLOCK SERVICETYPE;
	BEGIN
	PROCEDURE REQUEST (BUF);
		ARRAY BUF [*];
		BEGIN
		. . .
		END REQUEST;
	EXPORT REQUEST;
	END SERVICETYPE;

SERVICETYPE EXPORTING LIBRARY SERVICE;

READYCL (SERVICE);