Interprocess Communication
Shared server libraries provide one of the most sophisticated means for communicating information between processes. Any number of client processes can access the same object by way of a shared library. The client processes can belong to different process families and can be written in different languages.
Capabilities
The main benefit of using a library for interprocess communication (IPC) is the flexible control it provides over the interactions between client processes and shared objects. For example,
-
If a data item is being made available to many different client processes, the library can act to protect the data from being corrupted by a wrongly designed client process.
-
The library can filter information, so that a particular piece of data in an object can be made visible to one client and not to others.
-
A library can provide a simple interface to information that has a complex structure.
Scope of Global Library Objects
The key to using global objects for IPC lies in the addressing environment of an exported library procedure. Such a procedure can access any objects declared globally to it in the library. The rules for determining if a declaration is global to a given ALGOL procedure are discussed in Using Global Objects. Objects declared in COBOL74 libraries are global to the exported PROCEDURE DIVISION unless they are specified as parameters to the PROCEDURE DIVISION. For information about the scope of declarations in other languages, refer to the appropriate programming language manuals.
Parameters from Client Process
A library procedure can also access objects that are passed to it as parameters by a client process. These parameters can be used to inform the library procedure of changes that need to be made to a global object.
Typed Procedures
If the library procedure is a typed procedure, then you can use the return value to transfer information about the global object back to the client process. You can also use parameters that are passed to the procedure, by name or by reference, to transfer information back to the client process.
Accessing the Same Library Instance
For client processes to communicate through a server library, they must access the same instance of the library. You can ensure this by following these steps:
-
Set the SHARING option to SHAREDBYALL. This prevents a separate instance of the library from being initiated each time a new client process links to the library.
-
Use a permanent freeze in some cases. A library with a temporary freeze suffices for most cases, because it does not resume until all client processes have terminated. However, if there will be periods of time when no client processes are linked to the library, and the communication information needs to be preserved, then a permanent freeze must be used. This preserves the library instance until it is thawed by an operator command or a programmatic change to the STATUS task attribute.
Local Objects in Library Procedures
Note that objects declared within a library procedure cannot be used for IPC. Even if client processes access the same instance of a library, they receive different instances of any exported library procedure when they invoke that procedure. Changes made to these local objects by one client process are not visible to other client processes. OWN objects are an exception to this rule, and are discussed separately under Restrictions on OWN Objects in Server Libraries later in this section.
Ensuring One-at-a-Time Access to Objects
A library can be written to ensure that only one client process can access a particular global object, or group of global objects, at a time. For example, the library procedure that accesses a particular global object could be written to first procure a globally declared event, then access the global object, and then liberate the event. If all the library procedures that modify the global object are written this way, then the global object is protected from conflicting updates by different client processes.
Controlling the Order in Which Processes Access Objects
Events can also be used to ensure that client processes access a global object in a certain order. For example, assume that client process A is supposed to access a particular global object before client process B does. Client process B could invoke a library procedure that waits on a certain global event. This event might be one that is caused only at the end of the library procedure called by client process A.
Discontinued Processes and Shared Events
When designing a library, you must be aware of the fact that any of the client processes might be discontinued while executing a procedure from the library. If the library procedure being executed has procured an event, but has not yet liberated the event, then the event remains procured. Other client processes waiting to procure the event wait indefinitely. You can prevent this problem in either of the following ways:
-
Include a CHANGE procedure in the server library process. Each time a client process delinks, the system passes a parameter to the CHANGE procedure indicating whether the delinkage is caused by the client process terminating abnormally. The server library could respond to this notification by, for example, liberating all global events whenever any client terminates abnormally. For information about the CHANGE procedure, refer to Monitoring Client Process Linkage later in this section.
-
Use features such as EPILOG and EXCEPTION procedures to ensure that clients can perform cleanup actions during an abnormal termination. For further information, refer to Discontinued Processes and Events in Using Events and Interlocks.
MYSELF Task Variable
A library procedure can use the MYSELF task variable to access the task attributes of the client process. (In a procedure exported by a frozen library, MYSELF always refers to the client process, not the library.) For example, the library procedure could interrogate the USERCODE task attribute of the client process. The library procedure could be defined to provide different actions for different client processes.
Protecting Against Data Loss
Another point to be aware of is that the information stored in a permanent library can be lost if a system halt/load terminates the library process. The library can protect against this possibility by writing data out to disk files or to a database.
Shared Access Examples
For a simple example of a server library that provides client processes with shared access to a disk file, refer to File Sharing Examples in Using Shared Files.
