1 0 Ref. C1 - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) (Ref. C1) + _____ _______ ______________ _______ ___ ___ __ 0 Version 8.7 + _______ _ _ 0 8 March 1982 + _ _____ ____ 0 P M Girard + _ _ ______ - 1. Introduction 0 2. Software Structure 0 3. The User's Main Program 0 4. The Dispatcher 0 5. The Distributor Routine 0 6. Inter-Process Message (IPM) Facilities 0 7. Standard Inter-Process "Connections" 0 8. Non-Standard Inter-Process "Connections" 0 9. Asynchronous I/O Facilities 0 10. Timer Services 0 11. Miscellaneous Special Facilities 0 12. Multiple Buffer Pools 0 13. Buffer Utilisation Monitoring 0 14. Handling of User ECB's 0 15. Acknowledgements - APPENDIX 1 : Reply Codes - - - - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 1 1 0 Ref. C1 - 1. Introduction + ____________ - This package was designed to enable software to be written easily in the form of "processes". There are separate versions for use in MVT and under CMS, but the facilities are the same except where otherwise stated. The main difference is that none of the facilities using the UCLA EXCHANGE are available under CMS. Equivalent facilities are provided via VMCF however. In the MVT version, the VMCF package is a module in the MVT nucleus called IEAVMCF, and its functions are used by calling an SVC. In the CMS version, IEAVMCF and the IPC package are linked directly into the user's program. 0 The facilities fall into several categories: 0 (a) A program can be written in a high level language, such as FORTRAN, and yet function as a collection of autonomous processes. Calling and return sequences are all FORTRAN-compatible, and use INTEGER*4 arguments. 0 (b) An inter-process message (IPM) scheme is provided, allowing processes within a single program to communicate by queueing message buffers for each other. 0 (c) Semi-permanent connections can be set up between processes, using the UCLA EXCHANGE software (MVT only) or the RAL VMCF package (MVT or CMS). This method can be used between processes in different programs (and in the VMCF case between different virtual machines), whereas the IPM scheme is more flexible for internal communications. 0 (d) Any process can use the above facilities and also do asynchronous I/O on one or more streams, set timer intervals, and carry out a variety of miscellaneous operations. - The package was designed primarily for use by the Network Control Program (NCP). It can also be used by applications, if required, to provide a Transport Service interface to the Network via VMCF or the UCLA EXCHANGE. - - - - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 2 1 0 Ref. C1 0 2. Software Structure + ________ _________ - It is convenient to think of a program using this package as composed of: 0 a)A main routine, which sets everything up initially. 0 b)A dispatcher which is concealed within the package and which receives control once the main routine has finished. 0 c)A set of autonomous processes, which receive control from the dispatcher when they become dispatchable, and return control when they can do no more work. 0 In fact the processes themselves are effectively concealed within the package. They call a common "distributor" routine (provided by the user), and pass across parameters indicating which process is in control. The distributor routine then calls the appropriate subroutines to resume handling of the process concerned. 0 The package maintains a work-space area for each process, and the user must store in this area (or in ordinary buffers acquired from the buffer pool) any information that needs to be preserved while the process concerned is dormant. This must of course include information on its current status, so that processing can be resumed at the correct place. 0 There is nothing to prevent more than one process from using a common set of routines, so long as all process- specific information is held in the work-space areas or in pool buffers. FORTRAN subroutines can easily be made "serially re-usable" in this way for instance. There is also no objection to the use of overlays. 0 An alternative mode of use of the package is provided for single-process programs. In this mode (called single- + _______ process mode), the process remains effectively in command + ____________ throughout, and must issue an I$WAIT call when it wishes to suspend itself pending a timer expiry or the posting of an ECB. Control returns in this case to the instruction following the I$WAIT call. - The MVT version of the package is written in re-entrant Assembly code using Chris Osland's "R#PACK" macro system. The bulk of the code resides in the link pack area and may be safely used by non-System programs. The CMS version is currently not re-entrant, but could probably be made re- - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 3 1 0 Ref. C1 0 entrant quite easily if this becomes an important requirement. 0 In general, the package does not devote much attention to protecting the user from himself. Some of the grosser forms of error are trapped however. 0 In the MVT version the re-enterable code occupies about 7K, while the Interface linked into the user's load module needs about 1K. The CMS version occupies about 8K. In addition to this, space is GETMAINed in the user's region for process control blocks (PCBs), connection control blocks (CCBs), subchannel control blocks (EXBs), an ECB address list, and a list of PCB pointers the same length as the ECB address list. A PCB requires 28 bytes, a CCB 12 bytes and an EXB 40 bytes (for EXCHANGE connections) or 24 bytes (for VMCF connections). In the VMCF case, the VMCF package will also set up in the user's region (in sub-pool 252 under MVT) a Logical Channel Control Block (LCCB) of 92 bytes or 108 bytes for each connection, depending on whether the connection uses two or four subchannels. - 0 3. The User's Main Program + ___ ____ _ ____ _______ - A definite sequence of calls must be followed. - (a) CALL I$MAIN (NPROC,NCONN,NEXSUB,NECB,NWORK,NVMSUB) 0 This tells the package what control blocks to set up, and the package acquires the necessary core space from within the user's region. The last two arguments are optional, but if NVMSUB is needed, NWORK must be present as well. 0 NPROC is the number of processes to be created. 0 NCONN is the maximum number of "connections" of all types (standard and non-standard, including asynchronous I/O subchannels) that may be open at any one time. 0 NEXSUB is the maximum number of subchannels needed for "standard connections" via the EXCHANGE at any one time. Four channels should be counted for a standard connection involving the NCP, two channels for other standard connections. - - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 4 1 0 Ref. C1 0 NECB is the maximum number of simultaneously awaited events (ECBs). This must be at least equal to NEXSUB + NVMSUB + the number of asynchronous I/O subchannels. There is no need to allow for a timer ECB, because the package will do this automatically. 0 NWORK is the name of an array, into which the process workspace may be copied by the package before a process is dispatched. This is further described at the end of sub-section (e), below. 0 NVMSUB is the maximum number of VMCF subchannels needed at any one time. Connections may use two or four subchannels each. - (b) CALL I$VMCF ('SUBFNAME',NSLOTS,NSUBS,REPLY) 0 This function should be called once for each VMCF Sub- Function required, the maximum number of Sub-Functions being five. 0 'SUBFNAME' is an arbitrary 8-character Sub-Function name. 0 NSLOTS is the maximum number of VMCF connections that may belong to this Sub-Function. 0 NSUBS is the number of subchannels per connection. Unless two is specified, four is assumed. 0 REPLY is set by the package, and should be zero if the Sub-Function has been successfully created. Other possible replies are given in Appendix 1. 0 The user must ensure that the requirements stated in I$VMCF calls do not exceed the total resources specified in the I$MAIN call, and that both ends of a potential connection will use the same number of subchannels. - (c) CALL I$BUF(0,pool array,pool length,N1,L1,N2,L2,...) 0 This defines the buffer pool and is fully described in section 6a. Pool buffers are used for holding process work-space areas and may also be used for general purposes, for inter-process messages, and as transmission or reception areas for inter-process "connections". - - 0 INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 5 1 0 Ref. C1 0 (d) CALL I$BUF(9,array) 0 This call is optional. If used, it provides a buffer monitoring facility as described in Section 13. - (e) A series of I$DISP calls must now be issued, one for each process to be launched. 0 CALL I$DISP (type,workspace length) 0 The "type" is an arbitrary number in the range 1 to 255 assigned by the user and any number of processes may share the same type number. Each process is provided by the package with a buffer from the pool, in which the user can store information that needs to be kept safe while the process is dormant. It is sensible to provide a subset of buffers in the pool of a length suitable for this purpose. 0 A work-space length of at least 8 bytes must be specified. 0 Note: If a 5th argument was used in the I$MAIN call and + ____ if the workspace length in the I$DISP call is negated, the workspace of the process will always be moved into the array indicated before the process is given control, and taken back from the array when control is returned to the dispatcher. This facility is provided to improve efficiency for FORTRAN programs. The workspace length must not exceed 256 bytes if this option is used. If "single-process mode" is used, it is advisable to use this facility, as the location of the workspace itself will not be known. - (f) CALL I$GO (DISTRB) 0 This enters the dispatcher and control should never return. DISTRB is the name of the user-supplied subroutine to be given control by the dispatcher, which will call further subroutines depending upon which process is in control. DISTRB must be declared EXTERNAL in the main program. 0 If the user specifies a zero argument in the I$GO call, the package assumes that "single-process mode" is to be used, and returns control immediately to the instruction following the I$GO call. When the user's single process subsequently wishes to suspend itself, it must issue an appropriate I$WAIT call, as described below. - (g) CALL I$WAIT (N) - 0 INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 6 1 0 Ref. C1 0 This function is for use only if the program contains one process only and has elected to use "single-process mode" by specifying a zero argument in the I$GO call. 0 It is used when the sole process wishes to suspend itself pending a timer expiry or the occurrence of an external event such as the completion of an I$MOVE. If N is zero, no timer is set. If N is positive, control is returned after N/100 seconds or when an external event occurs (in which case the timer is cancelled). If N is negative, control is returned after -N/100 seconds regardless of other external events occurring meanwhile. 0 Control is returned to the instruction following the I$WAIT call. - (h) CALL I$GLOB ('SUBFNAME','USERID ',reason,reply) 0 This function causes a VMCF 'GLOBAL DISCONNECT' message to be sent to the virtual machine indicated by the second argument. The receiving virtual machine should then close down all its VMCF connections with the sending virtual machine's Sub-Function indicated by the first argument. 0 'SUBFNAME' and 'USERID ' are 8-character names. 0 The reason code should be in the range 0 to 9. 0 The reply is set by the package, and possible values are given in Appendix 1. 0 The function may be used at any time. Its main use is likely to be before the corresponding I$VMCF call, to ensure that there are no connections left hanging from a previous loading of the software. It may also be useful for causing all the active calls belonging to a Sub- Function to be cleared (it does not scrap the Sub-Function itself however). Finally, it can be used with a dummy Sub-Function name as a probe to find out if the named virtual machine is avilable. - - - - - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 7 1 0 Ref. C1 0 4. The Dispatcher + ___ __________ 0 Each PCB contains amongst other things a set of bits indicating the dispatchability status of the process. 0 All processes are made dispatchable when the program begins execution, and receive control in the order in which the I$DISP calls were issued by the main program. Each process must return control to the dispatcher when it cannot proceed further for the time being. This is done by means of a normal FORTRAN-compatible return linkage, unless "single-process mode" is in use, in which case it must be done via I$WAIT. 0 Thereafter, a process is only dispatched when an event for which it is waiting occurs. Events that may be awaited include I$OPEN or I$MOVE completions, timer expiry, the availability of a buffer which could not be acquired earlier or the arrival of an inter-process message. 0 The dispatcher dispatches processes in the order in which they became dispatchable. - 0 5. The Distributor Routine + ___ ___________ _______ 0 Unless the program is running in "single-process mode", the dispatcher passes two arguments to the user-supplied distributor routine. The first is a pointer to the work- space buffer and is to be regarded as an array subscript for the buffer pool (treated as a LOGICAL*1 array). 0 The first word of the work-space buffer contains three items, which the user must not interfere with. 0 First half-word: The unique "process id" assigned by the package to the process which is currently in control. This is the "id" that is used where appropriate in SEND, RECEIVE, TRANSFER and other such operations described in later sections 0 Third byte: The process "type" assigned by the user. 0 Fourth byte: The event-wait-field: This contains a series of bit settings giving some guidance on what events have occurred since the process last had control. 0 Bit 0 : Will always be on. Indicates the process is dispatchable. - - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 8 1 0 Ref. C1 0 Bit 1 : An EXCHANGE or VMCF or asynchronous I/O operation may have completed, or some other ECB owned by the process may have been posted. 0 Bit 2 : The timer interval has expired. 0 Bit 3 : A buffer which was awaited may now be available. 0 Bit 4 : A message has arrived from another process. 0 Bit 5 : A "connection" has been transferred to this process. 0 Bit 6 : Available for use by the user via CALL I$PCB(5,ID,MASK). See Section 11. 0 Bit 7 : Available for use by the user via CALL I$PCB(5,ID,MASK). See Section 11. 0 The rest of the work-space buffer may be employed as the user thinks fit. However, the first two bytes will be initialised to X'FFFF' by the package the very first time the process is given control. 0 The second argument passed to the distributor routine allows the process, when it relinquishes control, to set a timer interval after which it is to be re-activated even if nothing else has occurred. This is discussed in the section entitled "Timer Services". 0 If the program is running in "single-process mode", there is no distributor routine, and the user does not know where the work-space is located. However, by using the appropriate arguments in I$MAIN and I$DISP, a copy of the work-space in a user area can be used exactly as if it were the work-space itself. The contents and usage of the work-space are the same as in the normal multi-process mode. Timer intervals can be set using I$WAIT (see Section 3). - - - - - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 9 1 0 Ref. C1 0 6. The Inter-Process Message (IPM) Facilities + ___ _____ _______ _______ ___ __________ 0 These facilities do not use EXCHANGE or VMCF and can only be used between processes within a single program. For this purpose however, they are much more flexible and convenient than the setting up of "connections". 0 Basically, a pool of buffers is created in an area supplied by the user. The buffers may be of several different lengths, and when a process asks for a buffer it will be given the shortest one available that will suit its purpose. If multiple independent buffer pools are required, see also section 12. Buffers may be passed from process to process and there is no limit on the number that can be queued for the attention of any given process. Buffers can also be placed on local queues for the process which owns them. Buffers are not moved around physically in core; everything (except "swapping") is done by a system of pointers. Whenever a buffer is sent to another process, the destination process is made dispatchable unless there are already buffers queued for it, in which case it is assumed to have been made dispatchable already. Whenever a process is unable to get a buffer from the pool, arrangements are made to re-activate it as soon as a buffer is released, so that it can try again. When a process is receiving buffers, it may either ask for the top buffer on the queue, or for the top buffer from a specific source process. If it asks for the latter and fails, arrangements are made to re-activate it whenever any new buffers are added to the queue. + ___ 0 To employ this system, the user must obey a small number of rules concerned basically with the ownership status of the buffers. Most violations will be detected causing an abend of the program. 0 In what follows, all arguments are INTEGER*4. It is necessary to be clear however which arguments need to be variables rather than constants, and these are indicated by a 'V' as the first letter. Arguments not beginning with V may in principle be either constants or variables. - (a) Define the buffer pool + ______ ___ ______ ____ 0 CALL I$BUF (0,pool array,pool length,N1,L1,N2,L2,....) 0 This call MUST be made by all users, whether or not they require the IPM facilities as such. This is because the work-space for each process is stored in buffers acquired from the pool. It is a good idea for this reason to define one or more sub-sets of buffers specifically for this purpose. - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 10 1 0 Ref. C1 0 The pool must be defined by a call from the main program immediately after the last call (if any) to I$VMCF. 0 The pool length argument is the total length in bytes, and the pool array must be aligned on a full-word boundary. Each N1,L1 specifies the number of buffers N1 of length L1 to be provided within the pool. These subsets must be specified in ascending order of lengths, and each length + _______________ must be a multiple of 4 bytes and less than 32K. Up to 10 + ________ __ _ _____ subsets may be defined in the current version. The first buffer of each subset will be forced to a double-word boundary. Subsequent buffers in the subset will be so aligned only if the buffer length specified is not a + ___ multiple of 8. 0 The values L1,L2 etc. refer to actually usable lengths. In fact each buffer has an overhead of 12 bytes, which (as well as losses for subset alignment) must be allowed for when working out the pool length. There is no need for an exact fit: the pool length may be specified larger than necessary. - (b) Get a buffer from the pool + ___ _ ______ ____ ___ ____ 0 CALL I$BUF (1,VPOINT,LENGTH) 0 This gets the smallest buffer available which has at least the length specified, and returns a pointer to it in VPOINT. The pointer is to be interpreted as as array subscript for the buffer pool array, which is regarded as having a LOGICAL*1 structure. Clearly the user cannot be prevented from over-writing material outside the buffer he has acquired, but if he does so the pool structure will be damaged and unpredictable results will ensue. 0 The calling process becomes the "owner" of the acquired buffer. 0 If a buffer cannot be obtained, a pointer value of zero is returned and the package will re-activate the process to try again when there is a possibility of success. - (c) Send a buffer to another process + ____ _ ______ __ _______ _______ 0 CALL I$BUF (2,POINTER,destination id) 0 This queues the buffer whose array subscript is "POINTER" for the process whose "id" is indicated. - - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 11 1 0 Ref. C1 0 Only the owner of a buffer may send it, and only if it is not on a local queue and not already in transit to another process. Although the buffer becomes queued for the other process, the sender remains the owner until the other process has picked it up. The owner cannot release a buffer while it is in transit to another process. 0 Normally, the buffer is put on the end of the queue. If the top bit of the 3rd argument is set on however, the buffer will be put on the front of the queue. 0 The other process will be made dispatchable if the new buffer is the sole item on its input queue, or if it is awaiting a buffer from a specific source. - (d) Examine a buffer from another process + _______ _ ______ ____ _______ _______ 0 CALL I$BUF (3,VPOINT,VSOURCE) 0 This examines the input queue of the current process for buffers sent by other processes. If the caller sets VSOURCE=0, the package will return in VSOURCE the source "id" of the top buffer on the queue. If the caller sets VSOURCE non-zero, the package will scan the input queue for a message from that source. In either case, a pointer to the buffer will be returned in VPOINT, or zero if none is found. 0 This operation is purely for information and in no way changes the status of the message. The caller must not therefore behave as if he has actually taken the message in, and indeed he is not yet the owner. - (e) Receive a buffer from another process + _______ _ ______ ____ _______ _______ 0 CALL I$BUF (4,VPOINT,VSOURCE) 0 This is the same as the previous case, except that it actually takes the buffer from the input queue and makes the caller the owner. - (f) Swap a buffer + ____ _ ______ 0 CALL I$BUF (5,VPOINT,LENGTH) 0 CALL I$BUF(5,VPOINT,LENGTH,CLASS) 0 This tries to obtain a shorter buffer (of length as specified) than the one pointed to by VPOINT. If successful, it transfers the contents to the new buffer - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 12 1 0 Ref. C1 0 (by physical transfer), releases the old one to the pool, and returns the new pointer in VPOINT. If a shorter buffer is not available, no action is taken. 0 If the 3-argument form is used, a buffer of the same 'class' as the original is assumed to be required. 0 Only the owner of the buffer may use this function, and then only if the buffer is not queued for another process, nor on a local queue. - (g) Put a buffer on a local queue + ___ _ ______ __ _ _____ _____ 0 CALL I$BUF (6,POINTER,QHEAD) 0 The caller's variable QHEAD is treated as the head of the queue, and the buffer is added to the end of the existing chain if any. If no queue exists yet, the caller must initialise QHEAD to zero, but must not subsequently modify it. 0 Only the owner can use this function. A buffer cannot be simultaneously on a local queue and in transit to another process, nor can it be released while on a local queue. - (h) Take a buffer from a local queue + ____ _ ______ ____ _ _____ _____ 0 CALL I$BUF (7,VPOINT,QHEAD) 0 This removes the top buffer from a local queue whose head is QHEAD, and places a pointer to it in VPOINT. If no buffer is found, the package sets VPOINT to zero. 0 The buffer must be owned by the caller. - (i) Release a buffer + _______ _ ______ 0 CALL I$BUF (8,VPOINT) 0 This relieves the caller of ownership of the buffer pointed to by VPOINT, and VPOINT is then set to zero by the package. 0 Only the owner may release a buffer, and then only if the buffer is not on a local queue or in transit to another process. The buffer itself is released back to the buffer pool and any processes which have unsucessfully tried to acquire a buffer are made dispatchable, so that they can try again. - 0 INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 13 1 0 Ref. C1 0 (j) Request buffer utilisation monitoring + _______ ______ ___________ __________ 0 CALL I$BUF(9,ARRAY) 0 This facility was mentioned in Section 3, and is described fully in Section 13. - (k) Retrieve a buffer + ________ _ ______ 0 CALL I$BUF (10,VPOINT) 0 This provides a means of retrieving buffers which have been sent to another process, but not yet taken by the latter. On entry, VPOINT must be set to the "id" of the process from which a buffer is to be retrieved. The package then searches that process' input queue for the first buffer from the user's process, removes the buffer from the queue, and returns a pointer to it in VPOINT. If no relevant buffer is found, the package sets VPOINT to zero. - 0 7. Standard Inter-Process "Connections" + ________ _____ _______ ___________ 0 A "connection" is a semi-permanent communications path between two processes which may be in the same or in different programs, and which normally comprises one subchannel for each direction giving a "full-duplex" capability. If the Network Control Program is involved, the connection is normally given an additional pair of channels for passing control information in parallel with data. This provides the basis for a full "Transport Service" interface between applications and the NCP. 0 This section discusses only standard connections, which + ________ use the EXCHANGE software or the VMCF package, but for which the IPC package sets up and maintains all necessary control blocks. There are however provisions for non- standard EXCHANGE connections and for asynchronous I/O, in which cases the user supplies his own control blocks. That is discussed in a later section. - (a) Opening a connection + _______ _ __________ 0 CALL I$OPEN (port,control,address array,reply) 0 The "port" must be in the range 1 to 255 and is private to the calling process (e.g: each process may have its own port no.1). The port number identifies the connection in subsequent operations. - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 14 1 0 Ref. C1 - The second argument should be zero for a standard connection via the EXCHANGE. For a connection via VMCF, it should be 254 to launch a connection or 255 to listen for one. 0 The "address array" may take either of two possible formats as described below, but only the new format is acceptable for VMCF connections. The old format is therefore obsolescent and should be converted as soon as possible. 0 The "reply" argument is set to the response of the EXCHANGE or VMCF package. Details of most responses will be found in Refs M8, M3 or A2. A number of additional reply values from IPC itself may also occur, as detailed in Appendix 1. If a reply other than 0 (which is the normal reply) is obtained, an I$CLOS should be issued to ensure that all control blocks are released. - NEW FORMAT ADDRESSES : A 56-byte area must be supplied, + ___ ______ _________ with contents as follows: 0 (1) Other end address (16 bytes) (2) This end address (16 bytes) (3) Application addressing (16 bytes) (4) Other end USERID (8 bytes) 0 The "other end address", if it is in an MVT system, will take the form of an 8-byte Jobname and an 8-byte TAG or "Sub-Function name". Other systems may use other addressing formats. The "other end address" and (for a VMCF connection) the "other end USERID" must be fully specified if launching a connection (i.e: if 'calling'); if listening for a connection, however, any of these three 8-byte fields may be filled with spaces if the listener does not wish to restrict incoming calls in these respects. In the case of EXCHANGE connections, the user must not set both halves of the "other end address" to spaces, so in the interests of compatibility it is recommended that the second half should always in practice be specified, for both EXCHANGE and VMCF connections. 0 If the package is running in an MVT system, the jobname will be filled in by the package, but the TAG or Sub- Function name must always be specified whether calling or listening. When listening, the "application addressing" fields should be filled with spaces, unless something specific is expected from the other end. If running under CMS, the package will have access to a dummy jobname which it inserts automatically. - 0 INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 15 1 0 Ref. C1 0 OLD FORMAT ADDRESSES : The address array must contain a + ___ ______ _________ "home address" followed by an "away address", each preceded by a length byte whose value includes the length byte itself. The "home address" is an arbitrarily chosen string of up to 8 characters. The "away address" may take various forms: 0 1) JOB.TAG 2) TAG 3) N.TAG 4) *.TAG 5) JOB.* 6) * 0 The JOB name of the other process need only be specified if it is different from the caller's job name. The special job name N refers to the Network Control Program. An asterisk may be used to indicate a non-specified JOB or TAG, but not both. Both JOB and TAG are strings of characters, up to 8 bytes each. - (b) Sending and receiving data + _______ ___ _________ ____ 0 CALL I$MOVE (port,type,length,data address,reply) 0 The "port" specified must be that of a currently open connection. 0 For output, the "type" must be 'PUT ', 'PUTN' or 'PUTA' for the data subchannel, and 'PTC ', 'PTCN' or 'PTCA' for the control subchannel (if used). The presence or absence of the final 'N' or 'A' is significant for VMCF connections only. If 'PUT ' or 'PTC' is used, ordinary data or control information is transmitted, with an accompanying VMCF 'PUSH' signal. A VMCF 'PUSH' signal is indicated by a zero in the final bit of the VMCF User Doubleword, this bit being set to 1 in the absence of a PUSH. 'PUTN' and 'PTCN' imply the transmission of ordinary data or control information with no accompanying 'PUSH' signal. 0 'PUTA' and 'PTCA' imply the transmission of 'special' data or 'special' control information, always with an accompanying 'PUSH' signal. Special data and special control information is indicated by the last-but-one bit of the VMCF User Doubleword, which is normally set to zero, but is set to 1 in this case. The meaning of 'special' is not defined at this level: it is 'special' in whatever manner the higher level applications protocols may choose to define it. However, it has been provided with the Transport Service "ADDRESS" primitive in mind, as - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 16 1 0 Ref. C1 0 the latter requires precisely such a facility on the data streams. 0 For input, the "type" must be 'GET ' or 'GETS' for the data subchannel, and 'GTC ' or 'GTCS' for the control subchannel (if used). The presence or absence of the final 'S' is significant for VMCF connections only. The presence of the 'S' implies that the 'stream-mode get' option is to be used, whereby the operation will not finally complete until either the full number of bytes requested has arrived, or a transmission is received containing a VMCF 'PUSH' signal (see previous paragraph). More than one I$CHEK operation may be needed before final completion occurs. Absence of the final 'S' means that the operation should complete on reception of the full number of bytes requested, or on completion of the VMCF SEND operation issued by the sending end. 0 The "length" must be expressed in bytes. For output it gives the exact number of bytes to be sent, and completion will not occur until the other process has accepted that number of bytes (whether in one or more than one operations). For input, the length is a maximum: Completion may occur before the full number of bytes has arrived, as detailed in the previous paragraph. 0 The "data address" is the address of the data to be sent, or of the area which is to receive incoming data. 0 The "reply" will be set to the response issued by the EXCHANGE or VMCF package (see Refs M8, M3 or A2), or to one of the codes listed in Appendix 1. The normal value of the reply is zero. 0 It should be noted that the above operation merely initiates a transfer of data. The actual transfer can + _________ then be considered to proceed in parallel with further processing. 0 It should also be noted that the user may put up an I$MOVE of type 'GET', 'GTC', 'GETS' or 'GTCS' whenever he is willing to receive input. There is no assumption that the other process has offered any data as yet, and the I$MOVE will merely remain pending until the other end sends something. Likewise an I$MOVE that sends data outwards simply remains pending until the other end takes the data. Thus it never matters which end issues an I$MOVE first. - - - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 17 1 0 Ref. C1 0 (c) Checking an I$OPEN or I$MOVE operation + ________ __ _ ____ __ _ ____ _________ 0 A call to I$OPEN merely issues a request to open a connection, and completion of the request does not normally occur until a matching OPEN request from the other process has been found, or (in the case of "control" = 254) until the listening end rejects it. Meanwhile the user may do other processing or suspend himself as he thinks fit. The same is basically true for I$MOVE requests. 0 It follows that each process must check for completion of the operation when it has reason to believe that it may have occurred. This may be done, for instance, when the process is next dispatched by the dispatcher, but if several possible events are pending, some preliminary guidance on what may have happened can be obtained from the event-wait field in the process work-space (see Section 5). The I$CHEK operation is provided for checking the completion of both I$OPEN and I$MOVE requests. It may be used several times if necessary, but it MUST detect that completion has occurred before another I$MOVE request is made on the same subchannel. 0 The check operation takes the following form: 0 CALL I$CHEK (port,type,reply,status) 0 The "port" is as previously described. 0 The "type" is 'OPEN', 'PUT', 'GET', 'PTC', or 'GTC' as appropriate. Only the first 3 characters of the "type" are examined, so in an I$CHEK 'PUTN' is equivalent to 'PUT ' and 'GETS' is equivalent to 'GET '. 0 The "reply" is the content of the ECB as set by the EXCHANGE or IPC package. A zero reply implies that completion has not yet occurred. A top byte of X'40' means that the operation has completed normally. The rest of the reply is undefined except for 'GET' and 'GTC' (or 'GETS' and 'GTCS') operations, where the last bit is set to zero if a VMCF 'PUSH' was received, and the last-but- one bit is set to 1 if VMCF 'special' information was received. If a VMCF 'PUSH' was not received, the last bit of the reply parameter is set to 1. VMCF 'PUSH' and 'special' are discussed to some extent in sub-section (b) above, and in Ref. A3. Other possible replies are given in Appendix 1. If an error has occurred, the user should close the connection by issuing an I$CLOS. 0 The "status" will be set by the package to the contents of the "status word" maintained by the EXCHANGE or by VMCF. In the case of type 'OPEN', when completion has occurred - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 18 1 0 Ref. C1 0 "status" will contain the address of an 8-byte area + _______ holding the other end's virtual machine USERID (VMCF connections only). In other cases of type 'OPEN', "status" is undefined. For types other than 'OPEN', it contains information from which it is possible to calculate the number of bytes actually transferred. The "status" should always be zero on successful completion of a 'PUT', 'PTC', 'PUTN', 'PTCN', 'PUTA' or 'PTCA' operation. On successful completion of a 'GET', 'GTC', 'GETS' or 'GTCS' operation, the top bit will be off if the number of bytes received was less than or equal to the maximum specified in the I$MOVE: The rest of the field gives the difference between the maximum specified and the number received. The top bit will be on if the number of bytes offered by the other end exceeded the maximum specified in the I$MOVE: In this case, the rest of the field gives the number of bytes from the other end which have yet to be taken. In the case of 'GETS' or 'GTCS' with VMCF, the status word cannot still have a positive value on final completion of the I$MOVE operation, unless a 'PUSH' signal has arrived. - (d) Closing a connection + _______ _ __________ 0 CALL I$CLOS (port,reply) 0 This operation does not proceed in parallel; it has immediate effect and the reply is the response returned by the EXCHANGE or VMCF package. The normal reply is zero. No following I$CHEK call should be used. - (e) Transferring a connection + ____________ _ __________ 0 CALL I$TRAN (port,new process' id) 0 This transfers an open connection from the current process to the one whose "id" is specified. The receiving process is assumed to know what it needs to do next on receiving control, and the main application is likely to be the transfer from a process which merely listens for incoming calls to one of a set of processes which actually perform the work. The receiving process is also assumed not to be already using the same port number. 0 Optionally, a third argument may be supplied if further information needs to be transferred to the new process. The value of the third argument, if present, is the number of bytes to be moved from the current process' workspace to the receiving process' workspace, starting in both cases at the 5th byte (counting from 1). - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 19 1 0 Ref. C1 - Another function (I$PCB) is provided to find out the "id" of the new process. This is discussed in the section entitled "Miscellaneous Special Facilities". - (f) Single subchannel connections + ______ __________ ___________ 0 A single subchannel EXCHANGE connection may be created which is nevertheless "standard" in that the package still creates and maintains all control blocks. It is created by setting the second argument of I$OPEN to 1 instead of 0. 0 The "type" parameter in I$MOVE and I$CHEK operations is specified as usual ('PUT' or 'GET'), but as there is only one subchannel the user must take care not to attempt input and output operations in parallel. An error reply will be obtained if this is done. - (g) Two-subchannel EXCHANGE connections to the NCP + ___ __________ ________ ___________ __ ___ ___ 0 These are allowed for special purposes only, and may be specified by setting the second argument of the I$OPEN call to 2 instead of 0. - (h) A note on parameters in the above functions + _ ____ __ __________ __ ___ _____ _________ 0 Unless otherwise stated, parameters are assumed to be INTEGER*4 constants, variables, arrays or array elements. "Reply" must of course be a variable wherever it occurs, and so must the status parameter used with I$CHEK. - 0 8. Non-Standard Inter-Process "Connections" + ___ ________ _____ _______ ___________ - These connections also go via the EXCHANGE, but the aim is to allow the user to supply and organise his own EXCHANGE control blocks while still having access to all the other facilities provided by the IPC package. Except where otherwise stated, the procedure arguments are the same as in the last section. - - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 20 1 0 Ref. C1 0 (a) Opening a connection + _______ _ __________ 0 CALL I$OPEN (port,control array,address array,reply) 0 The control array must consist of a control word followed by sufficient space for one EXB per subchannel (an EXB is an EXCHANGE control block), each preceded by one additional word. 0 The control word must be as follows: 0 Byte 0 = 0 0 Byte 1 = length of one EXB plus 4 bytes (min. 40) 0 Byte 2 = 0 0 Byte 3 = number of subchannels (must be 1 to 4) 0 The rest of the array consists of one EXB per subchannel, each preceded by one word for use by the package. The user may add extent lists or other information to the end of each EXB if he includes these in the length stated. - (b) Sending and receiving data + _______ ___ _________ ____ 0 The user must set up the EXB to his satisfaction before issuing the I$MOVE call. The package will do nothing for him, thus permitting fully flexible use of the EXCHANGE. 0 CALL I$MOVE (port,subchannel number,reply) 0 The subchannel number must be in the range 0 to 3. - (c) Checking an I$OPEN or I$MOVE operation + ________ __ _ ____ __ _ ____ _________ 0 As for standard connections, I$OPEN and I$MOVE merely initiate operations which then proceed in parallel. An I$CHEK call is necessary to test for completion. 0 CALL I$CHEK (port,subchannel number,reply) 0 The subchannel number must be in the range 0 to 3, for checking an I$MOVE operation. For checking I$OPEN, the second argument must be set to 'OPEN'. - - 0 INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 21 1 0 Ref. C1 0 (d) Closing a connection + _______ _ __________ 0 CALL I$CLOS (port,reply) - (e) Transferring a connection + ____________ _ __________ 0 CALL I$TRAN(port, new process' id) - 0 9. Asynchronous I/O Facilities + ____________ _ _ __________ - By setting up a special type of "non-standard connection" (to the data set), the user may do asynchronous I/O operations using EXCP or BSAM. In the CMS version of the package, an EXCP simulation routine is called (using address constant V(SVC0) as entry point) if EXCP is specified. A dummy DCB will then be needed, and the package will call an SVC 19 simulation routine to 'open' this DCB (using address constant V(SVC19) as entry point). This routine must insert a pointer to a dummy DEB, and set the 'open' bit in DCBOFLGS. - (a) Opening a connection + _______ _ __________ 0 CALL I$OPEN (port,control area,DCB,reply) 0 "Port" is as defined for a standard connection. 0 The "control area" consists of: 0 A control word 0 4 bytes for use by IPC 0 A control block 0 The "control word" must contain: 0 Byte 0 = 1 (EXCP) 0 2 (BSAM) 0 Byte 1 = length of control block plus 4 bytes 0 Byte 2 = options byte (For EXCP: as for 'INPUT') 0 INPUT=X'80' (X'C0' for TYPE=J) - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 22 1 0 Ref. C1 0 OUTPUT=X'8F' (X'CF' for TYPE=J) 0 INOUT=X'83' (X'C3' for TYPE=J) 0 OUTIN=X'87' (X'C7' for TYPE=J) 0 UPDAT=X'84' (X'C4' for TYPE=J) 0 Byte 3 = 1 (indicating a one-subchannel connection) - The "control block" must be: 0 For EXCP : An IOB preceded by an ECB 0 For BSAM : A DECB 0 The third argument of I$OPEN is the address of the DCB. 0 The "reply" will be zero for a successful outcome. For other replies, see Appendix 1. - Note : IPC will not alter the DCB or the control block in + ____ any way for the duration of the connection, except for clearing the ECB while processing an I$OPEN or I$MOVE call. - (b) Reading and writing + _______ ___ _______ 0 CALL I$MOVE (port,0,reply) 0 IPC will issue an EXCP or BSAM READ/WRITE as appropriate, and will assume that the DCB and control block are ready for use. A zero reply denotes no error. For errors see Appendix 1. - (c) Checking an operation + ________ __ _________ 0 No checking is required following the I$OPEN. 0 Following an I$MOVE, a check operation MUST be issued: + ____ 0 CALL I$CHEK(port,0,reply) 0 For EXCP, the I$CHEK operation will return zero in the reply if the I/O completion has not yet occurred. Otherwise it will return the contents of the ECB in the reply field. It is harmless to issue the I$CHEK more than once. - 0 INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 23 1 0 Ref. C1 0 For BSAM, the I$CHEK operation will call the BSAM CHECK routine, and so will wait until the I/O is complete before returning control. When it does so, the reply will contain the ECB contents. If the I$CHEK is issued more than once, the reply will be set to the ECB contents always, but BSAM CHECK will not be called again. - (d) Closing a connection + _______ _ __________ 0 CALL I$CLOS(port,reply) 0 A non-zero reply indicates that the DCB was not successfully closed. - 0 (e) Comments + ________ 0 As with all types of "connection" in IPC, the ECB is automatically added to the WAIT list as part of I$MOVE and removed as part of I$CHEK or by the dispatcher (whichever processes it first). The user's process will be dispatched once, and once only, in connection with the posting of an ECB. - 0 10. Timer Services + _____ ________ 0 Each process may set a timer interval when relinquishing control, after which it wishes to receive control again even if nothing else has happened. To set an interval, a value in 1/100 seconds may be returned to the dispatcher in the second argument of the distributor routine. The interval will be cancelled if the process receives control again before it has expired. 0 There is a special mode in which an obligatory interval may be set. In that case the process will not regain control until the interval has expired, even if other events have occurred meanwhile. The effect of this is to "save up" all the other events and present them at a particular time to the process concerned. To use this mode, the argument returned to the dispatcher should be set to minus the required interval. 0 If the package is being used in "single-process mode", the method of setting a timer is different, and involves use of I$WAIT (see section 3(g)). - 0 INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 24 1 0 Ref. C1 - 11. Miscellaneous Special Facilities + _____________ _______ __________ 0 (a) CALL I$PCB (0,type) 0 This allows the "type" of the current process to be altered. It must be in the range 1 to 255. 0 (b) CALL I$PCB (1,type,VID) 0 This locates a process of the "type" specified which is not marked as "claimed". The process is then marked as "claimed" and its "id" is returned in VID. A zero response indicates failure to find an appropriate process. 0 The operation of a process is in no way affected by being "claimed". This is purely a user-level facility to assist in the allocation of processes to particular functions. 0 (c) CALL I$PCB (2,type,VID) 0 This finds a process of the "type" specified without testing whether it is "claimed" or not and without marking it as such. The "id" of the process is returned in VID. A zero response in VID indicates failure to find the process. 0 (d) CALL I$PCB (3,ID) 0 This releases the process indicated from its "claimed" status. If it was not claimed anyway, no action is taken. 0 (e) CALL I$PCB(4,ID,VREP) 0 This tests whether the process indicated is "claimed". If so, a non-zero response is returned in VREP. 0 (f) CALL I$PCB(5,ID,MASK) 0 This makes the process indicated dispatchable and OR's the last two bits of the MASK into the event-wait field (see Section 5). 0 (g) CALL I$PCB(6,IECB) CALL I$PCB(6,IADLST,N) 0 The two-argument form causes the address of IECB (which contains an ECB) to be added to the WAIT list, if it is not already there. 0 The three-argument form causes each of the N ECB addresses found in the INTEGER*4 array IADLST to be added to the WAIT list, if it is not already there. - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 25 1 0 Ref. C1 - It should be noted that, whereas IECB should contain the ECB itself, IADLST should contain, not the ECBs themselves, but the addresses of the ECBs. 0 Before employing these functions, the user is advised to read the section entitled "Handling of User ECBs". 0 (h) CALL I$PCB(7,ID,VREP) 0 This returns in VREP the PCB address of the process indicated, or zero if the process cannot be found. This is likely to be of use only from Assembly-coded routines. The user should not alter anything in the PCB, but may wish to have access to the workspace buffer of another process. Even this is best avoided if possible. 0 (i) CALL I$PCB(8,ID,VREP) 0 This returns in VREP a count of the number of buffers queued upon process ID. If VREP was non-zero on entry, it counts only those which were sent by process VREP. 0 (j) CALL I$PCB(9,IECB) 0 This causes the address of IECB (which contains an ECB) to be deleted from the WAIT list, if it is found to be there. 0 Before employing this function, the user is advised to read the section entitled "Handling of User ECBs". - 12. Multiple Buffer Pools + ________ ______ _____ - The effect of having several independent buffer pools can be created by assigning the buffers to different "classes". If no class is specified, class 0 is used. 0 When defining the buffer pool (see section 6a), each subset of buffers may be assigned to class 1, class 2, and so on by adding 100000, 200000 etc to the respective length arguments. 0 When "getting" a buffer (section 6b), the class of buffer required may be similarly specified in the length argument. 0 No attempt must be made to specify a class value in an I$DISP call (workspace buffers are always assigned from class 0), nor when trying to "swap" a buffer (section 6f). In the latter case, the new buffer is always taken from the same class as the original. - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 26 1 0 Ref. C1 - 13. Buffer Utilisation Monitoring + ______ ___________ __________ 0 CALL I$BUF(9,ARRAY) 0 This function, if required, must be used once only immediately after the I$BUF(0,...) call. It requests the package to maintain buffer utilisation histograms in the array indicated. The length of the array, in bytes, must be at least equal to the total number of buffers in the pool, plus five times the number of buffer subsets requested, plus four. The array must be on a full-word boundary and pre-set to zeroes. The user may subsequently print and zero the histogram part of the array as often as required. 0 The package divides the array up into a control section followed by a series of histograms, one for each buffer subset. The control section consists of NS+1 full-words, where NS is the number of buffer subsets. Each full-word is composed of a half-word which contains the current number of active buffers in that subset, and a second half-word which contains the offset from the start of the array of the first bin of the corresponding histogram. The last full-word in the control section contains the offset of the first byte beyond the end of the last histogram. The histograms are laid out in the order in which the subsets were defined in the I$BUF(0,...) call. 0 Each histogram consists of N+1 bins, where N is the number of buffers in the subset. Each bin is a single byte, and if the count in any bin reaches 255 it is left at that value until the user zeroes it. The first bin will contain a count of the number of times that zero buffers were active when a buffer request was made; the second bin likewise the number of times that one buffer was found to be active; and so on. The top bin therefore records the number of times that the package failed to obtain a buffer from that subset. In the event of such failure, the package may or may not succeed in getting a larger buffer from another subset belonging to the same class. The count found in the top bin of the last subset belonging to each class is thus a measure of how often there was a complete failure to acquire a buffer. 0 The easiest way of printing off the histograms is to do so from a separate process, using the timer facility to activate it at suitable intervals. - 14. Handling of User ECBs + ________ __ ____ ____ - - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 27 1 0 Ref. C1 0 The I$PCB functions for handling user ECBs (see sections 11(g) and 11(j)) are for the benefit of programs which need IPC, but must also carry out asynchronous activities not directly supported by it. For instance they are needed by RL "online" programs, by the NCP, and by programs wishing to use the "DRIO" asynchronous input- output facilities. 0 If a process puts some ECB addresses on the WAIT list before releasing control, this ensures that the process will be re-activated automatically when the dispatcher detects that one or more of these ECBs has been posted. The process itself is then responsible for testing the ECBs to see which ones have been posted, and to act accordingly. The dispatcher will delete from the WAIT list any ECB it finds to be posted. However the user must not assume that a posted ECB has necessarily been deleted from the list, because the posting is asynchronous and may have occurred since the dispatcher last examined it. This causes no problem so long as the user always adopts the following rule:- 0 When the process detects a posted ECB, it must either + ______ explicitly re-insert it on the WAIT list before relinquishing control, or it must explicitly delete it. + __ Both functions are defined in such a way that the desired effect is produced, whether or not an ECB is currently on the list. 0 Care is needed in handling the ECB itself, because in general it may be posted asynchronously by a higher priority task or interrupt routine. An ECB must be zeroed each time a new posting of it begins to be anticipated, and this needs careful synchronisation. For instance, if a new posting gets in asynchronously just before the instruction which clears the ECB, the posting will be missed unless appropriate precautions have been taken. This need for proper synchronisation when clearing the ECB has nothing to do with IPC specifically, and IPC imposes no additional synchronisation problems. 0 In the CMS version, the mechanisms for handling ECBs are exactly the same as under MVT. Waiting is done by loading a wait state PSW, and posting is done by inserting a post code in an ECB and loading a suitable PSW to resume processing. This difference of mechanism is invisible to the user. - 15. Acknowlegements + _______________ 0 The implementation of the MVT version was greatly facilitated by the use of C.D.Osland's "R#PACK" system for writing re-entrant code. - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 28 1 0 Ref. C1 - The UCLA EXCHANGE software is a proprietary product of UCLA, and cannot be made available by RAL to other organisations. - 16. References + __________ 0 M8) UCLA EXCHANGE Manual: "Campus Computing Network" R.T.Braden, S.C.Feigin, 1971. 0 M3) IBM VM/370 System Programmers Guide 0 A2) A Protocol for using VMCF (P M Girard) 0 A3) The Application/NCP Protocol using VMCF (P M Girard) - - - - - - - - - - - - 0 INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 29 1 0 Ref. C1 0 APPENDIX 1 + __________ - REPLY CODES + ___________ - Codes are given in decimal unless otherwise stated. - (a) Certain user errors will produce an ABEND of the program, with one of the following ABEND codes. 0 2601 : Improper call (e.g: wrong no. of args). 0 2602 : Insufficient core or buffer space to get started. 0 2603 : Fourth argument of I$MAIN has proved too small. 0 2604 : Improper use of I$TRAN. 0 2605 : Improper use of IPM facilities. 0 2606 : Attempt to SEND to a non-existent process. 0 2607 : Buffer pool has been corrupted. 0 2608 : Attempt to use a non-existent process. - (b) Responses from I$VMCF + _________ ____ _ ____ 0 -4: This Sub-Function already exists 0 -3: Too many Sub-Functions in use 0 -1: VMCF not available 0 0: Successful completion - (c) Responses from I$OPEN + _________ ____ _ ____ - -4: No free VMCF slot 0 -3: VMCF Sub-Function not known 0 -1: VMCF not available 0 0: Successful initiation of I$OPEN 0 1 to 23 : See References 1 or 2 - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 30 1 0 Ref. C1 - 24: Bad port number 0 28: Port already open 0 32: Bad home or away addresses 0 36: No more control blocks for connections 0 40: Not enough connections defined by I$MAIN 0 44: Invalid arguments 0 48: OS DCB failed to open - (d) Responses from I$MOVE + _________ ____ _ ____ - -10: Connection no longer operational (VMCF) 0 -5: Other end does not support this subchannel (VMCF) 0 0: Successful initiation of I$MOVE 0 1 to 23 : See References 1 or 2 0 24: Bad port number 0 28: Previous operation not (successfully) checked 0 32: Non-existent subchannel 0 36: I$OPEN not (successfully) checked yet - (e) Responses from I$CHEK + _________ ____ _ ____ - Top byte = 0 : 0 24: Bad port number 0 28: Second argument bad 0 32: Non-existent subchannel 0 36: Attempt to check I$OPEN after data flow has begun - - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 31 1 0 Ref. C1 0 Top byte = X'40' : Normal completion. When checking an incoming move operation via VMCF, the bottom bit of the bottom byte is zero if a 'PUSH' was detected, and 1 if a 'PUSH' was not detected. 0 Top byte = X'44', X'48', or X'4C': EXCHANGE errors. (See Ref. 1) 0 Top byte = X'5n' : VMCF connection was disconnected by the other end, with reason code n. The last byte of the reply contains the first byte of the VMCF User Data field. A reason code of zero implies deliberate closure by the remote application process. A reason code of 15 in response to a connection attempt means that the other end was not listening for a call. (See Refs 2 and 3) 0 Top byte = X'60' : An outgoing buffer was rejected by the other end with a VMCF REJECT. The last byte of the reply contains the first byte of the VMCF User Data field. (See Refs 2 and 3) 0 Top byte = X'68' : A VMCF error occurred while trying to take a buffer from the other end. The last byte of the reply contains the VMCF error code. (See Refs 2 and 3) 0 Top byte = X'69' : This end tried to accept an incoming VMCF call, but its VMCF ACCEPT message was refused with the VMCF code given in the last byte of the reply. (See Refs 2 and 3) - (f) Responses from I$GLOB + _________ ____ _ ____ 0 -6 : Invalid parameters 0 -1 : Not authorised to use VMCF 0 0 : Successful issue of GLOBAL DISCONNECT 0 1 to 23 : See References 1 or 2 - - - - INTER-PROCESS COMMUNICATIONS PACKAGE (IPC) PAGE 32