Communication system for facilitating in full duplex communication mode and without previously defining sessions between sender and receiver programs5287456Abstract A method of facilitating program to program communication within memory space managed by a given processor. Would-be sender programs communicate with would-be receiver programs via an intermediate communication facility program acting as a central "post office" for the sender and receivers. Receiver programs identify themselves and their status to the communication facility program by registering their identification and status therewith. Thereafter, any would-be sender programs can send messages or data to any receiver programs which have been defined to the communication facility program much as any post office patron can receive mail addressed to the patron. Senders need not be defined to the communication facility program but need only request delivery of data or a message to a targeted receiver. Claims What is claimed is: Description FIELD OF THE INVENTION
TABLE 1
______________________________________
Position (byte) Data Field
______________________________________
1-4 RPB-LEN
5-6 TYPE
7-8 RECOPT
9-12 RETCODE
13-16 WORK-ADR
17-24 SENDER-ID
*17-20 ASCB-ADR
*21-24 ECB-ADR
*21-24 BUFFQ-L
25-32 RECEIVER-ID
33-36 BUFF-LEN
*33-34 AUTH-IND
37-40 BUFF-ADR
*37-40 TCB-ADR
______________________________________
*Note: ASCBADR and ECBADR overlap SENDERID.
AUTHIND overlaps the first twobyte of BUFFLEN.
TCBADR overlaps the BUFFADR.
This type of communication facility can be used generally with any high level or assembler programming language having the capability of supporting a standard program call interface. The requirements and functional capabilities of the call interface will be described in greater detail herein. As shown in Table 1 above, the request parameter buffer (RPB) fields have arbitrarily defined byte format meanings, all of which will be defined in greater detail herein. The call facility (call FAC) is actually implemented by Program A as shown as box 4 in FIG. 1 detailed in FIG. 2 is executed whenever the user program issues a CALL to Program A to use the communication facility. Program A is defined in greater detail in FIG. 2; however, Program A is executed whenever the user program, i.e. a sender or a receiver program issues a "call" command. Program A will check to see in box 2.3 if the intermediate communication facility program 3 (FIG. 1) and Program B in FIG. 1 box 5 are active and will, if Program B is active, cause in boxes 2.3, 2.5 and 2.8 FIG. 2 Program B to be executed at once. Otherwise, a return code will be set in box 2.4, FIG. 2 and Program A will regain control and notify the user program that the communication facility is not available at this time. The general flow for operations will be described with respect to the schematic shown in FIG. 1. Assuming that Program A's check in box 2.3, FIG. 2 of availability for the intermediate communication facility program and Program B are positive, Program B will be executed. Program B, as shown FIG. 3, performs the following processes. First it validates in 5.1 the user request type as a type that is recognized by prior arrangement. It also verifies 5.17 and 5.20 that the user program is an authorized program (if it is a request of the type that requires authorization as will be described in greater detail later). Also, if the user's request requires a check on a given receiver, Program B will verify to see whether the receiver has been defined 5.10 at the communication facility and in 5.13, whether it is currently active or not. Program B will also check to see whether a user program's request is to set a receiver inactive in 5.6 and will verify in 5.7 and 5.10 that the intended receiver has, in fact, already been defined in the communication facility memory area. If the user program's request is to send a data buffer in 5.3 and 5.19, Program B verifies in 5.9 and 5.10 that the intended receiver has been defined already in the memory area assigned for the communication facility. If the user program request is to send an alert in 5.3 and 5.23 to a network management program, Program B verifies 5.9 and 5.10 that the management program has been defined as a receiver in the communication facility memory area. Also, Program B will verify in box 5.20 and 5.21 that a sender program is an Authorized Program Facility (APF) authorized program when a user program's request is to send a data buffer of information to a receiver program which is initialized as an authorized receiver. Additionally, Program B establishes in 5.26 and 5.27 a recovery routine if it is requested. This routine, if an abnormal termination occurs, will be executed and will return control to the requesting user program. Depending upon the type of request presented by the user program, Program B will execute the communication facility program resident within the intermediate memory Program C (in box 5.29), D (in box 5.32) and E (in box 5.31) depending specifically upon the particular request type. Program C in FIG. 4 is executed in response to actions taken by Program B to process user requests of certain types 12 and 14 that will be described in greater detail later. Program C obtains in 6.3, FIG. 4 a data storage area within the intermediate memory area of the communication facility program for holding the user's data buffer of information. Program C then copies in 6.6, FIG. 4 the user's data buffer information from the user memory area of the sending program into the intermediate memory area of the communication facility program. Then, if the intended receiver program is active in box 6.7, FIG. 4 and the receiver's execution control block has not been set in 6.8 to indicate that a message awaits the given receiver, the receiver's control block will be set in 6.9 to so indicate. Program D, (7 in FIG. 1) is shown in FIG. 5. It may be executed by Program B as shown in box 5.32, FIG. 3C, to process requests from user programs of type 22 as will be described later. This is the type of request which is presented to request retrieving a data buffer of information previously stored in a buffer queue for a given receiver program. Program D, checks, in box 7.1, FIG. 5 the receiver buffer queue within the communication facility program memory area to see if there is a message available for reception. It will also check in 7.3 to see if whatever buffer length has been specified by the receiver program is large enough to hold the incoming data buffer contents. It will then copy in 7.5, the data buffer contents in the intermediate memory of the communciation facility program over into the receiver program's memory area and will release, in 7.6, the data buffer storage for reuse in the communication facility memory area. Program E as described in detail in FIG. 6 will be executed by the Program B, box 5.31, FIG. 3, in order to process user program requests of types 4 and 9. If the request from the user is to set a receiver to an inactive state, request type 9, then Program E sets, in 8.4 the receiver status to not active. If the request is to define or initialize a program as a receiver, request type 4, and the receiver has already been defined, it sets, in box 8.5, the receiver status to active, but if the receiver has not already been defined, it will perform the initialization in 8.3 for the receiver and set the status active in 8.5. Program F is shown in FIG. 7, and is executed by the system whenever a user task or memory area is terminated in box 9.1, 9.2 or 9.4. If the terminating task matches in box 9.2 that of one of the defined receivers, the receiver's status will be set to not active in box 9.3 and if the terminating user's memory area matches in box 9.5 one of the receivers, the receiver's status will also be set in box 9.6 to not active. Program G is shown in FIG. 8, is executed by the system when the intermediate memory area is being terminated. It notifies all active receivers by posting a code in the receivers' ECBs in box 10.1, that notifies them that the intermediate memory area is terminated. The processing path and functions are defined by the specific Request Parameter Buffer indicated by the user program's CALL command. The contents of the Request Parameter Buffer fields are identified in Table 1 and have the function or meaning as defined in Table 2 below.
TABLE 2
__________________________________________________________________________
RPB-LEN .fwdarw.
Length of this RPB in bytes (including this field).
(4-byte binary value). (i.e. 40).
TYPE .fwdarw.
Request type.
(2-byte binary value).
`1`-
Request to check if the communication facility
is available to process user requests.
`2`-
Request to check if a receiver program,
as specified in RECEIVER-ID, is active.
`4`-
Request to define and initialize a receiver.
`9`-
Request to set a receiver to not active.
`12`-
Request to send a copy of a user generic
alert buffer to the Network Management
program for processing. The user alert
buffer should include the 8-byte Network
Management Vector Transport header.
`14`-
Request to send a copy of a user data
buffer to the receiver.
`22`-
Request to obtain a data buffer which was
stored in the buffer queue for a receiver.
RECOPT .fwdarw.
This is a recovery option indicator.
(2-byte binary value)
`0`=
No recovery is requested.
`1`=
To request that a Recovery Routine is
provided during this processing.
RETCODE .fwdarw.
Processing return code.
(4-byte binary value).
`0`-
Request completed successfully.
`4`-
Request completed successfully.
The receiver program is not active.
(Or the Network Management Alert
Receiver program is not active if
request type `12` is used).
`10`-
The communication facility is available
to process user requests.
`14`-
The receiver program is active.
`15`-
The receiver program is not active.
`16`-
The receiver program is already active.
`20`-
Invalid request type.
`22`-
User program not executing in primary
addressing mode.
`23`-
User program is not authorized.
`24`-
The communication facility is not active.
`25`-
ASCB address is incorrect.
`26`-
Receiver program is not defined.
`28`-
The communication facility does not
support user request.
`30`-
No data buffer available for the receiver.
`31`-
User buffer size is not large enough to hold
the awaiting data buffer.
`32`-
No storage available.
`34`-
The user alert buffer length exceeds 512 bytes.
`35`-
The receiver buffer queue is full.
`36`-
A Recovery Routine cannot be established
as requested.
`40`-
Invalid SENDER-ID or RECEIVER-ID.
`90`-
Process error occurred.
WORK-ADR .fwdarw.
The address of the work storage space in memory
required for the communication facility service module.
The work storage must be 128 bytes in length (4-byte
binary value).
SENDER-ID .fwdarw.
8-character ID of the sender. (e.g. user module
name, program name or product name).
ASCB-ADR .fwdarw.
The address of the Address Space Control Block
(ASCB) of the receiver program. (4-byte binary
value).
TCB-ADR .fwdarw.
The address of the Task Control Block (TCB) of the
receiver program. (4-byte binary value).
ECB-ADR .fwdarw.
The address of the Event Control Block (ECB) which
a receiver program will wait on to be posted when
data buffers arrived. (4-byte binary value).
BUFFQ-L .fwdarw.
The maximum number of outstanding data buffers
allowed for a receiver buffer queue.
(4-byte binary value).
RECEIVER-ID .fwdarw.
8-character ID for the receiver program.
BUFF-LEN .fwdarw.
Length of the user data buffer. (4-byte binary value).
BUFF-ADR .fwdarw.
The address of the user data buffer. (4-byte binary
value). (If using request type `12`, the user alert
buffer should include the 8-byte NMVT header).
AUTH-IND .fwdarw.
Authorization Indicator. (2-byte binary value).
`0`-
Receiver is initialized as non-authorized.
`1`-
Receiver is initialized as authorized.
A sender program must be APF-authorized in
order to send data buffers to an authorized
receiver.
__________________________________________________________________________
Table 1 above specifies the byte position within the Request Parameter Buffer fields and defines the meaning ascribed thereto. The request types, as shown in Table 2, are arbitrary codings with the meanings as defined for each of the request types shown. The recovery codes and the return codes also are arbitrary and are defined as shown. Other indicators and pointers are as defined in Table 2. The sender ID and receiver ID, bytes 17-24 of the RPB and 25-32 of the RPB as shown in Table 1, must be between one and eight characters in length in this embodiment. These ID's consist of alphanumeric characters or special characters chosen arbitrarily by the user. For operation of the programs that will be described herein, if a given ID is not eight characters in length it is left justified and padded with blank characters. For all types of requests by any user, control of program execution is returned to the user's requesting program following execution of the CALL command. For request type 1, the parameters required are the RPB length and type and the return code can be any of 10, 24, or 28. For request type 2, the required parameters are the RPB length, type, work address and receiver ID, and the return code can be any of 14, 15, 24, 26, or 28. For requests of type 4, the required buffer parameters are length, type, recovery option, work address, address space control block address, buffer queue limit, task control block address, the receiver ID, and the authorization indicator. The buffer queue limit is used to specify the maximum number of outstanding data buffers that will be permitted for a given receiver's buffer queue. If this limit is exceeded, the sender's data buffer of information will not be accepted by the communication facility program and the return code of 35 will be returned. The return codes can be 0, 16, 23, 24, 28, 32, 35, 36, or 40 for this type of request. When the request is completed successfully, the ECB address will contain the address for the ECB for the receiver program. This event control block is posted for execution when the data buffer of information arrives. The user program desiring to send the buffer must be APF authorized in order to use this type of request. For request type 9, the required parameters are: length (RPB-LEN), TYPE, recovery option (RECOPT), work address (WORK-ADR), Buffer Queue Limit (BUFFQ-L), ASCB-ADR, and RECEIVER-ID. The BUFFQ-L is used to specify the maximum number of outstanding data buffers of data that can be accepted for a receiver while it is not active. If this limit is exceeded, the sender's buffer of data will not be accepted and the return code will be 35. Return codes can be any of 0, 15, 23, 24, 25, 26, 28, 35, 36, or 40. A sender program can still send data buffers to an inactive receiver program, so long as the receiver's buffer queue as defined is not full. However, the sending program will receive a return code of 4 to indicate that the receiver program is currently not active. User programs should be APF authorized in order to use this request. For request type 12 the required parameters are: RPB-LEN, TYPE, RECOPT, WORK-ADR, SENDER-ID, BUFF-LEN and BUFF-ADR. The return codes can be any of 0, 4, 23, 24, 26, 28, 32, 34, 35, 36, or 40. A user program can use this request type to send a copy of an alert buffer data to a network management program for processing. For request type 14, the required RPB contents are: RPB-LEN, TYPE, RECOPT, WORK-ADR, SENDER-ID, RECEIVER-ID, BUFF-LEN, and BUFF-ADR. Return codes can be 0, 4, 23, 24, 26, 28, 32, 35, 36, or 40. As before, a sending program can still send data buffers of information to an inactive receiver program, but a return code indicating inactivity of the program will be sent back to the requestor. For the request type 22, the required RPB contents are: RPB-LEN, TYPE, RECOPT, WORK-ADR, ASCB-ADR, RECEIVER-ID, BUFF-LEN, and BUFF-ADR. The return codes can be 0, 23, 24, 25, 26, 28, 30, 31, 36, or 40. The buffer address should be the address of a buffer area within the receiver program address space where an incoming data buffer may be copied. If this request is successful, the sender ID field will contain the identification of the sender program and the buffer length will contain the length of the incoming data buffer. If the specified buffer length is not large enough to hold the incoming data for the intended receiver, the return code will be 31 and the length of the incoming data buffer will be placed in the buffer length field. In this case the receiving program should obtain another buffer large enough to hold the incoming data buffer and try the request again. Returning to FIG. 1, the communication facility program may be seen to actually be constituted by all of the subroutines including programs A through G as depicted in FIG. 1. Each of these programs resides within specified areas of memory within the same processor system, as do the sender program and the receiver program. The individual program portions A through G will now be described with reference to FIGS. 2-8 where the detailed flow chart for each subroutine is illustrated. Turning to FIG. 2, the detailed flow chart for Program A (4 in FIG. 1) the first portion of the communication facility program is shown. The operation of Program A is self explanatory beginning at the top of FIG. 2, box 2.1, where Program A receives the RPB from a user, sender or receiver program. It may be seen that Program A saves in box 2.2 the user's program registers if desired, checks in box 2.3, to see whether the remainder of the communication facility program and memory space is available (if not available, it sets a return code in 2.4), checks, in box 2.5, on whether the request presented is a query facilities request and, if so, sets a return code in box 2.6, or executes in box 2.7 and 2.8 the user's request by utilizing the processing module Program B as shown. It also returns control, in box 2.9 and 2.10 to the user program as its final step, as shown. FIG. 3 illustrates the detailed processing flow of Program B (5 in FIG. 1) beginning from the top box 5.1 where it receives its initiation from Program A. FIG. 3 has various entry and exit points marked with encircled A, B, X as shown. Program B checks in box 5.1, as to whether the user's request type as indicated in its RPB is valid (and if not valid, it sets a return code in box 5.2), whether an initiation in box 5.6 or termination of a receiver program is requested. It validates receiver identification in box 5.7 and if invalid, sets a return code in box 5.8. It finds a receiver anchor control block in box 5.9. It executes the appropriate action of either defining or terminating a receiver as in existence, box 5.31 checks in box 5.3 to see whether the request is to retrieve a buffer of information or to send a buffer of information or to send an alert, box 5.3 through 5.5 or to initiate or terminate as a receiver in box 5.6 through 5.8 and executes in box 5.32 the dequeueing routine D, or the receiver initialization/terminate routine E in box 5.31, or the queueing portion Program C in box 5.29 as indicated. The queueing program is entered as shown in FIG. 4 for program module C by initiation from Program B. This routine handles loading of receiver buffer queue within memory space of the communication facility program. This is accomplished by copying a sender's data buffer in a sender's memory area into the facility's memory area in boxes 6.1 through 6.10. The dequeueing program D is shown in FIG. 5. Dequeueing Program D FIG. 5, receives its input from Program B FIG. 3 and operates as illustrated. No description is needed as the FIG. 5 is self-explanatory. Initiation or termination of a receiver is handled by the Program module E, FIG. 6, which receives its input from Program B, FIG. 3 as shown in FIG. 6. It handles definition or termination of a given user program as a defined receiver to the communication facility program. No further description is needed, as FIG. 6 is also self-explanatory. FIG. 7 illustrates the flow for processing of task or address space termination for Program F (9 in FIG. 1) as shown in FIG. 1. It is executed by an end of task or end of memory address space function from the processor. It has the function of setting the defined receiver to "not active" and returning control to the caller program. The flow of FIG. 7 in boxes 9.1 through 9.7 is also self-explanatory. FIG. 8 illustrates the subroutine Program G(10) from FIG. 1 which is initiated by an operator requiring an end of the program to program information transfer process. As will be appreciated from the foregoing discussion, the program to program communication facility program does not require sender programs to be predefined and does not require set up or maintenance of a "session" in order for communication to occur. Once an intended receiver program has been defined to the communication facility by defining itself, any number of sender programs can start to communicate or send data to the receiver program. A receiver program is allowed to specify to the communication facility whether intended sender programs must be APF authorized in order for communications to be sent to it or not. When sender programs wish to communicate or send data to a receiver, the intermediate communication facility program copies the sender's data into a receiver's buffer queue within the communication facility program's address space, notifies the receiver that it has incoming data, and returns control to the sending program. Unlike typical "session" activity, a sender program doesn't have to wait for the receiver program to receive its data; it can start to send data to the same receiver again or to another receiver as soon as return of control is obtained. The receiver can specify a limit for the number of data buffers of information that the intermediate communication facility program should hold for it within that receiver's buffer queue. Similarly, unlike a "session protocol, a receiver can retrieve its data for processing whenever it is ready. Whenever the receiver issues a retrieve data request, the communication facility will copy the data, one data buffer for each request, into the receiver's address space and memory. Sender programs can still send data to a receiver program even when the receiver program is not currently active. The intermediate communication facility program may accept and hold data for an intended receiver and return a status code to notify the sender program that the receiver is not currently active. The receiver program itself can notify the intermediate communication facility program that it is no longer active and it can specify a limit as to the number of data buffers of information that the communication facility program should accept and hold for it while it is in the inactive state. The communication facility program detects whenever a receiver program terminates normally or abnormally and will set the appropriate status for the receiver to not active. From the foregoing, it will be appreciated that a high level, easy to use program to program communication apparatus and technique have been described that can be used in any type of computer system by programs which use any arbitrarily desired high level programming language that can support standard program call operations. The call operation calls upon the intermediate program to program communication facility program itself entailing modules A-G as illustrated and described in detail and supports asynchronous, full duplex and non "session" oriented communication between user and receiver programs or machines as will be readily appreciated. In view of the foregoing description and indication of applications for the preferred embodiment of the invention, what is set forth in the claims which follow is intended by way of description and not of limitation.
|
Same subclass Same class Consider this |
||||||||||