Browse Prior Art Database

Use of XCF to Facilitate Communication Among Independent Processes

IP.com Disclosure Number: IPCOM000120376D
Original Publication Date: 1991-Apr-01
Included in the Prior Art Database: 2005-Apr-02
Document File: 3 page(s) / 126K

Publishing Venue

IBM

Related People

Hackett, T: AUTHOR

Abstract

A mechanism is disclosed for facilitating communication among multiple independent processes, which cooperate to perform work in a sysplex or a single Multiple Virtual Storage/Enterprise Systems Architecture (MVS/ESA*) host system on behalf of a user at a programmable work station (PWS) or host system. The association of the MVS address spaces containing the processes with the userid of the user is exploited by using the Cross-system Coupling Facility (XCF) of MVS/ESA. The userid is used to generate the XCF Group name. XCF message-out and message-in services are used to achieve the communication capability.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 51% of the total text.

Use of XCF to Facilitate Communication Among Independent Processes

      A mechanism is disclosed for facilitating communication
among multiple independent processes, which cooperate to perform work
in a sysplex or a single Multiple Virtual Storage/Enterprise Systems
Architecture (MVS/ESA*) host system on behalf of a user at a
programmable work station (PWS) or host system.  The association of
the MVS address spaces containing the processes with the userid of
the user is exploited by using the Cross-system Coupling Facility
(XCF) of MVS/ESA.  The userid is used to generate the XCF Group name.
XCF message-out and message-in services are used to achieve the
communication capability.

      This mechanism provides an inter-address space communication
protocol with the following characteristics:
      1.   Processes in independent address spaces or within a single
address space may communicate with each other.
      2.   Processes comprising a single instance of an application
may communicate with each other without interfering with, and without
the cooperation of, other instances of the same application.
      3.   The application program code written for the cooperating
processes need not be aware of MVS/ESA data structures nor explicitly
reserve areas of common storage for communication purposes.
      4.   The application program code written for the cooperating
processes need not establish or maintain awareness of any
cross-memory environment.

      The mechanism is described as it might be utilized by
application programs, called transaction programs, running as a
result of certain Systems Network Architecture (SNA) requests,
referred to as attach requests, received by Advanced
Program-to-Program Communication for MVS (APPC/MVS).  The description
uses a number of terms or concepts in a way that must be clearly
understood in order to avoid confusion.  These terms and concepts are
defined here.
Local System        The system in which transaction programs using
the mechanism described herein are running. The local system is
always an MVS/ESA host.
Partner System      The system which originated the attach requests
resulting in transaction programs being started in the local system.
The partner system may be the local system itself, or it may be a
programmable work station, a computer with an architecture or
operating system different from the local system or a computer of the
same type and running the same operating system as the local system.
Master Program      A transaction program started as the result of an
Advanced Program-to-Program Communication (APPC) attach request
issued by a program in the partner system.  The master program may
supervise, oversee or coordinate the processing of a request
originating at the partner system.
Subordinate Program Also a transaction program started as the result
of an APPC attach request issued by a program in the p...