Network-Level Queues
Network-level queues allow IPC to occur between processes located in different sessions. Such operation represents IPC at the widest possible scope, that is, from one user ID to another. This facility can be used to let multiple users run a single cooperative application based on queues. It can also be used to implement servers based on IPC.
When a network-level queue is created, it resides in the same session as the process that created it. Other processes in that session access the queue with the same speed as they would have for session-level queues residing in that session. Processes in other sessions access the queue more slowly, because CMS uses a communication carrier on their behalf to reach the remote queue. In either case, the primitives (API calls) used to reach the queue are the same as those used to reach queues of other scopes.
Largely speaking, programs using the queue API need not be sensitive to whether the queues being manipulated are located at the network level. One point to keep in mind, though, is that network-level queues are one of the few constructs in CMS where interprocess aspects of the CMS process model, that is, those process model traits relating to the interaction of one user process with another, come to light. When two CMS application programs communicate with one another through network-level queues, they are exposed to timing, synchronization, and scope-of-recovery effects not seen within a single CMS application. For example, consider a client-server situation where the client and server components are separate CMS applications, each one residing in its own virtual machine. Each must be written to expect that the partner might not yet be started; CMS may not automatically start a queue-based server in response to QueueOpen requests from clients. Programmers need to keep in mind that they must account for such effects when writing distributed applications with CMS.
To facilitate the selection of retry strategies, the queue API provides reason codes indicating the kind of retry an application might choose to attempt. One such reason code indicates that an operation might succeed if the application simply retries it. The out of storage indicator is an example of this kind of reason code. Another reason code, returned only when network-level queues are involved, indicates that the connection to the remote CMS application has been lost. In this case, the application's only recourse is to try to re-establish the connection to the remote application by reopening the remote queue. Depending on the nature of the application, this more serious retry attempt might need to be coupled with some application-dependent recovery procedure.
CMS provides code supporting network-level queue operations using APPC/VM as the carrier. This allows applications to send messages to one another's queues within a VM collection (through TSAF) or across collections (through AVS). CMS also contains interfaces that allow customers to write line drivers to support queue operations over other carriers. For more information on writing IPC carriers, see Remote IPC Support.
For a concrete example that shows how to set up network-level queues based on the following analytical discussion, see Setting Up Network-Level Queues.