SYSTEMS COMMUNICATIONS ARCHITECTURE - DEC COMPANY CONFIDENTIAL Page 1 File: SCA.MEM Date: 29-March-1983 Author: William Strecker Abstract: This document describes a communications architecture for building clusters of computer systems. Included are message formats, protocols, and implementation independent interface models. Revision: Description Author Date 0 Outline Strecker 08-Dec-80 1 Definitions Strecker 09-Jan-81 in PASCAL 2 Public Review Strecker 09-Feb-81 3 Path Blocks, H. Levy 10-Dec-81 Disconnect, and Updates 4 Disconnect H. Levy 20-Jul-82 Changes 5 Updates Darrell Duffy 5-Oct-82 6 Minor Updates Darrell Duffy 29-Mar-83 SYSTEMS COMMUNICATIONS ARCHITECTURE - DEC COMPANY CONFIDENTIAL Page 2 CHAPTER 1 INTRODUCTION CHAPTER 2 SCA TOPOLOGICAL NOTATION 2.1 NETWORK . . . . . . . . . . . . . . . . . . . . . 2-1 2.2 SCA CLUSTER . . . . . . . . . . . . . . . . . . . 2-1 2.3 COMMMUNICATIONS SERVICE . . . . . . . . . . . . . 2-1 2.4 SYSTEM ADDRESS . . . . . . . . . . . . . . . . . . 2-1 2.5 PORT . . . . . . . . . . . . . . . . . . . . . . . 2-1 2.6 PORT DRIVER . . . . . . . . . . . . . . . . . . . 2-2 2.7 INTERCONNECT . . . . . . . . . . . . . . . . . . . 2-2 2.8 POINT-TO-POINT INTERCONNECT . . . . . . . . . . . 2-2 2.9 MULTIACCESS INTERCONNECT . . . . . . . . . . . . . 2-2 2.10 PORT ADDRESS . . . . . . . . . . . . . . . . . . . 2-2 CHAPTER 3 SCA TOPOLOGY CHAPTER 4 SCA LAYERING CHAPTER 5 SYSAP-SCS INTERFACE NOTATION 5.1 PROCESS . . . . . . . . . . . . . . . . . . . . . 5-1 5.2 PROCESS NAME . . . . . . . . . . . . . . . . . . . 5-1 5.3 DIRECTORY . . . . . . . . . . . . . . . . . . . . 5-1 5.4 SYSTEM LIST . . . . . . . . . . . . . . . . . . . 5-1 5.5 SYSTEM BLOCK . . . . . . . . . . . . . . . . . . . 5-1 5.6 PATH BLOCK . . . . . . . . . . . . . . . . . . . . 5-1 5.7 CONNECTION . . . . . . . . . . . . . . . . . . . . 5-2 5.8 CONNECTION BLOCK . . . . . . . . . . . . . . . . . 5-2 5.9 CONNECT ID . . . . . . . . . . . . . . . . . . . . 5-2 5.10 DATAGRAM COMMUNICATION SERVICE . . . . . . . . . . 5-2 5.11 DATAGRAM BUFFER . . . . . . . . . . . . . . . . . 5-2 5.12 SEQUENTIAL MESSAGE COMMUNICATIONS SERVICE . . . . 5-2 5.13 MESSAGE BUFFER . . . . . . . . . . . . . . . . . . 5-3 5.14 QUEUED BUFFER . . . . . . . . . . . . . . . . . . 5-3 5.15 BLOCK DATA COMMUNICATIONS SERVICE . . . . . . . . 5-3 5.16 NAMED BUFFER . . . . . . . . . . . . . . . . . . . 5-3 5.17 FLOW CONTROL . . . . . . . . . . . . . . . . . . . 5-3 5.18 CREDIT . . . . . . . . . . . . . . . . . . . . . . 5-3 CHAPTER 6 SYSAP-SCS INTERFACE 6.1 TYPE DEFINITIONS . . . . . . . . . . . . . . . . . 6-2 6.2 CONFIGURATION SERVICES . . . . . . . . . . . . . . 6-5 6.2.1 System Configuration . . . . . . . . . . . . . . 6-5 6.2.2 Path Configuration . . . . . . . . . . . . . . . 6-6 6.3 CONNECTION MANAGEMENT SERVICE . . . . . . . . . . 6-8 6.3.1 Connect . . . . . . . . . . . . . . . . . . . . 6-9 6.3.2 Listen . . . . . . . . . . . . . . . . . . . . 6-10 6.3.3 Accept . . . . . . . . . . . . . . . . . . . . 6-11 SYSTEMS COMMUNICATIONS ARCHITECTURE - DEC COMPANY CONFIDENTIAL Page 3 6.3.4 Reject . . . . . . . . . . . . . . . . . . . . 6-11 6.3.5 Disconnect . . . . . . . . . . . . . . . . . . 6-12 6.3.6 Connect State Poll . . . . . . . . . . . . . . 6-13 6.4 DATAGRAM SERVICE . . . . . . . . . . . . . . . . 6-14 6.4.1 Send Datagram . . . . . . . . . . . . . . . . 6-14 6.4.2 Send Datagram Poll . . . . . . . . . . . . . . 6-15 6.4.3 Receive Datagram . . . . . . . . . . . . . . . 6-15 6.4.4 Receive Datagram Poll . . . . . . . . . . . . 6-16 6.4.5 Cancel Receive Datagram . . . . . . . . . . . 6-16 6.5 SEQUENTIAL MESSAGE SERVICE . . . . . . . . . . . 6-17 6.5.1 Send Message . . . . . . . . . . . . . . . . . 6-18 6.5.2 Send Message Poll . . . . . . . . . . . . . . 6-18 6.5.3 Receive Message . . . . . . . . . . . . . . . 6-19 6.5.4 Receive Message Poll . . . . . . . . . . . . . 6-19 6.5.5 Cancel Receive Message . . . . . . . . . . . . 6-20 6.5.6 Cancel Receive Message Poll . . . . . . . . . 6-20 6.6 BLOCK DATA SERVICE . . . . . . . . . . . . . . . 6-21 6.6.1 Map Buffer . . . . . . . . . . . . . . . . . . 6-21 6.6.2 Unmap Buffer . . . . . . . . . . . . . . . . . 6-22 6.6.3 Read . . . . . . . . . . . . . . . . . . . . . 6-22 6.6.4 Read Poll . . . . . . . . . . . . . . . . . . 6-23 6.6.5 Write . . . . . . . . . . . . . . . . . . . . 6-24 6.6.6 Write Poll . . . . . . . . . . . . . . . . . . 6-25 CHAPTER 7 SCS-PPD INTERFACE 7.1 DATAGRAM SERVICE . . . . . . . . . . . . . . . . . 7-1 7.1.1 Send Datagram . . . . . . . . . . . . . . . . . 7-1 7.1.2 Receive Datagram . . . . . . . . . . . . . . . . 7-2 7.1.3 Return Datagram Buffer . . . . . . . . . . . . . 7-2 7.2 VIRTUAL CIRCUIT SERVICE . . . . . . . . . . . . . 7-3 7.2.1 Start Virtual Circuit . . . . . . . . . . . . . 7-3 7.3 MESSAGE SERVICE . . . . . . . . . . . . . . . . . 7-4 7.3.1 Send Message . . . . . . . . . . . . . . . . . . 7-4 7.3.2 Receive Message . . . . . . . . . . . . . . . . 7-4 7.3.3 Return Message Buffer . . . . . . . . . . . . . 7-4 7.4 BLOCK DATA SERVICE . . . . . . . . . . . . . . . . 7-5 7.4.1 Send Data . . . . . . . . . . . . . . . . . . . 7-5 7.4.2 Request Data . . . . . . . . . . . . . . . . . . 7-6 7.5 RESPONSES . . . . . . . . . . . . . . . . . . . . 7-7 CHAPTER 8 SCS MESSAGES AND DATAGRAMS 8.1 TYPES . . . . . . . . . . . . . . . . . . . . . . 8-1 8.2 SCS CONTROL MESSAGES . . . . . . . . . . . . . . . 8-3 8.2.1 Connect Request . . . . . . . . . . . . . . . . 8-3 8.2.2 Connect Response . . . . . . . . . . . . . . . . 8-4 8.2.3 Accept Request . . . . . . . . . . . . . . . . . 8-5 8.2.4 Accept Response . . . . . . . . . . . . . . . . 8-6 8.2.5 Reject Request . . . . . . . . . . . . . . . . . 8-7 8.2.6 Reject Response . . . . . . . . . . . . . . . . 8-8 8.2.7 Disconnect Request . . . . . . . . . . . . . . . 8-9 8.2.8 Disconnect Response . . . . . . . . . . . . . 8-10 SYSTEMS COMMUNICATIONS ARCHITECTURE - DEC COMPANY CONFIDENTIAL Page 4 8.2.9 Credit Request . . . . . . . . . . . . . . . . 8-11 8.2.10 Credit Response . . . . . . . . . . . . . . . 8-12 8.3 APPLICATION MESSAGE . . . . . . . . . . . . . . 8-13 8.4 APPLICATION DATAGRAM . . . . . . . . . . . . . . 8-14 CHAPTER 9 SCS OPERATION 9.1 RELATION TO PPD VIRTUAL CIRCUIT . . . . . . . . . 9-1 9.2 SCS PROTOCOL VERSION RESOLUTION . . . . . . . . . 9-1 9.3 SCS CONTROL MESSAGE FLOW CONTROL . . . . . . . . . 9-1 9.4 SCS OPERATION DESCRIPTION . . . . . . . . . . . . 9-3 9.5 TYPE, VARIABLE , FUNCTION, AND PROCEDURE DEFINITIONS . . . . . . . . . . . . . . . . . . . 9-5 9.6 CONFIGURATION SERVICE . . . . . . . . . . . . . 9-10 9.6.1 System Block . . . . . . . . . . . . . . . . . 9-10 9.6.2 Path Block . . . . . . . . . . . . . . . . . . 9-12 9.6.3 Configuration Services . . . . . . . . . . . . 9-13 9.7 CONNECTION MANAGEMENT SERVICE . . . . . . . . . 9-15 9.7.1 Connection Block . . . . . . . . . . . . . . . 9-15 9.7.2 Connection States . . . . . . . . . . . . . . 9-19 9.7.3 Connect . . . . . . . . . . . . . . . . . . . 9-21 9.7.4 Listen . . . . . . . . . . . . . . . . . . . . 9-22 9.7.5 Accept . . . . . . . . . . . . . . . . . . . . 9-22 9.7.6 Reject . . . . . . . . . . . . . . . . . . . . 9-23 9.7.7 Disconnect . . . . . . . . . . . . . . . . . . 9-23 9.7.8 State Poll . . . . . . . . . . . . . . . . . . 9-24 9.8 DATAGRAM SERVICE . . . . . . . . . . . . . . . . 9-25 9.8.1 Send Datagram . . . . . . . . . . . . . . . . 9-25 9.8.2 Send Datagram Poll . . . . . . . . . . . . . . 9-25 9.8.3 Receive Datagram . . . . . . . . . . . . . . . 9-26 9.8.4 Receive Datagram Poll . . . . . . . . . . . . 9-26 9.8.5 Cancel Receive Datagram . . . . . . . . . . . 9-27 9.9 SEQUENTIAL MESSAGE SERVICE . . . . . . . . . . . 9-28 9.9.1 Send Message . . . . . . . . . . . . . . . . . 9-28 9.9.2 Send Message Poll . . . . . . . . . . . . . . 9-29 9.9.3 Receive Message . . . . . . . . . . . . . . . 9-29 9.9.4 Receive Message Poll . . . . . . . . . . . . . 9-30 9.9.5 Cancel Receive Message . . . . . . . . . . . . 9-31 9.9.6 Cancel Receive Message Poll . . . . . . . . . 9-31 9.10 BLOCK DATA SERVICE . . . . . . . . . . . . . . . 9-33 9.10.1 Buffer Descriptor Table . . . . . . . . . . . 9-33 9.10.2 Map Buffer . . . . . . . . . . . . . . . . . . 9-34 9.10.3 Unmap Buffer . . . . . . . . . . . . . . . . . 9-34 9.10.4 Read . . . . . . . . . . . . . . . . . . . . . 9-34 9.10.5 Read Poll . . . . . . . . . . . . . . . . . . 9-35 9.10.6 Write . . . . . . . . . . . . . . . . . . . . 9-35 9.10.7 Write Poll . . . . . . . . . . . . . . . . . . 9-36 9.11 SCS SEND . . . . . . . . . . . . . . . . . . . . 9-37 9.12 SCS RECEIVE . . . . . . . . . . . . . . . . . . 9-39 CHAPTER 10 CI PPD OPERATION 10.1 PPD DATAGRAMS . . . . . . . . . . . . . . . . . 10-1 SYSTEMS COMMUNICATIONS ARCHITECTURE - DEC COMPANY CONFIDENTIAL Page 5 10.1.1 Start . . . . . . . . . . . . . . . . . . . . 10-1 10.1.2 Start Acknowledge . . . . . . . . . . . . . . 10-2 10.1.3 Acknowledge . . . . . . . . . . . . . . . . . 10-3 10.2 START VIRTUAL CIRCUIT . . . . . . . . . . . . . 10-4 10.3 CONFIGURATION . . . . . . . . . . . . . . . . . 10-6 10.4 OTHER PPD INTERFACE FUNCTIONS . . . . . . . . . 10-6 CHAPTER 11 NI PPD OPERATION CHAPTER 12 BI PPD OPERATION APPENDIX A PROCESS NAMING APPENDIX B DIRECTORY SERVICE B.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . B-1 B.2 LOCAL DIRECTORY MANAGEMENT . . . . . . . . . . . . B-1 B.2.1 Enter . . . . . . . . . . . . . . . . . . . . . B-1 B.2.2 Delete . . . . . . . . . . . . . . . . . . . . . B-2 B.3 REMOTE DIRECTORY ACCESS . . . . . . . . . . . . . B-2 B.3.1 Lookup Request . . . . . . . . . . . . . . . . . B-3 B.3.2 Lookup Response . . . . . . . . . . . . . . . . B-4 APPENDIX C THIRD PARTY I/O APPENDIX D SCS/PPD TYPE AND LENGTH CODES APPENDIX E REJECTION AND DISCONNECTION REASON CODES APPENDIX F CI START DATA FORMAT APPENDIX G EXAMPLE CI MESSAGE APPENDIX H MINIMAL SUPPORT APPENDIX I CHANGE HISTORY CHAPTER 1 INTRODUCTION This document describes the Systems Communications Architecture (SCA). SCA should be contrasted with a network communications architecture (e.g. DECNET/DNA). SCA is intended to be useful as an I/O architecture in the traditional sense: it is optimized for high performance. This high performance is achieved by restricting the topologies, by specializing the function of the communications services, and by assuming that communicating processes are highly trustworthy. A network communications architecture, in contrast, is designed to support varied topologies, more generalized communication services, and less trustworthy communicating processes. | | This document describes an architecture and is not a functional | specification for an implementation. An architecture document can be | contrasted with a functional specification in several ways: | | o The descriptions of the interfaces (calls) and the data | structures are general and need not be adhered to exactly in | an implementation. They werve to specifiy the services | present but need not restrict additional services provided. | | o An architecture provides a model of an implementation through | which it describes the algorithms used in am implementation. | It is the algorithms that are important and not the details | of the data passing and synchronization that an | implementation uses to embody those algorithms. | | Polling is used as the model of synchronization here because | it is simple to describe and because it requires fewer | interface calls. To describe a model using polling requires | only calls to lower layers and not calls from lower layers to | higher layers. | | The algorithms are important in so far as their results are | visible at interfaces and in the protocol. It may be that | implementations can modify the algorithms and achieve the | same result. | | o Descriptions of protocol messages are exact and their order | is important. These serve to allow all implementations of | the architecture to communicate. INTRODUCTION Page 1-2 The current revision of this document is focused on clusters of systems interconnected with the CI. Later revisions will include additional information on the relation of SCA to the NI and BI. CHAPTER 2 SCA TOPOLOGICAL NOTATION 2.1 NETWORK A set of interconnected systems that communicate using a network communications service (e.g. DECNET/DNA NSP). | | | | 2.2 SCA CLUSTER | A set of interconnected systems that communicate using the Systems Communications Services (SCS). The systems in a cluster are managed by a single system manager and lie within a single security boundary. 2.3 COMMMUNICATIONS SERVICE A module or process that provides a set of communications services to a user. 2.4 SYSTEM ADDRESS The 48-bit address of a system in a cluster or network. More specifically, it is the address of a network communications service and/or an SCS. Not all systems necessarily contain both a network communications service and an SCS. The system addresses are necessarily unique within the cluster or network and are preferably globally unique. System addresses with bit 47 equal to 1 are not allowed. System address 0 is not allowed. 2.5 PORT The interface between an interconnect and the physical processor that implements network communications services and/or SCS. SCA TOPOLOGICAL NOTATION Page 2-2 2.6 PORT DRIVER The software that controls a port. 2.7 INTERCONNECT A physical communications path between ports. 2.8 POINT-TO-POINT INTERCONNECT An interconnect joining two ports. 2.9 MULTIACCESS INTERCONNECT An interconnect joining multiple ports that allows direct communication between all port pairs. An n port multiaccess interconnect is logically equivalent to n(n-1)/2 point-to-point interconnects. The CI (Computer Interconnect) and NI (Network Interconnect) are multiaccess interconnects. | | | | 2.10 PORT ADDRESS | | The 48 bit address of a port on a multiaccess interconnect. The port | address may or may not be related to the system address. For example, | the 48-bit NI port address is normally the system address of the | system it interfaces. CHAPTER 3 SCA TOPOLOGY The basic topology supported by SCA is a fully, directly connected set of systems. This can be realized either by a multiaccess interconnect or an equivalent set of point-to-point interconnects. The purpose of this restricted support is to eliminate the complexity of routing from SCA. The multiaccess CI is the current focus for SCA: CI --------+---------------+---------------+-------- | | | | | | +-----+-----+ +-----+-----+ +-----+-----+ | system |...| system |...| system | +-----------+ +-----------+ +-----------+ Note that the redundant dual path CI is logically a single CI. In large clusters a single CI may have inadequate bandwidth. In this case the acceptable topology is paralleled CI's: CI -----------+---------------+---------------+----- | | | | | CI | --------+---------------+---------------+-------- | | | | | | | | | | | | +-----+--+--+ +-----+--+--+ +-----+--+--+ | system |...| system |...| system | +-----------+ +-----------+ +-----------+ This topology retains the fully interconnected property. SCA TOPOLOGY Page 3-2 Non-fully connected systems may be interconnected using multiple CI's. An example would be several CPU's sharing file storage systems on a common CI but with private paging systems on private CI's: Common CI --------+-----------------+-----------------+-------- | | | | | | +-----+------+ +-----+-----+ +------+-----+ | system X |... | system |... | system Y | +-----+------+ +-----------+ +------+-----+ | | pvt | | pvt CI | | CI | | | | +-----+-----+ +------+-----+ | system | | system Z | +-----------+ +------------+ In this topology system X cannot communicate with system Z using SCS. If the services provided by system Z are to be available to system X, an intercept process (not part of SCA) must be provided in system Y. CHAPTER 4 SCA LAYERING SCA is described as a multilayer communications architecture. Layer 0 is the Physical Interconnect (PI) layer (e.g., the CI). Layer 1 is the Port/Port (PPD) Driver layer, which controls the PI layer and provides reliable, sequential transfers of data between ports on the PI. (In the case of the CI, most of the PPD layer is implemented by the CI port.) Layer 2 is the Systems Communication Services (SCS) layer, which provides the process and system addressing, connection management, and flow control necessary to multiplex the basic PPD data services among multiple users. Layer 3 is the System Applications (SYSAP) layer, which represents the users of SCS. 3. System Applications (SYSAP) ------------------------------------- 2. Systems Communications Services (SCS) ------------------------------------- 1. Port/Port Driver (PPD) ------------------------------------- 0. Physical Interconnect (PI) By analogy to DECNET/DNA the SCA SYSAP layer corresponds to the DECNET/DNA Network Applications layer, SCS to NSP, and PPD to DDCMP. CHAPTER 5 SYSAP-SCS INTERFACE NOTATION 5.1 PROCESS A communicating entity that uses SCS: i.e., a SYSAP. 5.2 PROCESS NAME A 16-byte string that identifies a SYSAP process within a system. See Appendix A. 5.3 DIRECTORY A list of SYSAP process names that exist in a system. See Appendix B. 5.4 SYSTEM LIST A data structure that contains information on systems in a cluster. Included are system chracteristics, system port characteristics, and the state of port-to-port communications with the systems. 5.5 SYSTEM BLOCK A data structure on the system list that describes the characteristics of a system in a cluster. 5.6 PATH BLOCK A data structure on the system list that describes the characteristics of a particular interconnect used for port-to-port communications to a specific system in a cluster. SYSAP-SCS INTERFACE NOTATION Page 5-2 5.7 CONNECTION The synchronization of two connection blocks in the same or different systems to define a logical communications path between processes. A process may participate in more than one connection at a time. 5.8 CONNECTION BLOCK A data structure that contains the state of a connection. 5.9 CONNECT ID The 32-bit identifier of a connection block within a system. This is normally treated as a 16-bit connection number and a 16-bit sequence number. | | | | 5.10 DATAGRAM COMMUNICATION SERVICE | | The transmission of an independent information unit (datagram) over a | connection. Delivery of the datagram occurs with high probability, | but is not guaranteed. Also, the order of delivery of a sequence of | datagrams is not guaranteed. 5.11 DATAGRAM BUFFER A buffer that contains (or can contain) a datagram. In SCA a datagram buffer appears in layers 1, 2, and 3. To avoid copying between layers, a datagram buffer is defined large enough to support layer 1, 2, and 3 data. Layer 3 ignores the layer 1 and 2 data; layer 2 ignores the layer 1 data. | | | | 5.12 SEQUENTIAL MESSAGE COMMUNICATIONS SERVICE | | The transmission of a sequence of independent information units | (messages) over a connection. The messages are guaranteed to arrive | in the order they were sent (without loss or duplication) or an error | condition is indicated to the sender. SYSAP-SCS INTERFACE NOTATION Page 5-3 5.13 MESSAGE BUFFER A buffer that contains (or can contain) a message. A message buffer is also used to contain control information for the block data communications service. In SCA a message buffer appears in layers 1, 2, and 3. To avoid copying between layers, a message buffer is defined large enough to support layer 1, 2, and 3 data. Layer 3 ignores the layer 1 and 2 data; Layer 2 ignores the layer l data. 5.14 QUEUED BUFFER Either a datagram or a message buffer. | | | | 5.15 BLOCK DATA COMMUNICATIONS SERVICE | | The direct transmission of information (block data) between a named | local buffer and a named destination buffer. The transmission takes | place over a connection between the system containing the local named | buffer and the system containing the destination named buffer. The | block data is guaranteed to arrive completely or an error condition is | indicated to the sender. 5.16 NAMED BUFFER A named memory buffer used by the block data service. A buffer name is a 32-bit value. A buffer is considered byte addressable with each byte specified by a 32-bit unsigned offset from the beginning (byte 0) of the buffer. 5.17 FLOW CONTROL The method by which the rate of information flow from the sender to the receiver is controlled. In SCS there is no flow control applied to the datagram service. For the sequential message and block data services, flow is controlled by a credit-based protocol that inhibits a sender from sending information (messages, block data control, or block data) until the receiver has provided a buffer to receive the information. 5.18 CREDIT A logical token held by a sending process that indicates that a receiving process has queued a message buffer to (1) receive a message or (2) permit a block data operation. CHAPTER 6 SYSAP-SCS INTERFACE The SCS interface is modelled as a set of PASCAL functions or procedures of the form: function FUNCTIONNAME ([var] ARGUMENTNAME:TYPE [;[var]ARGUMENTNAME:TYPE]...):FUNCTIONSTATUS; or procedure PROCEDURENAME([var]ARGUMENTNAME:TYPE [;[var]ARGUMENTNAME:TYPE]...); where: [] - indicates optional. var - indicates an output argument. FUNCTIONNAME - the name of the function. PROCEDURENAME - the name of the procedure. ARGUMENTNAME - the name of the argument. TYPE - the type of the argument. ... - indicates replication. FUNCTIONSTATUS - the status of function execution. SYSAP-SCS INTERFACE Page 6-2 6.1 TYPE DEFINITIONS The following PASCAL type definitions apply to the function and procedure arguments: | type BYTE = -128..127; | | WORD = -32768..32767; | | LONG = {32-bit} integer; | | QUAD = packed array [1..8] of BYTE; | | SEPTA = packed array [1..12] of BYTE; | | OCTA = packed array [1..16] of BYTE; | | SYSTEM = packed array [1..6] of BYTE; { system address } | | PORT = packed array [1..6] of BYTE; { port address } | | PROC_NAME = packed array [1..16] of BYTE; { process name } | | CONNECT_ID = record { connect id } | INDEX: WORD; | SEQ: WORD | end; | | SB_INDEX = WORD; { system block index } | | PB_INDEX = WORD; { path block index } | | C_DATA = packed array [1..16] of BYTE; { connect data } | | APPL_MSG_LEN = 0..MAX_APPL_MSG; { SYSAP message length } | | APPL_DG_LEN = 0..MAX_APPL_DG; { SYSAP datagram length } | | BUF_USE = (BLK_ARG,MSG_DG); { variant record selector } | | MSGDG = (MSG,DG); { variant record selector } | | MSG_USE = (CONTROL,APPL); { variant record selector } | | Q_BUF_PTR = ^Q_BUFFER; { address of a queued buffer } | | Q_BUFFER = record { queued command buffer for message, datagram, or block transfer } | NEXT: Q_BUF_PTR; { next buffer in queue } | { PPD layer data } | case BUF_USE of | | BLK_ARG:( { block data command } | SEND_BLOCK_ID: WORD; { connection block index for the transfer } | SEND_XID: WORD; { transaction number } | DATA_LENGTH: LONG; { number of bytes to be transferred } SYSAP-SCS INTERFACE Page 6-3 | SEND_NAME: LONG; { buffer name of source buffer } | SEND_OFFSET: LONG; { starting byte in source buffer } | REC_NAME: LONG; { buffer name of destination buffer } | REC_OFFSET: LONG); { starting byte in destination buffer } | | MSG_DG:( { message or datagram command } | LENGTH: WORD; { length in bytes of following fields } | PPD_TYPE: WORD; { PPD message type code } | SCS_TYPE: WORD; { SCS message type code } | CREDIT: WORD; { number of credits to extend } | REC_CONNECT_ID: CONNECT_ID; { destination connect ID } | SEND_CONNECT_ID: CONNECT_ID; { source connect ID } | case MSGDG of | | DG:( { if Datagram, just include application info. } | DG_TEXT: packed array [1..MAX_APPL_DG] | of BYTE); | | MSG:( { if Message ... } | case MSG_USE of | | CONTROL:( { ... and this is SCS control message, then ... } | MIN_CREDIT: WORD; { credit extended } | STATUS: WORD; { reason for accept/reject } | REC_PROC: PROC_NAME; { destination process name } | SEND_PROC: PROC_NAME; { source process name } | SEND_DATA: C_DATA); { connect data } | | APPL:( { ... else SYSAP message, so just include SYSAP stuff. } | MSG_TEXT: packed array | [1..MAX_APPL_MSG] of BYTE))) | end; | | | { BUF_DESCR = implementation specific named buffer descriptor } | | | | C_STATE = ( { process-to-process connection state } | CLOSED, { connection is closed by command } | LISTENING, { listening for connection request } | CONNECT_SENT, { connect request was transmitted } | CONNECT_REC, { connect request was received } | CONNECT_ACK, { connect response was received } | OPEN, { connection is open } | ACCEPT_SENT, { accept request was sent } | REJECT_SENT, { reject request was sent } | DISCONNECT_SENT, { disconnect message was transmitted } | DISCONNECT_REC, { disconnect message was received } | DISCONNECT_ACK, { response received, waiting for remote disconnect } | DISCONNECT_MATCH { waiting for matching response confirmation } | ); | | FSTATUS = (FAIL,SUCCESS,NULL,NOT_OPEN); { function status } | SYSAP-SCS INTERFACE Page 6-4 | PORT_CHAR = packed array [1..16] of BYTE; { see appropriate port specification } | | VC_STATE = ( { port-to-port virtual circuit state } | MAINT, { maintenance state } | VC_CLOSED, { virtual circuit closed } | START_SENT, { start sequence initiated } | START_REC, { start sequence received } | VC_OPEN { virtual circuit is open } | ); { virtual circuit state }{SYSAPDEF} SYSAP-SCS INTERFACE Page 6-5 6.2 CONFIGURATION SERVICES The configuration services allow the caller to determine the identity of the connected systems and the number of paths to each system. A system block is read by calling CONFIG_SYS. The system block contains information on a remote system, its hardware and software characteristics, and the number of connecting paths. A path block is read by calling CONFIG_PATH. The path block contains port characteristics and the state of port to port communications. The REQ_ID procedure updates the port characteristics field of a path block. 6.2.1 System Configuration This function reads a system block: | function CONFIG_SYS( | ENTRY: SB_INDEX; | var FIRST_PB: PB_INDEX; | var SYS: SYSTEM; | var MAX_DG: WORD; | var MAX_MSG: WORD; | var SW_TYPE: LONG; | var SW_VERSION: LONG; | var SW_INCARNATION: QUAD; | var HW_TYPE: LONG; | var HW_VERSION: SEPTA; | var NODE_NAME: QUAD; | var PORT_COUNT: WORD): | FSTATUS; where: ENTRY the system list entry: entries start at one. FIRST_PB the path block index of the first path to the destination system. SYS the destination system address. MAX_DG the maximum size datagram (in bytes) supported by the destination system. MAX_MSG the maximum size message (in bytes) supported by the destination system. SW_TYPE 4-character ASCII software type of the destination system. SW_VERSION 4-character ASCII software version of the destination system. SYSAP-SCS INTERFACE Page 6-6 | SW_INCARNATION software incarnation of the destination system. | This is initialized by the system at its boot | time. When a ppd vc is established and the | SW_INCARNATION changes from a previous value, it | indicates that all of the system software state | has been lost. HW_TYPE the hardware type of the destination system. HW_VERSION the hardware version of the destination system. NODE_NAME the 8-byte ASCII node name of the destination system. PORT_COUNT the number of ports to the destination system. FSTATUS SUCCESS if entry is valid; FAIL otherwise. 6.2.2 Path Configuration This function reads a path block. The path block index for the first path block to a destination system is determined by first calling CONFIG_SYS for that system. Successive calls to CONFIG_PATH can be made to scan the list of path blocks for a particular system. function CONFIG_PATH( ENTRY: PB_INDEX; var STATE: VC_STATE; var PRT: PORT; var NEXT_PB: PB_INDEX; var SB: SB_INDEX; var CHAR: PORT_CHAR): FSTATUS; where: ENTRY the index of the path block to be examined; path block indices start at one. STATE the virtual circuit state to the destination system over this path. (MAINT, VC_CLOSED, START_SENT, START_REC, VC_OPEN) PRT the destination system port address. NEXT_PB the path block index of the next path to this system, or zero if this is the last path block. SB the system block index of the system block to which this path block is queued. SYSAP-SCS INTERFACE Page 6-7 CHAR the characteristics of the destination system port. (See the appropriate port specification.) FSTATUS SUCCESS if entry is valid; FAIL otherwise. Only if STATE = VC_OPEN can the connection management, datagram, sequential message, and block data services be used. | | REQUEST ID REMOVED SYSAP-SCS INTERFACE Page 6-8 6.3 CONNECTION MANAGEMENT SERVICE | A connection exists in one of several states: CLOSED, LISTENING, | CONNECT_SENT, CONNECT_ACK, CONNECT_REC, ACCEPT_SENT, REJECT_SENT, | OPEN, DISCONNECT_SENT, DISCONNECT_REC, DISCONNECT_ACK and | DISCONNECT_MATCH. | | There are two sides to a connection termed the active side and the | passive side. | | The passive side indicates a willingness to establish a connection by | calling LISTEN. This moves the passive side to the LISTENING state. | | The active side initiates a connection by calling CONNECT. A | CONNECT_REQ message is sent and the state moves to CONNECT_SENT. A | CONNECT_RSP is received with a status of NO_MATCH indicating that no | such process is listening, NO_RESOURCES if no connect block is | available, or CONNECTED if the connection can be handled by the | destination system. The connect request is handed to the destination | SYSAP at this point. When CONNECTED is returned, the CONNECT_ACK | state is entered, otherwise the CLOSED state is entered. | | In the CONNECT_ACK state a REJECT_REQ causing the state to go to | CLOSED or ACCEPT_REQ message can be received causing the state to go | to OPEN. | | When the SYSAP on the destination receives the connect request, it | responds with an ACCEPT causing its side to go to the ACCEPT_SENT | state or a REJECT causing its side to go to the REJECT_SENT. The | appropriate reply from the active side of ACCEPT_RSP causes the state | to go OPEN, and recept of REJECT_RSP causes the state to go CLOSED. When the connection is OPEN, the datagram, sequenced message, and block data services may be used. Either side initiates termination of the connection by calling DISCONNECT. Following the DISCONNECT call, no datagram, sequential message, or block transfer transmission operations can be performed by the disconnecting side. Attempts to initiate a transfer will fail with status NOT_OPEN. The sequence of states is dependent on the order of the DISCONNECT calls. The protocol is generally asymmetric with one side, called the active side, initiating the disconnect. The active side calling DISCONNECT moves to the DISCONNECT_SENT state while the passive side moves to DISCONNECT_REC state. When the active side is notified of receipt of the disconnect request by the passive side, it moves to DISCONNECT_ACK state. Both sides wait for the passive SYSAP to be notified of the request and to respond with its own DISCONNECT. When the passive SYSAP calls DISCONNECT, the passive side moves to DISCONNECT_MATCH and notifies the active side of the SYSAP's action. The active side moves to CLOSED state, and the passive side moves to CLOSED upon confirmation. Should both sides issue DISCONNECT requests simultaneously, the protocol will be symmetric with both active sides moving through states DISCONNECT_SENT, DISCONNECT_MATCH, and CLOSED. SYSAP-SCS INTERFACE Page 6-9 | If there is any failure of lower SCA layers, both sides of any | non-closed connection move to the CLOSED state. The (local side) state of a connection is determined by calling CONNECT_STATE_POLL. Section 9.6 contains a full state table describing the above states and transition conditions. | | SYSAPs that require a minimum size for messages and datagrams operate | in the following manner to assure that these message sizes are present | on a connection: When the SYSAP starts, it checks the message sizes | on the local system and does not perform a LISTEN if the message sizes | are too small. Before a SYSAP performs a connect, it checks the | message sizes of the remote system and does not perform the CONNECT if | the remote systems message sizes are too small. The message sizes can | be determined with the CONFIG_SYS request. 6.3.1 Connect This function allocates a connection block and actively requests a connection: | function CONNECT( | var CID: CONNECT_ID; | SRC_PROC: PROC_NAME; | DST_PROC: PROC_NAME; | DST: SB_INDEX; | THRSH: WORD; | { [CREDITS: Q_BUF_PTR];... } | DATA: C_DATA | { [PATH: PB_INDEX] } | ): | FSTATUS; where: CID the connect id of the connection block allocated by CONNECT. SRC_PROC the local process name. DST_PROC the destination process name. DST the system block corresponding to the destination system. THRSH the minimum number of message buffers the destination process should maintain for proper operation of the SYSAP protocol. | | CREDITS the address of a list of message buffers that | represent an initial credit. SYSAP-SCS INTERFACE Page 6-10 DATA initial connection data. The format of DATA is process specific. PATH optional Path Block index, if SYSAP needs to request connection over a specific interconnect. | | ERROR REMOVED FSTATUS SUCCESS if a connection block is allocated; FAIL otherwise. 6.3.2 Listen This function allocates a connection block and passively listens for a connection request from a destination process: | function LISTEN( | var CID: CONNECT_ID; | SRC_PROC: PROC_NAME; | DST_PROC: PROC_NAME; | DST: SB_INDEX ): | FSTATUS; where: CID the connect id of the connection block allocated by LISTEN. SRC_PROC the local process name. DST_PROC the destination process name. A DST_PROC field of all blanks indicates a willingness to connect to any process. DST the system block corresponding to the destination system. A DST field of 0 indicates a willingness to connect to any system. | | THRSH REMOVED FSTATUS SUCCESS if a connection block is available; FAIL otherwise. SYSAP-SCS INTERFACE Page 6-11 6.3.3 Accept This procedure accepts a requested connection: | procedure ACCEPT( | CID: CONNECT_ID; | { [CREDITS: Q_BUF_PTR];...} | THRSH : WORD; | DATA: C_DATA); where: CID the local connect id. CREDITS the address of a message buffer that represents an initial credit. | | THRSH the minimum number of message buffers the | destination process should maintain for proper | operation of the SYSAP procotol. DATA initial connection data. The format of DATA is process specific. 6.3.4 Reject This procedure rejects a requested connection: procedure REJECT( CID: CONNECT_ID; REASON: WORD); where: CID the local connect id. | | REASON the reason for rejection. See Appendix E. SYSAP-SCS INTERFACE Page 6-12 6.3.5 Disconnect This procedure requests termination of a connection. Following a disconnect call, further transfer requests will be returned with an error. procedure DISCONNECT( CID: CONNECT_ID; REASON: WORD); where: CID the local connect id. | | REASON the reason for disconnection. See Appendix E. | | /Due to the port design of the CI port, there is a restriction in the | CI PPD layer. DISCONNECT cannot be called until all (locally | initiated) outstanding block data transfers have completed. SCS based | on other interconnects need not have this restriction. On some | interconnects waiting for block transfers could be too time consuming | to make waiting practical./ After DISCONNECT is called only the following connection related SCS calls are valid: 1. STATE_POLL 2. SEND_DG_POLL 3. REC_DG_POLL 4. CANCEL_REC_DG 5. SEND_MSG_POLL 6. REC_MSG_POLL 7. CANCEL_REC_MSG_POLL SYSAP-SCS INTERFACE Page 6-13 6.3.6 Connect State Poll This procedure returns the state of a connection: procedure STATE_POLL( CID: CONNECT_ID; var STATE: C_STATE; var DST_CID: CONNECT_ID; var DST_PROC: PROC_NAME; var DST_SB: SB_INDEX; var DST_PB: PB_INDEX; var DATA: C_DATA; var REASON: WORD); where: CID the local connect id. | | STATE the connection state. (CLOSED, LISTENING, | CONNECT_SENT, CONNECT_ACK, CONNECT_REC, | ACCEPT_SENT, REJECT_SENT, OPEN, DISCONNECT_SENT, | DISCONNECT_REC, DISCONNECT_ACK, or | DISCONNECT_MATCH.) DST_CID the destination connect id. DST_PROC the destination process name. DST_SB the system block corresponding to the destination system. DST_PB the path block corresponding to the interconnect over which the connection exists. DATA connect data. REASON the reason for rejection or disconnection. Any queued datagram or message buffers remaining after a connection is closed are disposed of in an implementation specific manner. SYSAP-SCS INTERFACE Page 6-14 6.4 DATAGRAM SERVICE A datagram is sent by calling SEND_DG. A parameter in the SEND_DG call determines whether the buffer containing the datagram to be sent is to be returned or queued to receive a datagram. In the former case, the datagram buffer is returned by calling SEND_DG_POLL. A datagram buffer is queued to receive a message by calling REC_DG. Receipt of a datagram is checked by calling REC_DG_POLL. Return of a queued datagram buffer is requested by calling CANCEL_REC_DG. | | Datagrams are queued and accounted for on a per connection basis. It | is possible to return datagrams quickly to the receive queues when too | many arrive for a connection and thereby make it more likely that | datagram receive buffers are available to connections which carefully | manage the number of datagram receive buffers they queue. 6.4.1 Send Datagram This function sends a datagram over a connection: function SEND_DG( CID: CONNECT_ID; RET_FLAG: boolean; DLEN: APPL_DG_LEN; PTR: Q_BUF_PTR): FSTATUS; where: CID the local connect id. RET_FLAG true if the datagram buffer is to be returned, false otherwise. DLEN the length (in bytes) of the datagram text. PTR the address of the datagram buffer. FSTATUS SUCCESS if the send is queued, NOT_OPEN if the connection has been closed. When RET_FLAG is false, SEND_DG does an implicit Receive Datagram since the datagram buffer is available after sending to receive a datagram. SYSAP-SCS INTERFACE Page 6-15 6.4.2 Send Datagram Poll This function checks the return of a datagram sent with the RET_FLAG true: function SEND_DG_POLL( CID: CONNECT_ID; var PTR: Q_BUF_PTR): FSTATUS; where: CID the local connect id. PTR the address of the datagram buffer. FSTATUS SUCCESS if the buffer is returned; FAIL otherwise. Note that the original buffer contents are returned intact. 6.4.3 Receive Datagram This function queues a datagram buffer to receive a datagram: function REC_DG( CID: CONNECT_ID; PTR: Q_BUF_PTR): FSTATUS; where: CID the local connect id. PTR the address of the datagram buffer. FSTATUS SUCCESS if the receive buffer is queued, NOT_OPEN if the connection has been closed. SYSAP-SCS INTERFACE Page 6-16 6.4.4 Receive Datagram Poll This function checks if a datagram has been received in a previously queued datagram buffer: function REC_DG_POLL( CID: CONNECT_ID; var DLEN: APPL_DG_LEN; var PTR: Q_BUF_PTR): FSTATUS; where: CID the local connect id. DLEN the length (in bytes) of the datagram text. PTR the address of the datagram buffer. FSTATUS SUCCESS if a datagram has been received; FAIL otherwise. 6.4.5 Cancel Receive Datagram This function dequeues a datagram buffer: function CANCEL_REC_DG( CID: CONNECT_ID; var PTR: Q_BUF_PTR): FSTATUS; where: CID the local connect id. PTR the address of the datagram buffer. FSTATUS SUCCESS if a buffer is dequeued; FAIL otherwise. SYSAP-SCS INTERFACE Page 6-17 6.5 SEQUENTIAL MESSAGE SERVICE A message is sent by calling SEND_MSG. A parameter in the SEND_MSG call determines whether the buffer containing the message is to be returned or queued to receive a message. In the former case, the message buffer is returned by calling SEND_MSG_POLL. A message buffer is queued to receive a message by calling REC_MSG. Receipt of a message is checked by calling REC_MSG_POLL. Return of a queued message buffer is requested by calling CANCEL_REC_MSG. The queued message buffer is returned by calling CANCEL_REC_MSG_POLL. The sequential message service uses credit-based flow control. Consider two sides of a connection X and Y. When X queues a message buffer, Y receives a send credit. In general, if Y queues y buffers and X queues x buffers, Y has x send credits and X has y send credits. To send a message, a send credit is needed. When the message is sent, the number of send credits is decremented by 1. In order to support messages of different importance on a single connection, a threshold mechanism is employed. A threshold parameter appears in two places: 1. When a connection is established each side specifies a threshold which is the minimum number of queued message buffers the other side should maintain for proper operation of the SYSAP protocol (i.e. the support of messages of different importance). A CANCEL_REC_MSG call does not return buffers that would drop the number of send credits on the other side below the SYSAP protocol threshold. 2. A SEND_MSG call (also the READ and WRITE calls: see the section on block data service) has a threshold number that results in a message being sent only if at least that number of send credits would remain after sending the message. SYSAP-SCS INTERFACE Page 6-18 6.5.1 Send Message This function sends a message over a connection: function SEND_MSG( CID: CONNECT_ID; THRSH: WORD; RET_FLAG: boolean; MLEN: APPL_MSG_LEN; PTR: Q_BUF_PTR): FSTATUS; where: CID the local connect id. THRSH the message is sent only if at least this many send flow control credits will remain. The minimum value of THRSH is 0. RET_FLAG true if the message buffer is to be returned; false otherwise. MLEN the length (in bytes) of the message. PTR the address of the message buffer. FSTATUS SUCCESS if the send is queued, FAIL if no flow control credit is available, NOT_OPEN if the connection has been closed. When RET_FLAG is false, SEND_MSG does an implicit Receive Message since the message buffer is available to receive a message. 6.5.2 Send Message Poll This function checks the return of a message sent with the RET_FLAG true: function SEND_MSG_POLL( CID:CONNECT_ID; var PTR: Q_BUF_PTR): FSTATUS; where: CID the local connect id. PTR the address of the message buffer. FSTATUS SUCCESS if a buffer is returned; FAIL otherwise. SYSAP-SCS INTERFACE Page 6-19 Note that the original buffer contents are returned intact. 6.5.3 Receive Message This function queues a message buffer to receive a message and extends a flow control credit to the destination process: function REC_MSG( CID: CONNECT_ID; PTR: Q_BUF_PTR): FSTATUS; where: CID the local connect id. PTR the address of the message buffer. FSTATUS SUCCESS if the buffer has been queued, NOT_OPEN if the connection has been closed. 6.5.4 Receive Message Poll This function checks if a message has been received in a previously queued message buffer: function REC_MSG_POLL( CID: CONNECT_ID; var MLEN: APPL_MSG_LEN; var PTR: Q_BUF_PTR): FSTATUS; where: CID the local connect id. MLEN the length (in bytes) of the message. PTR the address of the message buffer. FSTATUS SUCCESS if a message has been received; FAIL otherwise. SYSAP-SCS INTERFACE Page 6-20 6.5.5 Cancel Receive Message This procedure requests return of a message buffer (and the associated flow control credit from the destination process): procedure CANCEL_REC_MSG( CID: CONNECT_ID); where: CID the local connect id. Cancellation does not occur if (1) the flow control credit has been used by the destination process to send a message or for a block data operation, or (2) the number of destination credits would drop below the SYSAP protocol threshold. 6.5.6 Cancel Receive Message Poll This function checks if a cancel operation has completed: function CANCEL_REC_MSG_POLL( CID: CONNECT_ID; var PTR: Q_BUF_PTR): FSTATUS; where: CID the local connect id. PTR the address of the message buffer. FSTATUS SUCCESS if a buffer is returned; NULL if the cancel cannot be completed; FAIL otherwise. CANCEL_REC_MSG_POLL must be called until every cancel has a matching SUCCESS or NULL FSTATUS. Null status indicates that the destination would not allow the buffer to be returned in order to keep the number of credits above threshold. SYSAP-SCS INTERFACE Page 6-21 6.6 BLOCK DATA SERVICE A name is associated with a named buffer by calling MAP. This name may be used locally or passed to the other side of a connection using one of the communications services. A name is disassociated from a buffer by calling UNMAP. By calling WRITE, data is transferred from the local side to the destination side. The completion of the transfer is checked by calling WRITE_POLL. Similarly, by calling READ, data is transferred from the destination side to the local side. The completion of the transfer is checked by calling READ_POLL. To initiate a block data transfer, the local side must hold a send credit. The send credit is used for the duration of the transfer, but is available again after completion of the transfer. | | In the following description, no provision is made for cancelling | block data transfers. An implementation must provide a cancel | function. Due to a restriction in the CI-780 port, it is not possible | to withdraw a block transfer that has started without shutting down | the port to port VC. This is not the intent of SCA and should be | viewed as an implementation restriction. 6.6.1 Map Buffer This function associates a name with a local named buffer: function MAP( {BLOCK_BUF: BUF_DESCR;} var NAME: LONG): FSTATUS; where: BLOCK_BUF a descriptor of a named buffer (implementation specific). NAME the name of buffer returned by MAP. FSTATUS SUCCESS if a name is associated; FAIL otherwise. The MAP function may have additional implementation specific parameters. An examples is a connect id that indicates that the connection block has additional information on how to map the buffer. This would be needed if there were multiple ports on the system with different named buffer mapping techniques. SYSAP-SCS INTERFACE Page 6-22 6.6.2 Unmap Buffer This procedure disassociates a name from a named buffer: procedure UNMAP( NAME: LONG); where: NAME the buffer name. 6.6.3 Read This function requests transfer of data from a destination named buffer to a local block data buffer: function READ( CID: CONNECT_ID; THRSH: WORD; PTR: Q_BUF_PTR; var XID: WORD): FSTATUS; where: CID the local connect id. THRSH the transfer is started only if at least this many send flow control credits will remain. The minimum value of THRSH is 0. PTR the address of the message buffer containing the block data arguments. XID the transaction id assigned by READ. FSTATUS SUCCESS if the transfer is queued, FAIL if no flow control credit is available, NOT_OPEN if the connection has been closed. The block data arguments include: DATA_LENGTH the number of bytes to be transferred. SEND_NAME the name of the buffer from which the data is read. SEND_OFFSET the starting byte in sending buffer. REC_NAME the name of the buffer to which the data is written. SYSAP-SCS INTERFACE Page 6-23 REC_OFFSET the starting byte in the receiving buffer. 6.6.4 Read Poll This function checks if a read transfer has completed: function READ_POLL( CID: CONNECT_ID; var PTR: Q_BUF_PTR; var XID: WORD): FSTATUS; where: CID local connect id. PTR the address of the message buffer returned by READ_POLL. XID the transaction id of the completed read. FSTATUS SUCCESS if a read has completed; FAIL otherwise. SYSAP-SCS INTERFACE Page 6-24 6.6.5 Write This function requests transfer of data from a local named buffer to a destination block data buffer: function WRITE( CID: CONNECT_ID; THRSH: WORD; PTR: Q_BUF_PTR; var XID: WORD): FSTATUS; where: CID the local connect id. THRSH the transfer is started only if this many send flow control credits will remain. The minimum value of THRSH is 0. PTR the address of the message buffer containing the block data arguments. XID the transaction id assigned by WRITE. FSTATUS SUCCESS if the transfer is queued, FAIL if no flow control credit is available, NOT_OPEN if the connection has been closed. The block data arguments include: DATA_LENGTH the number of bytes to be transferred. SEND_NAME the name of the buffer from which the data is read. SEND_OFFSET the starting byte in sending buffer. REC_NAME the name of the buffer to which the data is written. REC_OFFSET the starting byte in the receiving buffer. SYSAP-SCS INTERFACE Page 6-25 6.6.6 Write Poll This function checks if a write transfer has completed: function WRITE_POLL( CID: CONNECT_ID; var PTR: Q_BUF_PTR; var XID: WORD): FSTATUS; where: CID the local connect id. PTR the address of the message buffer returned by WRITE_POLL. XID the transaction id of the completed write. FSTATUS SUCCESS if a write has completed; FAIL otherwise. CHAPTER 7 SCS-PPD INTERFACE The PPD interface is modelled as a set of function and procedure calls of the same form as the SCS interface. The PPD interface is essentially the CI port architecture, and the function and procedure names (where appropriate) are the corresponding CI port command mnemonics. | | REQUEST ID REMOVED 7.1 DATAGRAM SERVICE 7.1.1 Send Datagram This procedure sends a datagram to a destination system: procedure SNDDG( DST: PB_INDEX; RET_FLAG: boolean; PTR: Q_BUF_PTR); where: DST the destination port path block address. RET_FLAG true if a DGSNT response is to be generated; false otherwise. PTR the address of the datagram buffer. SCS-PPD INTERFACE Page 7-2 7.1.2 Receive Datagram This procedure queues a datagram buffer to receive a datagram: procedure INSERT_DFREEQ( PTR: Q_BUF_PTR); where: PTR the address of the datagram buffer. 7.1.3 Return Datagram Buffer This function dequeues a datagram buffer: function REMOVE_DFREEQ( var PTR: Q_BUF_PTR): FSTATUS; where: PTR the address of the datagram buffer. FSTATUS SUCCESS if a buffer is dequeued; FAIL otherwise. SCS-PPD INTERFACE Page 7-3 7.2 VIRTUAL CIRCUIT SERVICE 7.2.1 Start Virtual Circuit This procedure requests the opening of a virtual circuit between the local and a destination system: procedure START_VC( DST: PB_INDEX; DATA: START_DATA; MPTR1: Q_BUF_PTR; MPTR2: Q_BUF_PTR; DPTR: Q_BUF_PTR); where: DST the path block corresponding to the destination port. DATA start data. See Appendix G. MPTR1 the address of a message buffer. MPTR2 the address of a message buffer. DPTR the address of a datagram buffer. | | Both message buffers, MPTR1 and MPTR2, are used to communicate between | SCS instances to establish and maintain connections. One is used to | send control messages and is immediately queued as a receive to | receive the response. One buffer is queued at all times as a receive | for commands from the other side and is queued as a transmit for the | response. After the response transmit it is queued as a receive for | the next incoming command. There is at most one outstanding SCS | command being processed by the other side and one being processed by | this side. | | The datagram message buffer, DPTR, is used to start the port to port | virtual circuit and is used for both transmit and receive. SCS-PPD INTERFACE Page 7-4 7.3 MESSAGE SERVICE 7.3.1 Send Message This procedure sends a message to a destination system: procedure SNDMSG( DST: PB_INDEX; RET_FLAG: boolean; PTR: Q_BUF_PTR); where: DST the destination port path block address. RET_FLAG true if a MSGSNT response is to be generated; false otherwise. PTR the address of the message buffer. SNDMSG requires an open virtual circuit to exist to DST. 7.3.2 Receive Message This procedure queues a message buffer to receive a message: procedure INSERT_MFREEQ( PTR: Q_BUF_PTR); where: PTR the address of the message buffer. 7.3.3 Return Message Buffer This function dequeues a message buffer: function REMOVE_MFREEQ( var PTR: Q_BUF_PTR): FSTATUS; where: PTR the address of the message buffer. FSTATUS SUCCESS if a buffer is dequeued; FAIL otherwise. SCS-PPD INTERFACE Page 7-5 7.4 BLOCK DATA SERVICE 7.4.1 Send Data This procedure sends data from a named buffer in the local system to a named buffer in the destination system: procedure SNDDAT( DST: PB_INDEX; PTR: Q_BUF_PTR); where: DST the destination port path block address. PTR the address of the message buffer containing the block data arguments. The block data arguments include: DATA_LENGTH the number of bytes to be transferred. SEND_NAME the name of the buffer from which the data is read. SEND_OFFSET the starting byte in sending buffer. REC_NAME the name of the buffer to which the data is written. REC_OFFSET the starting byte in the receiving buffer. SNDDAT requires a open virtual circuit to exist to DST. SCS-PPD INTERFACE Page 7-6 7.4.2 Request Data This procedure requests the sending of data from a named buffer in a destination system to a named buffer in the local system: procedure REQDAT( DST: PB_INDEX; PTR: Q_BUF_PTR); where: DST the destination port path block address. PTR the address of the message buffer containing the block data arguments. The block data arguments include: DATA_LENGTH the number of bytes to be transferred. SEND_NAME the name of the buffer from which the data is read. SEND_OFFSET the starting byte in sending buffer. REC_NAME the name of the buffer to which the data is written. REC_OFFSET the starting byte in the receiving buffer. REQDAT requires a open virtual circuit to exist to DST. SCS-PPD INTERFACE Page 7-7 7.5 RESPONSES This function checks if a message has been sent, a message has been received, a datagram has been sent, a datagram has been received, sent data has been confirmed, requested data has been received, or an id has been received. function RSP_POLL( var RSP: RSP_TYPE; var DST: PB_INDEX; var PTR: Q_BUF_PTR): FSTATUS; where: RSP the response type: (MSGSNT, DGSNT, MSGREC, DGREC, CNFREC, DATREC, IDREC, MCNFREC, MDATREC). DST the destination port path block address. PTR the address of a queued buffer returned by RSP_POLL. The buffer is a messsage buffer for MSGSNT, MSGREC, CNFREC, and DATREC and a datagram buffer otherwise. FSTATUS SUCCESS if a response is present; FAIL otherwise. CHAPTER 8 SCS MESSAGES AND DATAGRAMS 8.1 TYPES SCS messages and datagrams are of two basic types: control and application. Control messages carry information between peer SCS processes while application messages and datagrams carry information between peer SYSAP processes. Control messages are of two subtypes: request and response. A request message from SCS process X to SCS process Y is followed by a response message from SCS process Y to SCS process X that acknowledges the previous request and enables sending the next request. SCS MESSAGES AND DATAGRAMS Page 8-2 The general format of an SCS message or datagram is: 3 1 1 5 0 +---------------+---------------+ | CREDIT | SCS_TYPE | +---------------+---------------+ | REC_CONNECT_ID | +-------------------------------+ | SEND_CONNECT_ID | +-------------------------------+ | | = SCS_TYPE_SPECIFIC = | | +-------------------------------+ where: SCS_TYPE the message or datagram type. CREDIT the flow control credit. REC_CONNECT_ID the connect id of the process that is receiving the message or datagram or on whose behalf it is being received. SEND_CONNECT_ID the connect id of the process that is sending the messsage or datagram or on whose behalf it is being sent. SCS_TYPE_SPECIFIC depends on SCS_TYPE. SCS MESSAGES AND DATAGRAMS Page 8-3 8.2 SCS CONTROL MESSAGES 8.2.1 Connect Request The CONNECT_REQ request message requests a connection. The format of CONNECT_REQ is: 3 1 1 5 0 +---------------+---------------+ | CREDIT | SCS_TYPE | +---------------+---------------+ | 0 | +---------------+---------------+ | SEND_CONNECT_ID | +---------------+---------------+ | 0 | MIN_CREDIT | +---------------+---------------+ | | = REC_PROC = | | +-------------------------------+ | | = SEND_PROC = | | +-------------------------------+ | | = SEND_DATA = | | +-------------------------------+ where: SCS_TYPE CONNECT_REQ. CREDIT the initial number of flow control credits extended. CREDIT must be non-negative. SEND_CONNECT_ID the connect id of the process sending the connect request. MIN_CREDIT the minimum number of flow control credits needed. MIN_CREDIT must be non-negative. REC_PROC the name of the process to receive the request. SEND_PROC the name of the process sending the request. SEND_DATA connect data from the sending process. SCS MESSAGES AND DATAGRAMS Page 8-4 8.2.2 Connect Response The CONNECT_RSP response message acknowledges the CONNECT_REQ message and enables sending the next request message. The format of CONNECT_RSP is: 3 1 1 5 0 +---------------+---------------+ | 0 | SCS_TYPE | +---------------+---------------+ | REC_CONNECT_ID | +-------------------------------+ | SEND_CONNECT_ID | +---------------+---------------+ | STATUS | 0 | +---------------+---------------+ where: SCS_TYPE CONNECT_RSP. REC_CONNECT_ID the connect id of the process sending the connect request. SEND_CONNECT_ID the connect id of the process responding to the connect request. | | STATUS CONNECTED if the connect request was queued, | NO_MATCH or NO_RESOURCES otherwise. SCS MESSAGES AND DATAGRAMS Page 8-5 8.2.3 Accept Request The ACCEPT_REQ request message accepts a connection request. The format of ACCEPT_REQ is: 3 1 1 5 0 +---------------+---------------+ | CREDIT | SCS_TYPE | +---------------+---------------+ | REC_CONNECT_ID | +-------------------------------+ | SEND_CONNECT_ID | +---------------+---------------+ | 0 | MIN_CREDIT | +---------------+---------------+ | | = REC_PROC = | | +-------------------------------+ | | = SEND_PROC = | | +-------------------------------+ | | = SEND_DATA = | | +-------------------------------+ where: SCS_TYPE ACCEPT_REQ. CREDIT the initial number of credits extended. CREDIT must be non-negative. REC_CONNECT_ID the connect id of the process receiving the request. SEND_CONNECT_ID the connect id of the process sending the request. MIN_CREDIT the minimum number of flow control credits needed. MIN_CREDIT must be non-negative. REC_PROC the name of the process receiving the request. SEND_PROC the name of the process sending the request. SEND_DATA connect data from the sending process. SCS MESSAGES AND DATAGRAMS Page 8-6 8.2.4 Accept Response The ACCEPT_RSP response message acknowledges the ACCEPT_REQ message and enables sending the next request message. The format of ACCEPT_RSP response is: | | | 3 1 | 1 5 0 | +---------------+---------------+ | | 0 | SCS_TYPE | | +---------------+---------------+ | | REC_CONNECT_ID | | +-------------------------------+ | | SEND_CONNECT_ID | | +-------------------------------+ | | REASON | 0 | | +-------------------------------+ | where: SCS_TYPE ACCEPT_RSP. REC_CONNECT_ID same as SEND_CONNECT_ID in the ACCEPT_REQ message. SEND_CONNECT_ID same as REC_CONNECT_ID in the ACCEPT_REQ message. | REASON reason for failure to accept connection. | NO_RESOURCES and DISCONNECTED are possible. | CONNECTED means that the ACCEPT_REQ is being | processed. SCS MESSAGES AND DATAGRAMS Page 8-7 8.2.5 Reject Request The REJECT_REQ request message rejects a connection request. The format of REJECT_REQ is: | | | 3 1 | 1 5 0 | +---------------+---------------+ | | 0 | SCS_TYPE | | +---------------+---------------+ | | REC_CONNECT_ID | | +-------------------------------+ | | SEND_CONNECT_ID | | +---------------+---------------+ | | REASON | 0 | | +---------------+---------------+ | | where: SCS_TYPE REJECT_REQ. REC_CONNECT_ID the connect id of process receiving the request. SEND_CONNECT_ID the connect id of the process sending the request. | | REASON the reason for rejection. See Appendix E. SCS MESSAGES AND DATAGRAMS Page 8-8 8.2.6 Reject Response The REJECT_RSP response message acknowledges the REJECT_REQ message and enables sending the next request message. The format of REJECT_RSP is: 3 1 1 5 0 +---------------+---------------+ | 0 | SCS_TYPE | +---------------+---------------+ | REC_CONNECT_ID | +-------------------------------+ | SEND_CONNECT_ID | +-------------------------------+ where: SCS_TYPE REJECT_RSP. REC_CONNECT_ID same as SEND_CONNECT_ID in the REJECT_REQ message. SEND_CONNECT_ID same as REC_CONNECT_ID in the REJECT_REQ message. SCS MESSAGES AND DATAGRAMS Page 8-9 8.2.7 Disconnect Request The DISCONNECT_REQ request message requests disconnection. The format of DISCONNECT_REQ is: | | | 3 1 | 1 5 0 | +---------------+---------------+ | | 0 | SCS_TYPE | | +---------------+---------------+ | | REC_CONNECT_ID | | +-------------------------------+ | | SEND_CONNECT_ID | | +---------------+---------------+ | | REASON | 0 | | +---------------+---------------+ | | where: SCS_TYPE DISCONNECT_REQ. REC_CONNECT_ID the connect id of the process receiving the request. SEND_CONNECT_ID the connect id of the process sending the request. | | REASON the reason for disconnection. See Appendix E. SCS MESSAGES AND DATAGRAMS Page 8-10 8.2.8 Disconnect Response The DISCONNECT_RSP response message acknowledges the DISCONNECT_REQ message and enables sending the next request message. The format of DISCONNECT_RSP is: 3 1 1 5 0 +---------------+---------------+ | 0 | SCS_TYPE | +---------------+---------------+ | REC_CONNECT_ID | +-------------------------------+ | SEND_CONNECT_ID | +-------------------------------+ where: SCS_TYPE DISCONNECT_RSP. REC_CONNECT_ID same as SEND_CONNECT_ID in the DISCONNECT_REQ message. SEND_CONNECT_ID same as REC_CONNECT_ID in the DISCONNECT_REQ message. SCS MESSAGES AND DATAGRAMS Page 8-11 8.2.9 Credit Request The CREDIT_REQ request message carries credits for flow control. The format of CREDIT_REQ is: 3 1 1 5 0 +---------------+---------------+ | CREDIT | SCS_TYPE | +---------------+---------------+ | REC_CONNECT_ID | +-------------------------------+ | SEND_CONNECT_ID | +-------------------------------+ where: SCS_TYPE CREDIT_REQ. CREDIT a signed integer giving, if non-negative, the number of additional credits extended; if negative, the number of credits requested to be returned. REC_CONNECT_ID the connect id of the process receiving the credits. SEND_CONNECT_ID the connect id of the process sending the credits. SCS MESSAGES AND DATAGRAMS Page 8-12 8.2.10 Credit Response The CREDIT_RSP response message acknowledges the CREDIT_REQ message and enables sending of the next request message. The format of CREDIT_RSP is: 3 1 1 5 0 +---------------+---------------+ | CREDIT | SCS_TYPE | +---------------+---------------+ | REC_CONNECT_ID | +-------------------------------+ | SEND_CONNECT_ID | +-------------------------------+ where: SCS_TYPE CREDIT_RSP. CREDIT if the CREDIT field in the CREDIT_REQ message was non-negative, then the value of CREDIT; otherwise the negative of the number of credits actually returned. REC_CONNECT_ID same as SEND_CONNECT_ID in the CREDIT_REQ message. SEND_CONNECT_ID same as REC_CONNECT_ID in the CREDIT_REQ message. SCS MESSAGES AND DATAGRAMS Page 8-13 8.3 APPLICATION MESSAGE The APPL_MSG application message carries a SYSAP layer message. The format of APPL_MSG is: 3 1 1 5 0 +---------------+---------------+ | CREDIT | SCS_TYPE | +---------------+---------------+ | REC_CONNECT_ID | +-------------------------------+ | SEND_CONNECT_ID | +-------------------------------+ | | = SYSAP_MSG_TEXT = | | +-------------------------------+ where: SCS_TYPE APPL_MSG. CREDIT the number of flow control credits being extended. CREDIT must be non-negative. REC_CONNECT_ID the connect id of the process receiving the message. SEND_CONNECT_ID the connect id of the process sending the message. SYSAP_MSG_TEXT the SYSAP layer message text. SCS MESSAGES AND DATAGRAMS Page 8-14 8.4 APPLICATION DATAGRAM The APPL_DG datagram carries a SYSAP layer datagram. The format of APPL_DG is: 3 1 1 5 0 +---------------+---------------+ | 0 | SCS_TYPE | +---------------+---------------+ | REC_CONNECT_ID | +-------------------------------+ | SEND_CONNECT_ID | +-------------------------------+ | | = SYSAP_DG_TEXT = | | +-------------------------------+ where: SCS_TYPE APPL_DG. REC_CONNECT_ID the connect id of the process receiving the datagram. SEND_CONNECT_ID the connect id of the process sending the datagram. SYSAP_DG_TEXT the SYSAP layer datagram text. CHAPTER 9 SCS OPERATION 9.1 RELATION TO PPD VIRTUAL CIRCUIT All SCS messages flow over a port-to-port virtual circuit provided by the PPD layer. All SYSAP-SCS connections are multiplexed on this virtual circuit. Closing the PPD virtual circuit by either system requires closing all SCS connections. The SYSAPs are notified of connection close by calling the STATE_POLL function. | | | | 9.2 SCS PROTOCOL VERSION RESOLUTION | | The start data contains a protocol version number. This allows SCA | version upgrade in the future. The first version of SCA is version | zero. | | The version field is compared in such a way to allow newer versions to | be written to talk down to older versions as well as to their | contemporary versions. This is done by leaving the decision of making | the start_vc to the higher numbered version. The lower number version | always accepts starts from the same or higher versions. Higher number | versions always accept equal version starts and may as well accept | starts from lower numbered versions if the higher version is willing | to talk down to the older version. Talking down is an implementation | decision. Accepting connects from higher versions is required. 9.3 SCS CONTROL MESSAGE FLOW CONTROL When a port-to-port virtual circuit is opened, each system supplies 2 message buffers. The first, termed the local message buffer, is used to send SCS control request messages and receive the associated response control message. This buffer is initially queued on the path block, dequeued to send a request message, and requeued after the response is received. The second, termed the destination message buffer, is used to receive SCS control request messages and send the associated response control message. This buffer is initially queued on the PPD MFREEQ, dequeued when a SCS control request is received, and requeued after the response is sent. At most 1 request message on SCS OPERATION Page 9-2 each direction of the virtual circuit can be outstanding at a time. Only when the destination of the request responds with a response message can another request message be sent. | | These are some descriptions of the credit variables used in the SCS | operation description which will help to understand credit management. | | THRSH this value is the name of a call parameter which | corresponds to MIN_SEND_CREDIT. When a connection | is established, this parameter becomes | MIN_SEND_CREDIT. In other calls when a circuit is | running, it is compared to SEND_CREDIT and | SEND_CREDIT must be at least this value to | succeed. | | SEND_CREDIT credits extended to this side by partner for | transmit buffers. Or the number of receives | queued by the partner. | | MIN_SEND_CREDIT minimum number of credits a SYSAP expects to have | to transmit to the other side. In other words, a | SYSAP expects to have this many buffers queued as | receives by its partner. This is a constant for | each connection and is established by the partner | SYSAP. | | REC_CREDITS credits this side has extended to the other side | to transmit. The number of receives queued here. | | MIN_REC_CREDIT minimum number of credits the other side expects | to have to transmit. Or the minimum number of | receives we will keep queued here. This is a | constant for each connection and is established by | the SYSAP on this side. | | PEND_REC_CREDIT accumulated number of credits that have been | queued as receives here but have not been sent to | the partner in a credit message. | | REQ_CREDIT the number of credits sent in the last CREDIT_REQ | message. This cell is used for the duration of | the credit_req, _rsp pair to enable the correct | setting of RET_NULL. | | RET_CREDIT number of credits actually obtained from the | partner or deducted on this side from | PEND_REC_CREDIT by cancel credit calls. This is | the count of buffers that can be returned to the | SYSAP caller requesting to cancel receives. | | RET_NULL the number of cancel credit requests for which no | buffer is available because they have not been | returned in a credit_rsp message from the other | side. SCS OPERATION Page 9-3 9.4 SCS OPERATION DESCRIPTION The SCS process is described as expansions of the SCS interface calls and as 2 subprocesses, SCS_SEND and SCS_REC. SCS_SEND sends SCS control request messages. An SCS interface call needing the SCS request message service queues the appropriate connection block on the appropriate path block. The path block, if not already queued, is placed on the SCS_SEND_Q work queue. SCS_SEND removes the path block from the work queue and sends a request message (using the local message buffer). The following shows the relationship of the data structures used by SCS_SEND: +-------+ | |-----> next system |system | block | block | | | +-------+ ^ | | V +-------+ +-------+ +-------+ +-------+ <-------| |<------| |<------| |------>| | |connect| |connect| | path | | local | | block | | block | | block | |msg buf| | | | | | | | | +-------+ +-------+ +-------+ +-------+ | | | V next path block SCS OPERATION Page 9-4 SCS_REC receives all incoming messages and datagrams and does the following: 1. Processes and delivers SYSAP messages and datagrams; DATREC; MDATREC; DATCNF; and MDATCNF responses. 2. Processes SCS request control messages and sends the appropriate response. 3. Processes SCS response control messages, queues the local message buffer on the path block, and if the CB_Q in the path block is non-empty, queues the path block on the SCS_SEND_Q work queue. 4. Delivers IDREC responses. If the IDREC is from a 'new' system, calls START_VC to start the PPD virtual circuit. The focal points of SCS operation are the path and connection blocks that are modified by the SCS interface calls, SCS_SEND, and SCS_REC. It is assumed that modifications to a path and connection block are synchronized by some standard technique: e.g. all the modifications are done at the same IPL. SCS OPERATION Page 9-5 9.5 TYPE, VARIABLE , FUNCTION, AND PROCEDURE DEFINITIONS The following PASCAL definitions apply to the SCS operation description. type SB = record { system block definition } SB$NEXT_SB: SB_PTR; { address of next SB } SB$FIRST_PB: PB_INDEX; { array index of first path block } SB$DST_PORT_COUNT: WORD; { number of interconnects to dst } SB$DST_SYS: SYSTEM; { destination system address } SB$DST_MAX_DG: WORD; { max. datagram size allowed } SB$DST_MAX_MSG: WORD; { max. message size allowed } SB$DST_SW_TYPE: LONG; { software type } SB$DST_SW_VERSION: LONG; { software version } SB$DST_SW_INCAR: QUAD; { software incarnation number } SB$DST_HW_TYPE: LONG; { hardware type } SB$DST_HW_VERSION: SEPTA; { hardware version } SB$DST_NODE_NAME: QUAD { ASCII node name } end; PB = record { path block definition } PB$NEXT_PB: PB_INDEX; { index of next path block to system } PB$SB: SB_INDEX; { index of system block for this PB } PB$DST_VC_STATE: VC_STATE; { state of port-to-port virtual circuit } PB$DST_PORT: PORT; { destination port address } PB$DG_Q: Q_BUF_PTR; { datagram return queue } PB$MSG_PTR: Q_BUF_PTR; { scs control message pointer } PB$CB_Q: CB_PTR; { queue of CBs requiring SCS service } PB$DST_PORT_CHAR: PORT_CHAR { characteristics of remote port } end; B_STATE = ( { Connection block state for CB$BLOCK_STATE. This field is used as an opcode to SCS_SEND, which examines it to determine what type of control message to send. } FREE, { connection block is unused } ALLOC, { connection block is allocated } CONNECT_PEND, { send a connect message } ACCEPT_PEND, { send an accept message } REJECT_PEND, { send a reject message } CREDIT_PEND, { send a credit message } DISCONNECT_PEND { send a disconnect message } ); CB = record { connection block } CB$NEXT_CB: CB_PTR; { address of next CB in queue } CB$CONNECT_STATE: C_STATE; { state of process-to-process connection } CB$BLOCK_STATE: B_STATE; { state of this connection block } CB$SRC_CONNECT_ID: CONNECT_ID; { id of local connection block } CB$DST_CONNECT_ID: CONNECT_ID; { id of remote connection block } CB$SRC_PROC_NAME: PROC_NAME; { local process name } CB$DST_PROC_NAME: PROC_NAME; { remote process name } SCS OPERATION Page 9-6 CB$CONNECT_DATA: C_DATA; { connection data } CB$SRC_REASON: WORD; { local reason for reject or disconnect } CB$DST_REASON: WORD; { remote reason for reject or disconnect } CB$SEND_CREDIT: WORD; { number of available send credits } CB$MIN_SEND_CREDIT: WORD; { protocol threshold } CB$REC_CREDIT: WORD; { max. unused credits held by remote side } CB$MIN_REC_CREDIT: WORD; { min. send credits needed by remote side } CB$PEND_REC_CREDIT: WORD; { receive buffers queued, or cancels pending } CB$REQ_CREDIT: WORD; { credits sent but not acknowledged } CB$RET_CREDIT: WORD; { credits actually returned from remote side } CB$RET_NULL: WORD; { credits requested but not returned from remote side } CB$DG_REC: WORD; { number of datagram buffers queued } CB$RESERVED: WORD; { unused } CB$DST_SB: SB_INDEX; { system block for destination system } CB$DST_PB: PB_INDEX; { path block for interconnect to destination } CB$DG_Q: Q_BUF_PTR; { queue of DGREC responses } CB$MSG_Q: Q_BUF_PTR; { queue of MSGREC responses } CB$READ_Q: Q_BUF_PTR; { queue of DATREC responses } CB$WRITE_Q: Q_BUF_PTR; { queue of CNFREC responses } CB$DG_RET_Q: Q_BUF_PTR; { queue of DGSNT responses } CB$MSG_RET_Q: Q_BUF_PTR { queue of MSGSNT responses } end; CB_Q_STATE = (FILLED,WAS_EMPTY,NOW_EMPTY); { connection block queue state } RSP_TYPE = (DGREC,DGSNT,MSGREC,MSGSNT,DATREC,CNFREC, IDREC,MDATREC,MCNFREC); { PPD response type } START_DATA = packed array [1..36] of BYTE; var CBA: array [1..MAX_CB] of CB; { connection blocks } SBA: array [1..MAX_SB] of SB; { system blocks } PBA: array [1..MAX_PB] of PB; { path blocks } CUR_SB: WORD; { the highest current system list entry } CUR_PB: WORD; { the highest current path list entry } SCS_SEND_Q: SB_PTR; { SCS_SEND work queue } function ALLOC_CB( var CID:CONNECT_ID): boolean; begin { allocate connect block, initialize to zero, set CB$NEXT_CB to point to itself, set CB$BLOCK_STATE to ALLOC, and return CID: return true if block allocated; false otherwise } end;{ALLOC_CB} SCS OPERATION Page 9-7 function CB_CLOSED( { test connection state } CID: CONNECT_ID): boolean; begin {return TRUE if connection is closed, return FALSE otherwise } end;{CB_CLOSED} procedure CHOOSE_PATH( { select path to system } ENTRY: SB_INDEX; var PATH: PB_INDEX); begin { select path over which connection to specified system is to be attempted. } end;{CHOOSE_PATH} function PBPTR_TO_PBINDEX( { change pointer to index } PTR: PB_PTR): PB_INDEX; begin { calculate index from address pointer } end;{PBPTR_TO_PBINDEX} function NEXT_XID: WORD; begin { assign a new transaction number } end;{NEXT_XID} function CONNECT_MATCH( PTR: Q_BUF_PTR; var CNCT_INDEX: WORD): boolean; begin { search for connect block in LISTENING connect state which matches the connect request: set CB$DST_SB, CB$DST_PB } end;{CONNECT_MATCH} function INSERT_CB_Q( Q: CB_PTR; SCS OPERATION Page 9-8 PTR: CB_PTR): CB_Q_STATE; begin { insert entry whose address is PTR in queue Q: return WAS_EMPTY if queue was previously empty; FILLED otherwise } end; function REMOVE_CB_Q( Q: CB_PTR; var PTR: CB_PTR): CB_Q_STATE; begin { remove entry from queue Q and return address in PTR : return NOW_EMPTY if queue is now empty; FILLED otherwise } end; procedure INSERT_SCS_Q( INDEX: PB_INDEX); begin { insert path block identified by INDEX on the SCS_SEND_Q work queue } end;{INSERT_SCS_Q} function REMOVE_SCS_Q( var PTR: PB_PTR): boolean; begin { remove an entry from the SCS_SEND_Q work queue and return its address in PTR: return true if entry removed; false otherwise } end;{REMOVE_SCS_Q} procedure INSERT( Q: Q_BUF_PTR; PTR: Q_BUF_PTR); begin { insert entry whose address is PTR in queue Q } end;{INSERT} SCS OPERATION Page 9-9 function REMOVE( Q: Q_BUF_PTR; var PTR: Q_BUF_PTR): boolean; begin { remove entry from queue Q and return address of entry in PTR: return true if entry removed; false otherwise } end;{REMOVE} {SCSDEF} SCS OPERATION Page 9-10 9.6 CONFIGURATION SERVICE 9.6.1 System Block The system list is a data structure built and maintained by the PPD layer and used by the SCS layer. An entry on the system list is termed a system block. A representative system block has the following format: 3 1 0 +-------------------------------+ | NEXT_SB | +---------------+---------------+ |DST_PORT_COUNT |FIRST_PB_INDEX | +-------------------------------+ | | RESERVED | | +---------------+ | DST_SYS | +---------------+---------------+ | DST_MAX_MSG | DST_MAX_DG | +---------------+---------------+ | DST_SW_TYPE | +-------------------------------+ | DST_SW_VERSION | +-------------------------------+ | DST_SW_INCARNATION | | | +-------------------------------+ | DST_HW_TYPE | +-------------------------------+ | | = DST_HW_VERSION = | | +-------------------------------+ | NODE_NAME | | | +-------------------------------+ where: NEXT_SB the address of the next system block on the the SCS_SEND_Q. FIRST_PB_INDEX path block index of the first path block for this system. DST_PORT_COUNT number of paths to the destination system. RESERVED reserved word. DST_SYS the destination system. SCS OPERATION Page 9-11 DST_MAX_DG the maximum datagram size (in bytes) supported by the system. DST_MAX_MSG the maximum message size (in bytes) supported by the system. DST_SW_TYPE the 4-character ASCII type of the software in the system. DST_SW_VERSION the 4-character ASCII version number of the software in the system. DST_SW_INCARNATION (8 bytes) the incarnation number of the software in the system. DST_HW_TYPE the type of system hardware. | | DST_HW_VERSION (12 bytes) the version number of the system | hardware. NODE_NAME (8 bytes) the ASCII node name of the system. SCS OPERATION Page 9-12 9.6.2 Path Block The path block is a data structure containing information about a single system-to-system path. That is, it describes one of potentially several ports to a destination system. 3 1 0 +-------------------------------+ | SB | NEXT_PB | +-------------------------------+ | | DST_VC_STATE | | +---------------| | DST_PORT | +-------------------------------+ | DG_Q | +-------------------------------+ | MSG_PTR | +-------------------------------+ | CB_Q | +---------------+---------------+ | | = DST_PORT_CHAR = | | +-------------------------------+ NEXT_PB path block index of the next path to the destination system. SB system block index of the system block to which this path block is queued. DST_VC_STATE the state of the virtual circuit to the destination port. DST_PORT the destination system port address. DG_Q the datagram return queue for maintenance operations. MSG_PTR the address of the local message buffer associated with the port-to-port virtual circuit. CB_Q the queue of connection blocks of connections requiring SCS control message service. DST_PORT_CHAR the characteristics of the destination port. SCS OPERATION Page 9-13 9.6.3 Configuration Services | REQ_ID REMOVED function CONFIG_SYS( ENTRY: SB_INDEX; var FIRST_PB: PB_INDEX; var SYS: SYSTEM; var MAX_DG: WORD; var MAX_MSG: WORD; var SW_TYPE: LONG; var SW_VERSION: LONG; var SW_INCARNATION: QUAD; var HW_TYPE: LONG; var HW_VERSION: SEPTA; var NODE_NAME: QUAD; var PORT_COUNT: WORD): FSTATUS; { Return information about destination SYSTEM from the specified System Block. } begin if ENTRY <= CUR_SB then with SBA[ENTRY] do begin FIRST_PB:=SB$FIRST_PB; SYS:=SB$DST_SYS; MAX_DG:=SB$DST_MAX_DG; MAX_MSG:=SB$DST_MAX_MSG; SW_TYPE:=SB$DST_SW_TYPE; SW_VERSION:=SB$DST_SW_VERSION; SW_INCARNATION:=SB$DST_SW_INCAR; HW_TYPE:=SB$DST_HW_TYPE; HW_VERSION:=SB$DST_HW_VERSION; NODE_NAME:=SB$DST_NODE_NAME; PORT_COUNT:=SB$DST_PORT_COUNT; CONFIG_SYS:=SUCCESS end else CONFIG_SYS:=FAIL end;{CONFIG_SYS} function CONFIG_PATH( ENTRY: PB_INDEX; var STATE: VC_STATE; var PRT: PORT; var NEXT_PB: PB_INDEX; var SB: SB_INDEX; var CHAR: PORT_CHAR): FSTATUS; { Return information about the specified INTERCONNECT from the specified Path Block. } SCS OPERATION Page 9-14 begin if ENTRY <= CUR_PB then with PBA[ENTRY] do begin STATE:=PB$DST_VC_STATE; PRT:=PB$DST_PORT; NEXT_PB:=PB$NEXT_PB; SB:=PB$SB; CHAR:=PB$DST_PORT_CHAR; CONFIG_PATH:=SUCCESS end else CONFIG_PATH:=FAIL end;{CONFIG_PATH} SCS OPERATION Page 9-15 9.7 CONNECTION MANAGEMENT SERVICE 9.7.1 Connection Block A representative connection block has the following format: SCS OPERATION Page 9-16 3 1 0 +-------------------------------+ | NEXT_CB | +---------------+---------------+ | BLOCK_STATE | CONNECT_STATE | +---------------+---------------+ | SRC_CONNECT_ID | +-------------------------------+ | DST_CONNECT_ID | +-------------------------------+ | | = SRC_PROC_NAME = | | +-------------------------------+ | | = DST_PROC_NAME = | | +-------------------------------+ | | = CONNECT-DATA = | | +---------------+---------------+ | DST_REASON | SRC_REASON | +---------------+---------------+ |MIN_SEND_CREDIT| SEND_CREDIT | +---------------+---------------+ |MIN_REC_CREDIT | REC_CREDIT | +---------------+---------------+ | REQ_CREDIT |PEND_REC_CREDIT| +---------------+---------------+ | RET_NULL | RET_CREDIT | +---------------+---------------+ | RESERVED | DG_REC | +---------------+---------------+ | DST_PB | DST_SB | +---------------+---------------+ | DG_Q | +-------------------------------+ | MSG_Q | +-------------------------------+ | READ_Q | +-------------------------------+ | WRITE_Q | +-------------------------------+ | DG_RET_Q | +-------------------------------+ | MSG_RET_Q | +-------------------------------+ SCS OPERATION Page 9-17 where: NEXT_CB the address of the next connection block on the SCS send queue. CONNECT_STATE the connection state. BLOCK_STATE the state of the connection block. SRC_CONNECT_ID the connect id of the local connection block. DST_CONNECT_ID the connect id of destination connection block. SRC_PROC_NAME the process name of local process allocating the connection block. DST_PROC_NAME the process name of destination process. CONNECT_DATA connection data. SRC_REASON the local reject or disconnect reason. DST_REASON the destination reject or disconnect reason. SEND_CREDIT the number of available credits to send. MIN_SEND_CREDIT the SYSAP protocol threshold. REC_CREDIT the upper bound of the number of unused send credits held by the destination SYSAP process. MIN_REC_CREDIT the minimum number of send credits needed by the destination SYSAP process. PEND_REC_CREDIT if non-negative, the number of buffers queued to receive messages, but not yet credited to the destination process; otherwise the negative of the number of cancels not yet sent to the destination process. REQ_CREDIT the number of credits sent to the destination process in a CREDIT_REQ, but not yet responded to by a CREDIT_RSP. RET_CREDIT the number of credits returned by the destination as specified in the CREDIT_RSP. RET_NULL the number of credits requested to be returned in a CREDIT message but not returned in the CREDIT_RSP. DG_REC the number datagram buffers queued to receive datagrams. SCS OPERATION Page 9-18 RESERVED reserved word. DST_SB system block corresponding to the destination system. DST_PB path block on which this connection is established. DG_Q the queue of DGREC responses. MSG_Q the queue of MSGREC responses. READ_Q the queue of DATREC responses. WRITE_Q the queue of CNFREC responses. DG_RET_Q the queue of DGSNT responses. MSG_RET_Q the queue of MSGSNT response. SCS OPERATION Page 9-19 9.7.2 Connection States | A connection exists in 1 of several states: CLOSED, LISTEN, | CONNECT_SENT, CONNECT_ACK, CONNECT_REC, ACCEPT_SENT, REJECT_SENT, | OPEN, DISCONNECT_SENT, DISCONNECT_REC, DISCONNECT_ACK, and DISCONNECT | MATCH. Events cause transitions between states. An event is either a | connection management function call or receipt of a connection | management control message. | | The connection state table follows: | | Current Event Action New | State State | | CLOSED LISTEN call - LISTENING | CONNECT call send CONNECT_REQ CONNECT_SENT | *rcv CONNECT_REQ send CONNECT_RSP CLOSED | with NO_MATCH | *rcv ACCEPT_REQ send ACCEPT_RSP CLOSED | with NO_MATCH | DISCONNECT call nop CLOSED | | LISTENING rcv CONNECT_REQ send CONNECT_RSP CONNECT_REC | | DISCONNECT call cancel listen CLOSED | | CONNECT_SENT rcv CONNECT_RSP | with SUCCESS await ACCEPT or CONNECT_ACK | REJECT | with NO_MATCH - CLOSED | with NO_RESOURCES - CLOSED | | DISCONNECT call return success on CLOSED | DISCONNECT, abort on | CONNECT | | CONNECT_ACK rcv REJECT_REQ send REJECT_RSP CLOSED | rcv ACCEPT_REQ send ACCEPT_RSP OPEN | DISCONNECT call - CLOSED | | CONNECT_REC ACCEPT call send ACCPET_REQ ACCEPT_SENT | REJECT call send REJECT_REQ REJECT_SENT | DISCONNECT call send REJECT_REQ REJECT_SENT | | ACCEPT_SENT rcv ACCEPT_RSP | with SUCCESS - OPEN | with DISCONNECTED - CLOSED | | DISCONNECT call SUCCESS on DISCONNECT CLOSED | | ABORT on ACCEPT | | REJECT_SENT rcv REJECT_RSP - CLOSED | | DISCONNECT call SUCCESS on DISCONNECT CLOSED SCS OPERATION Page 9-20 | SUCCESS on REJECT | | OPEN DISCONNECT call send DISCONNECT_REQ DISCONNECT_SENT | rcv DISCONNECT_REQ send DISCONNECT_RSP DISCONNECT_REC | | DISCONNECT_SENT rcv DISCONNECT_REQ send DISCONNECT_RSP DISCONNECT_MATCH | rcv DISCONNECT_RSP - DISCONNECT_ACK | | DISCONNECT call SUCCESS on both CLOSED | DISCONNECTs | | DISCONNECT_REC DISCONNECT call Send DISCONNECT_REQ DISCONNECT_MATCH | | DISCONNECT_ACK rcv DISCONNECT_REQ send DISCONNECT_RSP CLOSED | | DISCONNECT call SUCCESS on both CLOSED | DISCONNECTs | | | DISCONNECT_MATCH | rcv DISCONNECT_RSP - CLOSED | | DISCONNECT call SUCCESS on both CLOSED | DISCONNECTs | | | | any non-CLOSED close port/port VC - CLOSED | | any state any inappropriate close port/port VC CLOSED | event | The reason that ACCEPT/REJECT are separated from CONNECT_RSP is to allow a system to initiate a potentially time consuming operation (e.g. process creation) in response to an incoming CONNECT_REQ. DISCONNECT_ACK and DISCONNECT_MATCH states are used to ensure that (1) both sides wait until the passive SYSAP issues a DISCONNECT request, and (2) both sides have acknowledged that they know the second DISCONNECT was issued. At that point, no further transfer requests can be issued by either side. To ensure that all messages in transit when the DISCONNECT was issed have completed before the connection is closed, all disconnect messages should be sent at lowest priority on ports that implement multiple priority messages. SCS OPERATION Page 9-21 9.7.3 Connect | function CONNECT( | var CID: CONNECT_ID; | SRC_PROC: PROC_NAME; | DST_PROC: PROC_NAME; | DST: SB_INDEX; | THRSH: WORD; | { [CREDITS: Q_BUF_PTR];... } | DATA: C_DATA | { [PATH: PB_INDEX] } | ): | FSTATUS; | | begin | | { Allocate a connection block, fill in appropriate fields, and place | on SCS work queue for processing. } | | if ALLOC_CB(CID) then with CBA[CID.INDEX] do | begin | CB$CONNECT_STATE:=CLOSED; | CB$BLOCK_STATE:=CONNECT_PEND; | CB$SRC_CONNECT_ID:=CID; | CB$SRC_PROC_NAME:=SRC_PROC; | CB$DST_PROC_NAME:=DST_PROC; | CB$CONNECT_DATA:=DATA; | CB$MIN_SEND_CREDIT:=THRSH; | { CB$PEND_REC_CREDIT:= count of CREDITS; | queue buffers with INSERT_MFREEQ } | CB$DST_SB:=DST; | | { Select a path to destination and store path block index | in CB. Insert CB on connection queue in chosen path block. | If queue is currently empty, then place the PB on | the SCS work queue for processing. } | | CHOOSE_PATH(DST,CB$DST_PB); | if INSERT_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB) = WAS_EMPTY | then INSERT_SCS_Q(CB$DST_PB); | CONNECT:=SUCCESS | end | else CONNECT:=FAIL | end;{CONNECT} SCS OPERATION Page 9-22 9.7.4 Listen | function LISTEN( | var CID: CONNECT_ID; | SRC_PROC: PROC_NAME; | DST_PROC: PROC_NAME; | DST: SB_INDEX ): | FSTATUS; | | { Allocate a connection block and initialize fields to | indicate waiting for matching connection request. } | | begin | if ALLOC_CB(CID) then with CBA[CID.INDEX] do | begin | CB$CONNECT_STATE:=LISTENING; | CB$SRC_CONNECT_ID:=CID; | CB$SRC_PROC_NAME:=SRC_PROC; | CB$DST_PROC_NAME:=DST_PROC; | CB$DST_SB:=DST; | LISTEN:=SUCCESS | end | else LISTEN:=FAIL | end{LISTEN}; 9.7.5 Accept | procedure ACCEPT( | CID: CONNECT_ID; | { [CREDITS: Q_BUF_PTR];...} | THRSH : WORD; | DATA: C_DATA); | | { Accept a connection request. Set CB$BLOCK_STATE for SCS_SEND | process and insert PB on work queue. Queue some message buffers | so credits can be extended.} | | begin with CBA[CID.INDEX] do | begin | CB$BLOCK_STATE:=ACCEPT_PEND; | CB$CONNECT_DATA:=DATA; | { CB$PEND_REC_CREDIT:= count of CREDITS; | queue buffers with INSERT_MFREEQ } | CB$MIN_SEND_CREDIT:=THRSH; | if INSERT_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB) = WAS_EMPTY | then INSERT_SCS_Q(CB$DST_PB); | end | end;{ACCEPT} SCS OPERATION Page 9-23 9.7.6 Reject procedure REJECT( CID: CONNECT_ID; REASON: WORD); { Reject a connection request. Set CB$BLOCK_STATE for SCS_SEND process, note reason for rejection, and queue PB for processing. } begin with CBA[CID.INDEX] do begin CB$BLOCK_STATE:=REJECT_PEND; CB$SRC_REASON:=REASON; if INSERT_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB) = WAS_EMPTY then INSERT_SCS_Q(CB$DST_PB); end end;{REJECT} 9.7.7 Disconnect procedure DISCONNECT( CID: CONNECT_ID; REASON: WORD); { Disconnect the connection. First, check to see if the connection is in operation. If so, transmit the DISCONNECT_REQ message and move to DISCONNECT_SENT state. Otherwise, disconnection has already begun due to remote disconnect request. Move to DISCONNECT_MATCH state and send DISCONNECT_REQ message to notify the other side that local SYSAP has disconnected. Set connection state, set block state for SCS_SEND, and insert PB if needed for sending. } begin with CBA[CID.INDEX] do begin case CB$CONNECT_STATE of OPEN: begin CB$CONNECT_STATE := DISCONNECT_SENT; CB$BLOCK_STATE := DISCONNECT_PEND end; DISCONNECT_REC: begin CB$CONNECT_STATE := DISCONNECT_MATCH; CB$BLOCK_STATE := DISCONNECT_PEND end; CONNECT_REC: begin SCS OPERATION Page 9-24 CB$CONNECT_STATE := REJECT_SENT; CB$BLOCK_STATE := REJECT_PEND end; OTHERWISE begin CB$CONNECT_STATE := CLOSED; CB$BLOCK_STATE := FREE end; end; CB$SRC_REASON:=REASON; if INSERT_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB) = WAS_EMPTY then INSERT_SCS_Q(CB$DST_PB) end; end;{DISCONNECT} 9.7.8 State Poll procedure STATE_POLL( CID: CONNECT_ID; var STATE: C_STATE; var DST_CID: CONNECT_ID; var DST_PROC: PROC_NAME; var DST_SB: SB_INDEX; var DST_PB: PB_INDEX; var DATA: C_DATA; var REASON: WORD); { Return the state of a process-to-process connection} begin with CBA[CID.INDEX] do begin STATE:=CB$CONNECT_STATE; DST_CID:=CB$DST_CONNECT_ID; DST_PROC:=CB$DST_PROC_NAME; DST_SB:=CB$DST_SB; DST_PB:=CB$DST_PB; DATA:=CB$CONNECT_DATA; REASON:=CB$DST_REASON end end;{STATE_POLL} SCS OPERATION Page 9-25 9.8 DATAGRAM SERVICE 9.8.1 Send Datagram function SEND_DG( CID: CONNECT_ID; RET_FLAG: boolean; DLEN: APPL_DG_LEN; PTR: Q_BUF_PTR): FSTATUS; { Check to see that connection is still open. Fill in SCS header information and call PPD send datagram. } begin with CBA[CID.INDEX] do if CB_CLOSED(CID) then SEND_DG:=NOT_OPEN else begin if not RET_FLAG then CB$DG_REC:=CB$DG_REC+1; PTR^.LENGTH:=DLEN+AP_DG_HDR_LEN; PTR^.SCS_TYPE:=APPL_DG; PTR^.CREDIT:=0; PTR^.REC_CONNECT_ID:=CB$DST_CONNECT_ID; PTR^.SEND_CONNECT_ID:=CB$SRC_CONNECT_ID; SNDDG(CB$DST_PB,RET_FLAG,PTR); SEND_DG:=SUCCESS end end;{SEND_DG} 9.8.2 Send Datagram Poll function SEND_DG_POLL( CID: CONNECT_ID; var PTR: Q_BUF_PTR): FSTATUS; { Check datagram return queue for datagram transmission buffer from previous send. } begin with CBA[CID.INDEX] do if REMOVE(CB$DG_RET_Q,PTR) then SEND_DG_POLL:=SUCCESS else SEND_DG_POLL:=FAIL end;{SEND_DG_POLL} SCS OPERATION Page 9-26 9.8.3 Receive Datagram function REC_DG( CID: CONNECT_ID; PTR: Q_BUF_PTR): FSTATUS; { Queue a buffer to the datagram receive queue. } begin with CBA[CID.INDEX] do if CB_CLOSED(CID) then REC_DG:=NOT_OPEN else begin CB$DG_REC:=CB$DG_REC+1; INSERT_DFREEQ(PTR); REC_DG:=SUCCESS; end end;{REC_DG} 9.8.4 Receive Datagram Poll function REC_DG_POLL( CID: CONNECT_ID; var DLEN: APPL_DG_LEN; var PTR: Q_BUF_PTR): FSTATUS; { Check CB datagram queue and return datagram if any have been received. } begin with CBA[CID.INDEX] do if REMOVE(CB$DG_Q,PTR) then begin DLEN:=PTR^.LENGTH-AP_DG_HDR_LEN; REC_DG_POLL:=SUCCESS end else REC_DG_POLL:=FAIL end;{REC_DG_POLL} SCS OPERATION Page 9-27 9.8.5 Cancel Receive Datagram function CANCEL_REC_DG( CID: CONNECT_ID; var PTR: Q_BUF_PTR): FSTATUS; { Return a queued datagram receive buffer. Function FAILS if no buffers are queued for this connection or if the global queue is empty. } begin with CBA[CID.INDEX] do if CB$DG_REC > 0 then if REMOVE_DFREEQ(PTR) = SUCCESS then begin CB$DG_REC:=CB$DG_REC-1; CANCEL_REC_DG:=SUCCESS end else CANCEL_REC_DG:=FAIL else CANCEL_REC_DG:=FAIL end;{CANCEL_REC_DG} SCS OPERATION Page 9-28 9.9 SEQUENTIAL MESSAGE SERVICE 9.9.1 Send Message function SEND_MSG( CID: CONNECT_ID; THRSH: WORD; RET_FLAG: boolean; MLEN: APPL_MSG_LEN; PTR: Q_BUF_PTR): FSTATUS; { Check that connection is operating. Send Message if credits are available. } begin with CBA[CID.INDEX] do if CB_CLOSED(CID) then SEND_MSG:=NOT_OPEN else if CB$SEND_CREDIT > THRSH then begin CB$SEND_CREDIT:=CB$SEND_CREDIT-1; { If we're keeping this buffer, note one more credit to extend. } if not RET_FLAG then CB$PEND_REC_CREDIT:= CB$PEND_REC_CREDIT+1; { If we have extra receive buffers to report, update estimated unused credits held by destination (CB$REC_CREDIT), send the outstanding credits by placing in message CREDIT field, and zero PENDING_REC_CREDIT to note that we're up to date. } if CB$PEND_REC_CREDIT > 0 then begin CB$REC_CREDIT:=CB$REC_CREDIT+CB$PEND_REC_CREDIT; PTR^.CREDIT:=CB$PEND_REC_CREDIT; CB$PEND_REC_CREDIT:=0; end else { Otherwise, we have not reported some cancelled buffers. } begin PTR^.CREDIT:=0; CB$RET_CREDIT:=CB$RET_CREDIT+1 end; { Fill in SCS header and transmit messge. } PTR^.LENGTH:=AP_MSG_HDR_LEN+MLEN; PTR^.SCS_TYPE:=APPL_MSG; PTR^.REC_CONNECT_ID:=CB$DST_CONNECT_ID; PTR^.SEND_CONNECT_ID:=CB$SRC_CONNECT_ID; SCS OPERATION Page 9-29 SNDMSG(CB$DST_PB,RET_FLAG,PTR); SEND_MSG:=SUCCESS end else SEND_MSG:=FAIL end;{SEND_MSG} 9.9.2 Send Message Poll function SEND_MSG_POLL( CID:CONNECT_ID; var PTR: Q_BUF_PTR): FSTATUS; { Check message return queue for received message } begin with CBA[CID.INDEX] do if REMOVE(CB$MSG_RET_Q,PTR) then SEND_MSG_POLL:=SUCCESS else SEND_MSG_POLL:=FAIL end;{SEND_MSG_POLL} 9.9.3 Receive Message function REC_MSG( CID: CONNECT_ID; PTR: Q_BUF_PTR): FSTATUS; { Receive message. Check connection status, queue the supplied buffer, and note that there is one more credit for the connection. } begin with CBA[CID.INDEX] do if CB_CLOSED(CID) then REC_MSG:=NOT_OPEN else begin REC_MSG:=SUCCESS; INSERT_MFREEQ(PTR); CB$PEND_REC_CREDIT:=CB$PEND_REC_CREDIT+1; { If we were going to ask for credits back, note that we got one back. } if CB$PEND_REC_CREDIT <= 0 then CB$RET_CREDIT:=CB$RET_CREDIT+1 { If remote side is below threshold, send credit message now. } else if CB$REC_CREDIT <= CB$MIN_REC_CREDIT then SCS OPERATION Page 9-30 begin if CB$BLOCK_STATE = ALLOC then begin CB$BLOCK_STATE:=CREDIT_PEND; if INSERT_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB) = WAS_EMPTY then INSERT_SCS_Q(CB$DST_PB); end end end end;{REC_MSG} 9.9.4 Receive Message Poll function REC_MSG_POLL( CID: CONNECT_ID; var MLEN: APPL_MSG_LEN; var PTR: Q_BUF_PTR): FSTATUS; { Check for reception of a message. Return buffer and data length. } begin with CBA[CID.INDEX] do if REMOVE(CB$MSG_Q,PTR) then begin MLEN:=PTR^.LENGTH-AP_MSG_HDR_LEN; REC_MSG_POLL:=SUCCESS end else REC_MSG_POLL:=FAIL end;{REC_MSG_POLL} SCS OPERATION Page 9-31 9.9.5 Cancel Receive Message procedure CANCEL_REC_MSG( CID: CONNECT_ID); { Cancel a receive message request. Note one less credit to send (or one more to take back). If we're going to extend more credits then note that we got one back (increment CB$RET_CREDIT) so that user will get buffer back. Otherwise, prepare CB so that credit message will be sent. The buffer is returned by calling CANCEL_REC_MSG_POLL. } begin with CBA[CID.INDEX] do begin CB$PEND_REC_CREDIT:=CB$PEND_REC_CREDIT-1; if CB$PEND_REC_CREDIT >= 0 then CB$RET_CREDIT:=CB$RET_CREDIT+1 else begin if CB$BLOCK_STATE = ALLOC then begin CB$BLOCK_STATE:=CREDIT_PEND; if INSERT_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB) = WAS_EMPTY then INSERT_SCS_Q(CB$DST_PB); end end end end;{CANCEL_REC_MSG} 9.9.6 Cancel Receive Message Poll function CANCEL_REC_MSG_POLL( CID: CONNECT_ID; var PTR: Q_BUF_PTR): FSTATUS; { Request return of buffers cancelled by CANCEL_REC_MESSAGE. CB$RET_CREDIT indicates number of buffers that can be returned. CB$RET_NULL indicates number of cancels requested but credits not returned from remote side. Status of NULL indicates that the cancel succeeded but the buffer can not be given back to the caller. } begin with CBA[CID.INDEX] do begin if CB$RET_CREDIT > 0 then begin CB$RET_CREDIT:=CB$RET_CREDIT-1; CANCEL_REC_MSG_POLL:=REMOVE_MFREEQ(PTR) end else if CB$RET_NULL > 0 then begin SCS OPERATION Page 9-32 CB$RET_NULL:=CB$RET_NULL-1; CANCEL_REC_MSG_POLL:=NULL end else CANCEL_REC_MSG_POLL:=FAIL end end;{CANCEL_REC_MSG_POLL} SCS OPERATION Page 9-33 9.10 BLOCK DATA SERVICE 9.10.1 Buffer Descriptor Table The buffer descriptor table is a data structure maintained by the SCS layer and readable by the PPD layer. The buffer descriptor table is referenced by buffer name and contains the length, address, and access control information for named buffers. A representative buffer descriptor table entry has the following format: 3 1 0 +-------------------------------+ | BUF_LENGTH | +-------------------------------+ | BUF_ADDRESS | +-------------------------------+ | BUF_ACCESS | +-------------------------------+ where: BUF_LENGTH the length of buffer. BUF_ADDR the address of the buffer and/or buffer mapping tables. BUF_ACCESS the buffer access control. SCS OPERATION Page 9-34 9.10.2 Map Buffer function MAP( {BLOCK_BUF: BUF_DESCR;} var NAME: LONG): FSTATUS; begin {fill in Buffer Descriptor Table entry end return buffer name} end;{MAP} 9.10.3 Unmap Buffer procedure UNMAP( NAME: LONG); begin {invalidate name and free Buffer Descriptor Table entry} end;{UNMAP} 9.10.4 Read function READ( CID: CONNECT_ID; THRSH: WORD; PTR: Q_BUF_PTR; var XID: WORD): FSTATUS; { Request block data transfer from destination. First check for connection condition and sufficient credits to perform operation. Assign a new transaction number for this transaction and return it to caller. } begin with CBA[CID.INDEX] do if CB_CLOSED(CID) then READ:=NOT_OPEN else if CB$SEND_CREDIT > THRSH then begin CB$SEND_CREDIT:=CB$SEND_CREDIT-1; PTR^.SEND_BLOCK_ID:=CID.INDEX; XID:=NEXT_XID; PTR^.SEND_XID:=XID; REQDAT(CB$DST_PB,PTR); READ:=SUCCESS end else READ:=FAIL SCS OPERATION Page 9-35 end;{READ} 9.10.5 Read Poll function READ_POLL( CID: CONNECT_ID; var PTR: Q_BUF_PTR; var XID: WORD): FSTATUS; { Check for completion of read block transfer. } begin with CBA[CID.INDEX] do if REMOVE(CB$READ_Q,PTR) then begin XID:= PTR^.SEND_XID; READ_POLL:=SUCCESS; end else READ_POLL:=FAIL; end{READ_POLL}; 9.10.6 Write function WRITE( CID: CONNECT_ID; THRSH: WORD; PTR: Q_BUF_PTR; var XID: WORD): FSTATUS; { Request block data transfer to destination system. Verify that connection is open, assign a new transaction number, and call PPD routine to perform the transfer. } begin with CBA[CID.INDEX] do if CB_CLOSED(CID) then WRITE:=NOT_OPEN else if CB$SEND_CREDIT > THRSH then begin CB$SEND_CREDIT:=CB$SEND_CREDIT-1; PTR^.SEND_BLOCK_ID:=CID.INDEX; XID:=NEXT_XID; PTR^.SEND_XID:=XID; SNDDAT(CB$DST_PB,PTR); WRITE:=SUCCESS end else WRITE:=FAIL end;{WRITE} SCS OPERATION Page 9-36 9.10.7 Write Poll function WRITE_POLL( CID: CONNECT_ID; var PTR: Q_BUF_PTR; var XID: WORD): FSTATUS; { Check for completion of write block transfer. } begin with CBA[CID.INDEX] do if REMOVE(CB$WRITE_Q,PTR) then begin XID:=PTR^.SEND_XID; WRITE_POLL:= SUCCESS end else WRITE_POLL:=FAIL end{WRITE_POLL}; SCS OPERATION Page 9-37 9.11 SCS SEND | procedure SCS_SEND; {PROCESS} | | var PTR: PB_PTR; | | { SCS work queue process to send SCS command messages. Path blocks | are queued to the work queue when a command is to be sent for | a connection. The CB$BLOCK_STATE field of the first connect | block queued to the PB specifies the work to be performed. | A control message is constructed in the single SCS command buffer | queued to the path block (PB), and the message is transmitted. } | | begin | | { Get next path block address in PTR. Dispatch on block state. } | | while REMOVE_SCS_Q(PTR) do with PTR^ do begin | case PB$CB_Q^.CB$BLOCK_STATE of | | CONNECT_PEND: | | { Prepare Connect Request Message. Fill in number of credits | now available (CB$PEND_REC_CREDIT) and the minimum number | of credits needed by destination (CB$MIN_REC_CREDIT). } | | begin | PB$MSG_PTR^.LENGTH:=CONNECT_REQ_LEN; | PB$MSG_PTR^.SCS_TYPE:=CONNECT_REQ; | PB$MSG_PTR^.CREDIT:=PB$CB_Q^.CB$PEND_REC_CREDIT; | { Update CB to note credits extended } | PB$CB_Q^.CB$PEND_REC_CREDIT:=0; | PB$MSG_PTR^.MIN_CREDIT:=PB$CB_Q^.CB$MIN_REC_CREDIT; | PB$MSG_PTR^.STATUS:=0; | PB$MSG_PTR^.REC_PROC:=PB$CB_Q^.CB$DST_PROC_NAME; | PB$MSG_PTR^.SEND_PROC:=PB$CB_Q^.CB$SRC_PROC_NAME; | PB$MSG_PTR^.SEND_DATA:=PB$CB_Q^.CB$CONNECT_DATA; | PB$CB_Q^.CB$CONNECT_STATE:=CONNECT_SENT | end; | | ACCEPT_PEND: | | { Prepare Accept message. Fill in number of credits | now available (CB$PEND_REC_CREDIT) and the minimum number | of credits needed by destination (CB$MIN_REC_CREDIT). } | | begin | PB$MSG_PTR^.LENGTH:=ACCEPT_REQ_LEN; | PB$MSG_PTR^.SCS_TYPE:=ACCEPT_REQ; | PB$MSG_PTR^.CREDIT:=PB$CB_Q^.CB$PEND_REC_CREDIT; | { Update CB to note credits extended } | PB$CB_Q^.CB$PEND_REC_CREDIT:=0; | PB$MSG_PTR^.MIN_CREDIT:=PB$CB_Q^.CB$MIN_REC_CREDIT; | PB$MSG_PTR^.STATUS:=0; | PB$MSG_PTR^.REC_PROC:=PB$CB_Q^.CB$DST_PROC_NAME; SCS OPERATION Page 9-38 | PB$MSG_PTR^.SEND_PROC:=PB$CB_Q^.CB$SRC_PROC_NAME; | PB$MSG_PTR^.SEND_DATA:=PB$CB_Q^.CB$CONNECT_DATA; | PB$CB_Q^.CB$CONNECT_STATE:=ACCEPT_SENT | end; | | REJECT_PEND: | | { Prepare Reject message with reason for rejection. | Give no credits (adding insult to injury). } | | begin | PB$MSG_PTR^.LENGTH:=REJECT_REQ_LEN; | PB$MSG_PTR^.SCS_TYPE:=REJECT_REQ; | PB$MSG_PTR^.CREDIT:=0; | PB$MSG_PTR^.MIN_CREDIT:=0; | PB$MSG_PTR^.STATUS:=PB$CB_Q^.CB$SRC_REASON; | PB$CB_Q^.CB$CONNECT_STATE:=REJECT_SENT | end; | | DISCONNECT_PEND: | | { Prepare Disconnect Request message. Connection state has | already been set to DISCONNECT_SENT or DISCONNECT_MATCH. } | | begin | PB$MSG_PTR^.LENGTH:=DISCON_REQ_LEN; | PB$MSG_PTR^.SCS_TYPE:=DISCON_REQ; | PB$MSG_PTR^.CREDIT:=0; | PB$MSG_PTR^.MIN_CREDIT:=0; | PB$MSG_PTR^.STATUS:=PB$CB_Q^.CB$SRC_REASON | end; | | CREDIT_PEND: | | { Prepare credit message. } | | begin | PB$MSG_PTR^.LENGTH:=CREDIT_REQ_LEN; | PB$MSG_PTR^.SCS_TYPE:=CREDIT_REQ; | PB$MSG_PTR^.CREDIT:=PB$CB_Q^.CB$PEND_REC_CREDIT; | PB$CB_Q^.CB$REQ_CREDIT:=PB$CB_Q^.CB$PEND_REC_CREDIT; | PB$CB_Q^.CB$PEND_REC_CREDIT:=0 | end; | end; | | { Now that message has been prepared, fill in source and | destination connect ID and send the message. } | | PB$MSG_PTR^.REC_CONNECT_ID:=PB$CB_Q^.CB$DST_CONNECT_ID; | PB$MSG_PTR^.SEND_CONNECT_ID:=PB$CB_Q^.CB$SRC_CONNECT_ID; | { must convert PTR to a PB Index for SNDMSG call } | SNDMSG( PBPTR_TO_PBINDEX(PTR) , false , PB$MSG_PTR); | end; | end;{SCS_SEND} SCS OPERATION Page 9-39 9.12 SCS RECEIVE | procedure SCS_REC; {PROCESS} | | var PTR: Q_BUF_PTR; | RSP: RSP_TYPE; | CNCT_INDEX: WORD; | DST: PB_INDEX; | | { Process to handle reception of messages, datagrams, and command | responses. There is a single SCS command buffer for each | port-to-port virtual circuit. Therefore, only one command can be | outstanding per path block. The buffer is consumed when an SCS | command is transmitted. When a response is received, the buffer | containing the response can be used to transmit another command. | This is done immediately if an immediate response is required. | Otherwise, the buffer is queued to the PB, and if any other CBs | are waiting on the PB, the PB is queued to the send work queue | for service. } | | begin | while RSP_POLL(RSP,DST,PTR) = SUCCESS do case RSP of | | { PTR now has address of a buffer (Q_BUF_PTR) | that has been received. Dispatch on the type | of response received. If DGSNT or MSGSNT response, | insert buffer on DG or MSG response queue. } | | DGSNT: | INSERT(CBA[PTR^.SEND_CONNECT_ID.INDEX].CB$DG_RET_Q,PTR); | | MSGSNT: | INSERT(CBA[PTR^.SEND_CONNECT_ID.INDEX].CB$MSG_RET_Q,PTR); | | | DGREC: | | { Datagram received. If receive queue has a buffer, insert | datagram on CB and note one less buffer available. Otherwise, | return buffer to datagram receive queue. } | | with CBA[PTR^.REC_CONNECT_ID.INDEX] do if CB$DG_REC > 0 | then | begin | CB$DG_REC:=CB$DG_REC-1; | INSERT(CB$DG_Q,PTR) | end | else INSERT_DFREEQ(PTR); | | MSGREC: | | { Message received. Locate CB for the message and dispatch | on the SCS message type. } | | with CBA[PTR^.REC_CONNECT_ID.INDEX] SCS OPERATION Page 9-40 | DO case PTR^.SCS_TYPE of | | { begin new case block } | | CONNECT_REQ: | | { Connect request recieved. Check if this conect | matches a pending Listen request. If so, initialize | credit and name fields. Return the Connect Response | message with proper status. } | | begin | if CONNECT_MATCH(PTR,CNCT_INDEX) then | with CBA[CNCT_INDEX] do | begin | CB$CONNECT_STATE:=CONNECT_REC; | CB$SEND_CREDIT:=PTR^.CREDIT; | CB$DST_CONNECT_ID:=PTR^.SEND_CONNECT_ID; | CB$DST_PROC_NAME:=PTR^.SEND_PROC; | CB$MIN_REC_CREDIT:=PTR^.MIN_CREDIT; | CB$CONNECT_DATA:=PTR^.SEND_DATA; | PTR^.STATUS:=CONNECTED | end | else PTR^.STATUS:=NO_MATCH; | PTR^.LENGTH:=CONNECT_RSP_LEN; | PTR^.SCS_TYPE:=CONNECT_RSP; | PTR^.CREDIT:=0; | PTR^.REC_CONNECT_ID:=PTR^.SEND_CONNECT_ID; | PTR^.SEND_CONNECT_ID:=CB$SRC_CONNECT_ID; | PTR^.MIN_CREDIT:=0; | SNDMSG(DST,false,PTR) | end; | | CONNECT_RSP: | | { Connect response received. Note whether connect was | processed or no matching listen was found. Restore the | message buffer for this PB, remove CB from queue, and | reinsert PB on work queue if more CB's are waiting. } | | begin | if PTR^.STATUS = CONNECTED then | CB$CONNECT_STATE:=CONNECT_ACK | else | begin | CB$CONNECT_STATE:=CLOSED; | CB$DST_REASON := PTR^.STATUS | end; | PBA[CB$DST_PB].PB$MSG_PTR:=PTR; | if REMOVE_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB) <> NOW_EMPTY | then INSERT_SCS_Q(CB$DST_PB); | end; | | ACCEPT_REQ: | SCS OPERATION Page 9-41 | { Accept Request received. Open connection and | initialize credit and connect data information. Send | The Accept Response message. } | | begin | CB$SEND_CREDIT:=PTR^.CREDIT; | CB$MIN_REC_CREDIT:=PTR^.MIN_CREDIT; | CB$CONNECT_STATE:=OPEN; | CB$CONNECT_DATA:=PTR^.SEND_DATA; | PTR^.LENGTH:=ACCEPT_RSP_LEN; | PTR^.SCS_TYPE:=ACCEPT_RSP; | PTR^.CREDIT:=0; | PTR^.REC_CONNECT_ID:=PTR^.SEND_CONNECT_ID; | PTR^.SEND_CONNECT_ID:=CB$SRC_CONNECT_ID; | SNDMSG(DST,false,PTR) | end; | | ACCEPT_RSP: | | { Accept Response message received. Save our message buffer, | remove CB from queue, and requeue PB if more to do for this | path. } | | begin | CB$CONNECT_STATE:=OPEN; | PBA[CB$DST_PB].PB$MSG_PTR:=PTR; | if REMOVE_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB) <> NOW_EMPTY | then INSERT_SCS_Q(CB$DST_PB); | end; | | REJECT_REQ: | | { Reject Request received. Close the channel, save the reject | reason, and send the Reject Response message. } | | begin | CB$CONNECT_STATE:=CLOSED; | CB$DST_REASON:=PTR^.STATUS; | PTR^.LENGTH:=REJECT_RSP_LEN; | PTR^.SCS_TYPE:=REJECT_RSP; | PTR^.CREDIT:=0; | PTR^.REC_CONNECT_ID:=PTR^.SEND_CONNECT_ID; | PTR^.SEND_CONNECT_ID:=CB$SRC_CONNECT_ID; | SNDMSG(DST,false,PTR) | end; | | REJECT_RSP: | | { Reject Response received. Save our SCS message buffer | and check if more work for this PB. } | | begin | CB$CONNECT_STATE:=CLOSED; | PBA[CB$DST_PB].PB$MSG_PTR:=PTR; | if REMOVE_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB) <> NOW_EMPTY SCS OPERATION Page 9-42 | then INSERT_SCS_Q(CB$DST_PB); | end; | | DISCON_REQ: | | { Disconnect request received. The connection can be in | one of three states: OPEN, DISCONNECT_SENT, or DISCONNECT_ACK. | For each state, set the correct new state. For OPEN or | DISCONNECT_SENT states, a DISCONNECT_RSP message must | be transmitted. A DISCONNECT_REQ message received while in | DISCONNECT_SENT state means that both SYSAPS initated | disconnection simultaneously. If the connection is in | DISCONNECT_ACK state, the connection is closed, the message | buffer is saved, and the queue is checked for more work. } | | begin | case CB$CONNECT_STATE of | OPEN: CB$CONNECT_STATE:=DISCONNECT_REC; | DISCONNECT_SENT: CB$CONNECT_STATE:=DISCONNECT_MATCH; | DISCONNECT_ACK: CB$CONNECT_STATE:=CLOSED | end; | | if CB$CONNECT_STATE=CLOSED | then | begin | PBA[CB$DST_PB].PB$MSG_PTR:=PTR; | if REMOVE_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB) <> | NOW_EMPTY then INSERT_SCS_Q(CB$DST_PB) | end | else | begin | CB$DST_REASON:=PTR^.STATUS; | PTR^.LENGTH:=DISCON_RSP_LEN; | PTR^.SCS_TYPE:=DISCON_RSP; | PTR^.CREDIT:=0; | PTR^.REC_CONNECT_ID:=PTR^.SEND_CONNECT_ID; | PTR^.SEND_CONNECT_ID:=CB$SRC_CONNECT_ID; | SNDMSG(DST,false,PTR) | end | end; | | DISCON_RSP: | | { Disconnect Response received. The connection can be | in one of two states. If in DISCONNECT_SENT state, we initiated | the disconnect, and now move to DISCONNECT_ACK to wait for | the remote SYSAP to disconnect. If in DISCONNECT_MATCH state, | we're waiting for confirmation that the initator knows that | we've received the passive SYSAP disconnect. Here we close | down the connection and look for more work to do. } | | begin | if CB$CONNECT_STATE = DISCONNECT_SENT | then | begin SCS OPERATION Page 9-43 | CB$CONNECT_STATE:= DISCONNECT_ACK; | CB$DST_REASON:=PTR^.STATUS; | PTR^.LENGTH:=DISCON_RSP_LEN; | PTR^.SCS_TYPE:=DISCON_RSP; | PTR^.REC_CONNECT_ID:=PTR^.SEND_CONNECT_ID; | PTR^.SEND_CONNECT_ID:=CB$SRC_CONNECT_ID; | SNDMSG(DST,false,PTR) | end | else { CB$CONNECT_STATE = DISCONNECT_MATCH } | begin | CB$CONNECT_STATE:=CLOSED; | PBA[CB$DST_PB].PB$MSG_PTR:=PTR; | if REMOVE_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB) <> | NOW_EMPTY then INSERT_SCS_Q(CB$DST_PB) | end | end; | | CREDIT_REQ: | | { Credit Request received. Credit request can be positive | (to indicate more credits) or negative (to take some back). | If negative, only give back the minimum of the number | requested and the number available without going below | the SCS threshold for this connection. Return | Credit Response message. } | | begin | if PTR^.CREDIT < 0 | then PTR^.CREDIT:= | -MIN( MAX(0,CB$SEND_CREDIT-CB$MIN_SEND_CREDIT), | -PTR^.CREDIT); | | { make positive or negative adjustment } | | CB$SEND_CREDIT:=CB$SEND_CREDIT+PTR^.CREDIT; | PTR^.LENGTH:=CREDIT_RSP_LEN; | PTR^.SCS_TYPE:=CREDIT_RSP; | PTR^.REC_CONNECT_ID:=PTR^.SEND_CONNECT_ID; | PTR^.SEND_CONNECT_ID:=CB$SRC_CONNECT_ID; | SNDMSG(DST,false,PTR) | end; | | CREDIT_RSP: | | { Credit Response received. Adjust credit values for | number actually returned, if credit return was requested. } | | begin | if CB$REQ_CREDIT < 0 then | begin | CB$RET_CREDIT:=CB$RET_CREDIT-PTR^.CREDIT; | CB$RET_NULL:=CB$RET_NULL+PTR^.CREDIT-CB$REQ_CREDIT; | end; | CB$REC_CREDIT:=CB$REC_CREDIT+PTR^.CREDIT; | PBA[CB$DST_PB].PB$MSG_PTR:=PTR; SCS OPERATION Page 9-44 | | { If credits are waiting to be taken back from the destination | due to cancels, OR if there are buffers not credited AND | the destination is below threshold, then insert this PB | on the work queue to send the credit message. } | | if (CB$PEND_REC_CREDIT < 0) or | ((CB$PEND_REC_CREDIT > 0) and | (CB$REC_CREDIT < CB$MIN_REC_CREDIT)) then | INSERT_SCS_Q(CB$DST_PB) | | { Otherwise, just check to see if there's anything else to do. } | | else if REMOVE_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB) <> | NOW_EMPTY then INSERT_SCS_Q(CB$DST_PB) | end; | | APPL_MSG: | | { Application Message received. Insert on message queue for | this connection. } | | begin | CB$REC_CREDIT:=CB$REC_CREDIT-1; | CB$SEND_CREDIT:=CB$SEND_CREDIT+PTR^.CREDIT; | INSERT(CB$MSG_Q,PTR) | end; | | end;{case PTR^.SCS_TYPE} | | | DATREC: | with CBA[PTR^.SEND_BLOCK_ID] do begin | INSERT(CB$READ_Q,PTR); | CB$SEND_CREDIT:=CB$SEND_CREDIT+1; | end; | | CNFREC: | with CBA[PTR^.SEND_BLOCK_ID] do begin | INSERT(CB$WRITE_Q,PTR); | CB$SEND_CREDIT:= CB$SEND_CREDIT+1; | end; | | IDREC: | {if then | PBA[PTR^.SEND_BLOCK_ID].PB$DST_VC_STATE:= | MAINT | else if PBA[PTR^.SEND_BLOCK_ID].PB$DST_VC_STATE = | CLOSED then VC_START( )} | INSERT(PBA[PTR^.SEND_BLOCK_ID].PB$DG_Q,PTR); | | MDATREC, | MCNFREC: | INSERT(PBA[PTR^.SEND_BLOCK_ID].PB$DG_Q,PTR); | SCS OPERATION Page 9-45 | end;{case RSP} | end;{SCS_REC} CHAPTER 10 CI PPD OPERATION The operation of the PPD layer is port specific. This section describes the operation of the CI PPD layer. 10.1 PPD DATAGRAMS 10.1.1 Start The START datagram is used to start virtual circuit initialization. The format of START is: 3 1 1 5 0 +---------------+---------------+ | PPD_TYPE | LENGTH | +---------------+---------------+ | | = START_DATA = | | +-------------------------------+ where: LENGTH START_LEN. PPD_TYPE START. START_DATA start data. See Appendix F. CI PPD OPERATION Page 10-2 10.1.2 Start Acknowledge The STACK datagram is used to acknowledge receipt of a START. The format of STACK is: 3 1 1 5 0 +---------------+---------------+ | PPD_TYPE | LENGTH | +---------------+---------------+ | | = START_DATA = | | +-------------------------------+ where: LENGTH STACK_LEN. PPD_TPE STACK. START_DATA start data. See Appendix F. CI PPD OPERATION Page 10-3 10.1.3 Acknowledge The ACK datagram is used to acknowledge the receipt of a STACK. The format of ACK is: 3 1 1 5 0 +---------------+---------------+ | PPD_TYPE | LENGTH | +---------------+---------------+ where: LENGTH ACK_LEN. PPD_TYPE ACK. CI PPD OPERATION Page 10-4 10.2 START VIRTUAL CIRCUIT A virtual circuit exists in one of four states: VC_CLOSED, START_SENT, START_REC, and VC_OPEN. The state is stored in the appropriate system block. Events cause transitions between states. An event is either an initialization function call, a timer expiration, or receipt of a virtual circuit initialization datagram. The initialization sequence is a standard 3-way handshake (used, for example, by DECNET/DNA DDCMP). The initialization state table follows: CURRENT STATE EVENT ACTION NEW STATE VC_CLOSED START call send START START_SENT start timer START_SENT rec STACK open port VC VC_OPEN send ACK stop timer rec START open port VC START_REC send STACK start timer timer expires send START START_SENT start timer START_REC rec ACK stop timer VC_OPEN rec SCS request stop timer VC_OPEN control message rec STACK send ACK VC_OPEN stop timer rec START send STACK START_REC start timer timer expires send STACK START_REC start timer VC_OPEN rec START close port VC VC_CLOSED notify SCS rec STACK send ACK VC_OPEN rec ACK - VC_OPEN VC failure notify SCS VC_CLOSED detected CI PPD OPERATION Page 10-5 Notes: | | 1. The initial value of the timer is at least one second. 2. The port VC is opened and closed using the SETCKT command. CI PPD OPERATION Page 10-6 10.3 CONFIGURATION | The system list is built by the PPD layer polling with REQID port | functions directed to all possible destination ports. The IDREC | responses are used to fill in the system blocks. This procedure is | repeated periodically to insure that the system list is current. | Also, any unsolicited IDREC responses received are used to fill in the | system blocks and path blocks. 10.4 OTHER PPD INTERFACE FUNCTIONS The other PPD interface functions and procedures are in one-to-one correspondence with CI port commands and responses. CHAPTER 11 NI PPD OPERATION \TBS\ CHAPTER 12 BI PPD OPERATION \TBS\ APPENDIX A PROCESS NAMING A process name is a 16 byte string. A process name starts with an upper case letter (A-Z) or a dollar sign ($). The remaining characters can be upper case letters, numbers (0-9), dollar signs, or underlines (_) except that the last character cannot be an underline. Blank () characters are added to the end of the string if necessary to fill the string to 16 characters. It is intended in SCA that process names be human understandable. The preferred structure for naming is as follows: $ Examples of names are: MSCP$DISK - MSCP disk service. MSCP$TAPE - MSCP tape service. SCS$DIRECTORY - SCS process name directory service. APPENDIX B DIRECTORY SERVICE B.1 INTRODUCTION Each system maintains a directory process with process name SCS$DIRECTORY. SYSAP processes can obtain a directory of processes in a destination system by connecting to the directory process in the destination system. B.2 LOCAL DIRECTORY MANAGEMENT Process names are entered in and deleted from the local directory using SCS level function calls of the same form as the SCS or PPD interface. B.2.1 Enter This function enters process name in the local directory: function ENTER( PROC: PROC_NAME, INFO: PROC_INFO): FSTATUS; where: PROC the process name to be entered. INFO (16 bytes) additional process information. FSTATUS SUCCESS if name entered; FAIL otherwise. DIRECTORY SERVICE Page B-2 B.2.2 Delete This function deletes a process name from the local directory: function DELETE( PROC: PROC_NAME): FSTATUS; where: PROC process name to be deleted. FSTATUS SUCCESS if process name in directory; FAIL otherwise. B.3 REMOTE DIRECTORY ACCESS After connecting to the remote directory process, the SYSAP sends an application message containing a lookup request. The directory process returns a lookup response application message containing the result of the lookup operation. DIRECTORY SERVICE Page B-3 B.3.1 Lookup Request The format of the message is: 3 1 1 5 0 +---------------+---------------+ | ENTRY | FORM | +---------------+---------------+ | | = PROC_NAME = | | +-------------------------------+ where: FORM the form of directory lookup (BY_NAME, BY_ENTRY) BY_NAME = 0, BY_ENTRY = 1. ENTRY the entry number if BY_ENTRY; ignored otherwise: entries start at one. PROC_NAME the process name if BY_NAME; ignored otherwise. | | BY_ENTRY lookup is used to obtain a complete list of directory | entires. This is done by specifying entry one and then succeeding | entry numbers until a failure status is returned indicating there are | no more entries. Entry numbers are densely assigned. DIRECTORY SERVICE Page B-4 B.3.2 Lookup Response The format of the message is: 3 1 1 5 0 +---------------+---------------+ | ENTRY | STATUS | +---------------+---------------+ | | = PROC_NAME = | | +-------------------------------+ | | = PROC_INFO = | | +-------------------------------+ where: STATUS SUCCESS if a directory name found; FAIL otherwise. ENTRY if SUCCESS, the entry number; UNPREDICTABLE otherwise. PROC_NAME if SUCCESS, the process name; UNPREDICTABLE otherwise. PROC_INFO (16 bytes) if SUCCESS, additional process information; UNPREDICTABLE otherwise. APPENDIX C THIRD PARTY I/O Third party I/O is an I/O operation involving three or more systems. Consider the following: CI --------------+---------------+---------------+-------------- | | | | | | +-------+------+ +------+------+ +------+-------+ | system X(U) | | system Y(F) | | system Z(D) | +--------------+ +-------------+ +--------------+ System X contains a file user process U. System Y contains a file server process F. System Z contains a disk server process D for the disks storing the file system. For D to directly read block data from U or write block data to U for file operations the following steps apply: 1. Process U connects to F requesting file services. 2. F sends to U the identity of Z and D and requests U to connect to D. 3. U sends to F the pair. 4. F requests D to perform block data operations directly to U by passing (in a higher level protocol such as MSCP) a 96-bit qualified buffer name of the following format: THIRD PARTY I/O Page C-2 3 1 0 +-------------------------------+ | SRC_CONNECT_ID | +-------------------------------+ | DST_CONNECT_ID | +-------------------------------+ | NAME | +-------------------------------+ where: SRC_CONNECT_ID the connect id of the process initiating the block data transfers (in this example D). DST_CONNECT_ID the connect id of the target of the block data transfers (in this example U). NAME the buffer name of the target of the block data transfers (in this example U). APPENDIX D SCS/PPD TYPE AND LENGTH CODES | {SCSPPDDEF} | | { Define SCS message types codes. } | | CONNECT_REQ = 0; { connect message } | | CONNECT_RSP = 1; { connect response } | | ACCEPT_REQ = 2; { accept connection } | | ACCEPT_RSP = 3; { accept response } | | REJECT_REQ = 4; { reject connection } | | REJECT_RSP = 5; { reject response } | | DISCON_REQ = 6; { disconnect message } | | DISCON_RSP = 7; { disconnect response } | | CREDIT_REQ = 8; { extend/retract credits } | | CREDIT_RSP = 9; { credit response } | | APPL_MSG = 10; { application message } | | APPL_DG = 11; { application datagram } | | { Define PPD message type codes. } | | START = 0; { start virtual circuit } | | STACK = 1; { acknowledge START } | | ACK = 2; { acknowledge STACK } | | SCS_DG = 3; { SCS datagram } | | SCS_MSG = 4; { SCS message } SCS/PPD TYPE AND LENGTH CODES Page D-2 | | { PPD message types with the sign bit set are reserved for } | { implementation use and are not part of the protocol over } | { the interconnect. } | | { Define SCS/PPD message lengths } | | CONNECT_REQ_LEN = 66; | | CONNECT_RSP_LEN = 18; | | ACCEPT_REQ_LEN = 66; | | ACCEPT_RSP_LEN = 18; | | REJECT_REQ_LEN = 18; | | REJECT_RSP_LEN = 14; | | DISCON_REQ_LEN = 18; | | DISCON_RSP_LEN = 14; | | CREDIT_REQ_LEN = 18; | | CREDIT_RSP_LEN = 14; | | AP_MSG_HDR_LEN = 14; | | AP_DG_HDR_LEN = 14; | | START_LEN = 42; | | STACK_LEN = 42; | | ACK_LEN = 6; {SCSPPDEND} APPENDIX E REJECTION AND DISCONNECTION REASON CODES | There is no guarantee that additional assigned codes are contiguously | assigned. All unassigned values are reserved for SYSAP private use | and their use may overlap between different SYSAP protocols. Common | useage is encouraged, however. | {CONREJDEF} | | { Connection accept/reject reason codes. } | | { Message codes have two fields. The lower three bits are } | { the severity and the bits 3-15 are the code. } | | { Severity values } | | { 0 = warning } | { 1 = success } | { 2 = error } | { 3 = reserved } | { 4 = severe error } | { 5 - 7 = reserved } | | CONNECTED = 1; { general success } | | NO_MATCH = 10; { no matching listen found } | | NO_RESOURCES = 18; { no resources available to process request } | | DISCONNECTED = 26; { connection has been broken } | | RESERVED = 34; { RESERVED } | | {CONREJEND} APPENDIX F CI START DATA FORMAT | | 3 | 1 0 | +-------------------------------+ | | PPD MTYPE | LENGTH | | +-------------------------------+ | | SEND_SYS | | +---------------+ | | | MBZ | PRTVRS| | | +---------------+---------------+ | | MAX_MSG | MAX_DG | | +---------------+---------------+ | | SW_TYPE | | +-------------------------------+ | | SW_VERSION | | +-------------------------------+ | | SW_INCARNATION | | | | | +-------------------------------+ | | HW_TYPE | | +-------------------------------+ | | | | = HW_VERSION = | | | | +-------------------------------+ | | NODE_NAME | | | | | +-------------------------------+ | | CUR_TIME | | | | | +-------------------------------+ | where: SEND_SYS the system address of the system sending the start data. CI START DATA FORMAT Page F-2 | PRTVRS protocol version (MBZ at this time). MAX_DG the maximum datagram size (in bytes) supported by the system. MAX_MSG the maximum message size (in bytes) supported by the system. SW_TYPE the type of the software in the system. Currently defined are 'VMS ','T-10', and 'T-20'. SW_VERSION the version number of the software in the system. SW_INCARNATION (8 bytes) the incarnation number of the software in the system. HW_TYPE the type of system hardware. | | HW_VERSION (12 bytes) the version number of the system | hardware. NODE_NAME (8 bytes) the ASCII node name of the system sending the message. CUR_TIME (8 bytes) the 64-bit current system time on the system sending the message. APPENDIX G EXAMPLE CI MESSAGE The following figure shows a SYSAP message and its encapsulation inside of SCS, PPD, and CI Port layer headers. This figure represents the send message command as presented to the CI port command queue. The double lines indicate layer boundaries. 3 2 1 1 3 5 7 0 +-------------------------------+ | FLINK | +-------------------------------+ | BLINK | +-------+-------+---------------+ CI PORT HEADER |SWFLAG | TYPE | SIZE | +-------+-------+-------+-------+ | FLAGS | OPC | STATUS| PORT | +=======+=======+=======+=======+ | PPD MTYPE | LENGTH | PPD HEADER +===============+===============+ | CREDIT | SCS MTYPE | +---------------+---------------+ | DESTINATION CONNECT ID | SCS HEADER +-------------------------------+ | SOURCE CONNECT ID | +===============================+ | | . . . APPLICATION MESSAGE . SYSAP MESSAGE . . | | +-------------------------------+ where: FLINK command queue forward link. BLINK command queue backward link. EXAMPLE CI MESSAGE Page G-2 SIZE size in bytes of structure containing the entire message (used by software only). TYPE software data structure type (used by software only). SWFLAG software flags (used by software only). PORT destination CI port number. STATUS packet status on response. OPC CI port opcode, e.g., SNDMSG in this case. FLAGS CI command flags. LENGTH number of bytes from PPD MTYPE field to end of SYSAP message (this field is shared by the PPD and SCS layers). PPD MTYPE command type code for PPD layer, e.g., SCS_SEND in this case. SCS MTYPE message type for SCS layer, e.g., APPL_MSG in this case. DESTINATION CONNECT ID connect ID of the target SYSAP process. SOURCE CONNECT ID connect ID of the sending SYSAP process. APPLICATION MESSAGE the data to be transmitted to the target SYSAP. APPENDIX H MINIMAL SUPPORT Subsetting of the SCS features is allowed. For example, some SCS systems may not implement block transfer operations. However, all systems implementing SCS must be able to: 1. Process the PPD start sequence. 2. Interpret all SCS messages. 3. Process all SCS control messages and provide proper response. APPENDIX I CHANGE HISTORY Rev. 2 to Rev. 3 change history. (All changes within change bars.) 1. Change data structures to allow for multiple interconnect paths between systems. Each system block now has a chain of path blocks, one for each intersystem path. The system block and connection block data structures are modified, and the path block data structure is added. The SCS message buffer is now queued to the path block, and the path block is queued to the SCS work queue for control message processing. In addition, the following procedures required interface modifications: 1. CONFIGURATION (changed to two procedures: CONFIG_SYS and CONFIG_PATH) 2. INSERT_SCS_Q 3. REMOVE_SCS_Q 4. SNDDG 5. SNDMSG 6. SNDDAT 7. REQDAT 8. REQID 9. RSP_POLL 10. START_VC 11. STATE_POLL 12. REQ_ID The following required minor code changes (due to calls to changed interfaces listed above). CHANGE HISTORY Page I-2 1. ACCEPT 2. REJECT 3. CONNECT 4. DISCONNECT 5. SEND_DG 6. SEND_MSG 7. REC_MSG 8. CANCEL_REC_MSG 9. READ 10. WRITE 11. SCS_REC 2. Two optional parameters are added to CONNECT. The PATH parameter allows a SYSAP to request connection over a specific path. The ERROR parameter provides a calling address for SCS to notify the SYSAP on the receipt of an erroneous packet. 3. A DISCONNECT request by one side now causes the connection to be closed by both local and remote SCSs. A new state, DISCONNECT_CNF, is added to the state diagram. A new SCS disconnect confirmed control message and response pair, DISCNF_REQ and DISCNF_RSP, are added. This second set of disconnect messages ensure that all pending transfer operations terminate before connection resources are released. The following changes are made: 1. A new function, CB_CLOSED, is added to check for closed state of a connection. 2. Procedures SEND_DG, REC_DG, and REC_MSG are changed to functions. 3. Functions SEND_DG, REC_DG, SEND_MSG, REC_MSG, READ, and WRITE now check to verify that the connection is open. If the connection has been closed, status NOT_OPEN is returned. 4. All PPD and SCS maintenance commands, messages, and responses are removed. CHANGE HISTORY Page I-3 5. The position of the reserved word in Start Data Format, Appendix G, is changed to follow the system address. 6. The HW_VERSION field is changed to 16 bytes. 7. A new appendix is added showing the format of a sample CI message transmission, including application message, SCS header, PPD header, and CI port header. 8. A new appendix is added describing minimal support. 9. Former appendix D, Multi CI Port Support, is removed. 10. New connection state CLOSED_NR is added to indicate that destination had no resources to process CONNECT, e.g., busy processing another connect request. This is indicated by NO_RESOURCES response. 11. Substantial style changes are made to the Pascal code and specification. Rev. 3 to Rev. 4 change history. (included in Rev. 3 change bars) 1. Change disconnect protocol to require both SYSAPs to issue DISCONNECT requests before the connection is shutdown. The new protocol uses only two messages, DISCONNECT_REQ and DISCONNECT_RSP, but introduces states DISCONNECT_MATCH and DISCONNECT_ACK. The following sections required changes: 1. Section 6.1, Type Definitions, was modified to add the new states to the C_STATE definition. 2. Section 6.3, Connection Management Services, was modified to add the new states and a description of the disconnect protocol. 3. Section 6.3.5, Disconnect call in the SYSAP-SCS interface, was changed to note that only the calling side is prohibited from transmitting further messages. 4. Former Sections 8.2.9 and 8.2.10 of Version 3, describing the Disconnect Confirmation messages, were removed. 5. Section 9.6.2, Connection States in SCS Operation, was modified. The connection state table was changed to reflect the new protocol, and the description following that table was modified to note the disconnect requirements for multi-priority ports. 6. Section 9.6.7, Disconnect procedure code, was modified because disconnect can be called in one of two states. CHANGE HISTORY Page I-4 7. Section 9.10, the SCS Send procedure code, was modified. The DISCONNECT_PEND code was changed (only the comments) to note the possible current states. 8. Section 9.11, SCS Receive procedure code, was modified. The DISCNF_REQ and DISCNF_RSP code from Rev. 3 were removed. The DISCON_REQ and DISCON_RSP code was modified to show the path for various connection states. 2. The Start/Stack Data Format, Appendix F, is changed to add two new fields. The CUR_TIME field is added to provide system time for initializing nodes that do not have a clock. The NODE_NAME field specifies the ASCII node name of the sender. 3. The System Block data structure is modified to add the NODE_NAME field. 4. The CONFIG_SYS function, Section 6.2.1, is changed to add the NODE_NAME return parameter. | | Rev. 4 to Rev. 5 change history. (change bars include only Rev. 5 | changes) | | 1. Contrasting of architecture and functional specifications in | Introduction. | | 2. Remove reference to requirements for supporting clusters with | multiple CI's. | | 3. Describe SW_INCARNATION in system block. | | 4. Remove CLOSED_NM, _NR, _REJ and _VC states leaving only | CLOSED. Add CONNECT_ACK, ACCEPT_SENT, and REJECT_SENT | states. Update description in section 6.3 Connection | management services and pascal code to reflect these state | changes. | | 5. Rename PTR to CREDITS in CONNECT and ACCEPT calls. | | 6. Remove THRSH from LISTEN and put it in ACCEPT. | | 7. Remove ERROR from CONNECT call. | | 8. State that datagrams are queued and accounted for on a | connection by connection basis in section 6.4 Datagram | service. | | 9. State that an implementation "MUST" provide a provision for | canceling block data transfers, but that there is a | restriction due to design of CI port hardware. Section 6.6 | block data service. CHANGE HISTORY Page I-5 | 10. Describe need for MPTR1 and MPTR2 and DPTR in START_VC call. | Section 7.3.1 Start Virtual Circuit. | | 11. Remove REQ_ID and REQID functions from PPD interface. | | 12. Rewrite section 9.6.2 Connection States to reflect reality. | | 13. Define PPD message type codes with sign bit set as reserved | for an implementation to use internally. | | 14. Change definitions of reject and disconnect reason codes to | include more codes and severity encoding. | | 15. Change definition of Start Data format to include protocol | version field and remove 4 bytes from the HW_VERSION. | | 16. Define the credit management variables a little better. | | 17. Explain START/STACK operation with protocol mismatch for | later use. | | 18. Fix the pascal program to store something in REQ_CREDIT | before using the value stored there. | | 19. Minor updates. | | | Rev. 5 to Rev. 6 changes (included in Rev. 5 change bars) | | 1. Describe rules for verifying minimum message size for SYSAP | protocol. Section 6.3. | | 2. Define BY_NAME and BY_ENTRY in section B.3.1. | | 3. Make statement about REJECT and DISCONNECT reason codes in | appendix E. Reserve code 34. |