Browse Prior Art Database

Generalized Communication Interface

IP.com Disclosure Number: IPCOM000079803D
Original Publication Date: 1973-Sep-01
Included in the Prior Art Database: 2005-Feb-26
Document File: 3 page(s) / 35K

Publishing Venue

IBM

Related People

Edel, TR: AUTHOR [+2]

Abstract

In order for two programs to communicate with each other in current systems (e.g., Inter-task or Inter-partition communication), the sending program and receiving program must have preestablished conventions agreed to with communication areas (e.g., buffers, queues, etc.) bound at compile time. This description defines methods in which a sending program may send messages to one or more destinations and a receiving program may receive messages from one or more sources, without knowing the destination/source programs or number of destinations/sources to which communication is to be achieved.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 55% of the total text.

Page 1 of 3

Generalized Communication Interface

In order for two programs to communicate with each other in current systems (e.g., Inter-task or Inter-partition communication), the sending program and receiving program must have preestablished conventions agreed to with communication areas (e.g., buffers, queues, etc.) bound at compile time. This description defines methods in which a sending program may send messages to one or more destinations and a receiving program may receive messages from one or more sources, without knowing the destination/source programs or number of destinations/sources to which communication is to be achieved.

The advantages of the above can be summarized as follows:
. Buffers and queues are not resolved at compile time.
. The destination/source of communication may dynamically

change at execution time, transparent to the using programs.
. The number of destinations is transparent to the sending

program giving a "broadcast" capability.
. The number of sources may vary transparently to the

receiving program, so that a given program may dynamically

accept messages from unknown sources.
. Communication activity may be selectively monitored

transparent to sending and receiving programs.
. By maintaining consistent interfaces, communication to devices

and/or remote nodes of a network may benefit from the same

capabilities. Thus, using programs may be independent of

whether they are communicating with -

another program in the same or remote node (local/remote

transparency),

a device in the same or remote node (local/remote

transparency).

The method of accomplishing the above is to support a program local control block called a "Indirect Communications Vector (ICV)", which provides an indirect control point between a sender/receiver and the queue or buffer for communication. Fig. 1 shows an example of program A communication, with program B. A and B use the agreed symbol "JOE" as follows:
1) Both programs must create ICV's whose entries contain the

symbols which they will use for communication. The fields in

the ICV are initialized to a "Connection" System Service

which will be described.
2) Either program A or program B will be executed first. If user

A executes first, it will issue a SEND command to send a

message to JOE. The SEND (or RECEIVE) command always sends

indirectly to the queue or...