! SYSTEMS COMMUNICATIONS ARCHITECTURE - FOR INTERNAL USE ONLY Page 1 ! ! ! ! File: SCA.MEM ! ! Date: 8-Aug-1985 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 ! ! 7 Updates Darrell Duffy 8-Aug-85 ! ! SYSTEMS COMMUNICATIONS ARCHITECTURE - FOR INTERNAL USE ONLY Page 2 CONTENTS CHAPTER 1 INTRODUCTION ! 1.1 SCA ARCHITECTURE ECO PROCESS . . . . . . . . . . . 1-3 ! 1.1.1 Participants In The ECO Process . . . . . . . . 1-3 ! 1.1.2 ECO Proposals . . . . . . . . . . . . . . . . . 1-4 ! 1.1.3 ECO Review . . . . . . . . . . . . . . . . . . . 1-4 ! 1.1.4 ECO Approval And Appeal . . . . . . . . . . . . 1-4 ! 1.1.5 ECO Publishing And Distribution . . . . . . . . 1-5 ! 1.1.6 Conformance . . . . . . . . . . . . . . . . . . 1-5 ! 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-2 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 ! ! SYSTEMS COMMUNICATIONS ARCHITECTURE - FOR INTERNAL USE ONLY Page 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 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 ! ! SYSTEMS COMMUNICATIONS ARCHITECTURE - FOR INTERNAL USE ONLY Page 4 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-7 ! 8.2.5 Reject Request . . . . . . . . . . . . . . . . . 8-8 ! 8.2.6 Reject Response . . . . . . . . . . . . . . . . 8-9 ! 8.2.7 Disconnect Request . . . . . . . . . . . . . . 8-10 ! 8.2.8 Disconnect Response . . . . . . . . . . . . . 8-11 ! 8.2.9 Credit Request . . . . . . . . . . . . . . . . 8-12 ! 8.2.10 Credit Response . . . . . . . . . . . . . . . 8-13 ! 8.3 APPLICATION MESSAGE . . . . . . . . . . . . . . 8-14 ! 8.4 APPLICATION DATAGRAM . . . . . . . . . . . . . . 8-15 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-4 ! 9.5 TYPE, VARIABLE , FUNCTION, AND PROCEDURE ! DEFINITIONS . . . . . . . . . . . . . . . . . . . 9-6 ! 9.6 CONFIGURATION SERVICE . . . . . . . . . . . . . 9-11 ! 9.6.1 System Block . . . . . . . . . . . . . . . . . 9-11 ! 9.6.2 Path Block . . . . . . . . . . . . . . . . . . 9-13 ! 9.6.3 Configuration Services . . . . . . . . . . . . 9-14 ! 9.7 CONNECTION MANAGEMENT SERVICE . . . . . . . . . 9-16 ! 9.7.1 Connection Block . . . . . . . . . . . . . . . 9-16 ! 9.7.2 Connection States . . . . . . . . . . . . . . 9-20 ! 9.7.3 Connect . . . . . . . . . . . . . . . . . . . 9-22 ! 9.7.4 Listen . . . . . . . . . . . . . . . . . . . . 9-23 ! 9.7.5 Accept . . . . . . . . . . . . . . . . . . . . 9-23 ! 9.7.6 Reject . . . . . . . . . . . . . . . . . . . . 9-24 ! 9.7.7 Disconnect . . . . . . . . . . . . . . . . . . 9-24 ! 9.7.8 State Poll . . . . . . . . . . . . . . . . . . 9-25 ! 9.8 DATAGRAM SERVICE . . . . . . . . . . . . . . . . 9-26 ! 9.8.1 Send Datagram . . . . . . . . . . . . . . . . 9-26 ! 9.8.2 Send Datagram Poll . . . . . . . . . . . . . . 9-26 ! 9.8.3 Receive Datagram . . . . . . . . . . . . . . . 9-27 ! 9.8.4 Receive Datagram Poll . . . . . . . . . . . . 9-27 ! 9.8.5 Cancel Receive Datagram . . . . . . . . . . . 9-28 ! 9.9 SEQUENTIAL MESSAGE SERVICE . . . . . . . . . . . 9-29 ! 9.9.1 Send Message . . . . . . . . . . . . . . . . . 9-29 ! 9.9.2 Send Message Poll . . . . . . . . . . . . . . 9-30 ! 9.9.3 Receive Message . . . . . . . . . . . . . . . 9-30 ! 9.9.4 Receive Message Poll . . . . . . . . . . . . . 9-31 ! 9.9.5 Cancel Receive Message . . . . . . . . . . . . 9-32 ! 9.9.6 Cancel Receive Message Poll . . . . . . . . . 9-32 ! 9.10 BLOCK DATA SERVICE . . . . . . . . . . . . . . . 9-34 ! 9.10.1 Buffer Descriptor Table . . . . . . . . . . . 9-34 ! 9.10.2 Map Buffer . . . . . . . . . . . . . . . . . . 9-35 ! ! SYSTEMS COMMUNICATIONS ARCHITECTURE - FOR INTERNAL USE ONLY Page 5 ! ! ! 9.10.3 Unmap Buffer . . . . . . . . . . . . . . . . . 9-35 ! 9.10.4 Read . . . . . . . . . . . . . . . . . . . . . 9-35 ! 9.10.5 Read Poll . . . . . . . . . . . . . . . . . . 9-36 ! 9.10.6 Write . . . . . . . . . . . . . . . . . . . . 9-36 ! 9.10.7 Write Poll . . . . . . . . . . . . . . . . . . 9-37 ! 9.11 SCS SEND . . . . . . . . . . . . . . . . . . . . 9-38 ! 9.12 SCS RECEIVE . . . . . . . . . . . . . . . . . . 9-40 CHAPTER 10 CI PPD OPERATION 10.1 PPD DATAGRAMS . . . . . . . . . . . . . . . . . 10-1 10.1.1 Start . . . . . . . . . . . . . . . . . . . . 10-1 10.1.2 Start Acknowledge . . . . . . . . . . . . . . 10-2 10.1.3 Acknowledge . . . . . . . . . . . . . . . . . 10-3 ! 10.1.4 Error Log Datagram . . . . . . . . . . . . . . 10-4 ! 10.1.5 Node Stop Datagram . . . . . . . . . . . . . . 10-6 ! 10.2 START VIRTUAL CIRCUIT . . . . . . . . . . . . . 10-7 ! 10.3 CONFIGURATION . . . . . . . . . . . . . . . . . 10-9 ! 10.4 OTHER PPD INTERFACE FUNCTIONS . . . . . . . . . 10-9 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 ! ! SYSTEMS COMMUNICATIONS ARCHITECTURE - FOR INTERNAL USE ONLY Page 6 ! APPENDIX G EXAMPLE CI MESSAGE APPENDIX H MINIMAL SUPPORT ! APPENDIX I WAIVERS ! ! ! APPENDIX J 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 serve to specify 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 an 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 ! o Certain field content descriptions have exact definitions in ! this document: MBZ (Must Be Zero) fields must contain zero ! on transmission and reception. MBZ fields cannot be easily ! changed in future protocol versions. RESERVED (RSV) fields ! must be zero on transmission and must be ignored on ! reception. These fields can be defined to take on new ! meaning in future implementations without effecting previous ! implementations. ! ! ! 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. ! ! INTRODUCTION Page 1-3 ! ! ! 1.1 SCA ARCHITECTURE ECO PROCESS ! ! The SCA architecture ECO process is intended to be biased against ! change. Only compelling reasons should cause incompatible differences ! between implementations, or cause existing software not to run on any ! implementation that conforms to the standard. ! ! ! ! 1.1.1 Participants In The ECO Process ! ! The participants in the SCA Architecture Review Process include the ! following people and groups: ! ! o SCA Review Group. This is the voting group comprising ! ! o the SCA architect, ! ! o and representatives of software and hardware engineering ! groups which have a Unique Implementation of SCA, ! ! o former major contributors to the specification of SCA, ! and past members of SCARG in order to maintain technical ! continuity. ! ! ! A Unique Implementation of SCA is defined as a unique body of ! software (Macro or Micro code) which implements the SCA ! Architecture. A major modification to an existing ! implementation constitutes a unique implementation, while ! minor modifications do not. ! ! The representatives are proposed from the groups by the ! managers of those groups or SCARG members. The SCARG as a ! whole decides who are voting members. A complete list of ! membership and distribution for the SCARG is available from ! the responsible SCA architect. ! ! The SCA architect manages the architecture process and ! updates the SCA specification. The SCA architect is ! appointed by the 32 Bit Systems Architecture Manager and ! reports to her/him for the purposes of this function. ! ! o The 32 Bit Systems Architecture manager who serves in the ! appeals process. ! ! o The manager of Corporate Strategy and Architecture, who ! serves in the appeals process. ! ! o Other reviewers as outlined in the section on ECO Review ! below. ! ! ! INTRODUCTION Page 1-4 ! ! ! 1.1.2 ECO Proposals ! ! Anyone, including SCARG members, or other interested parties, can ! propose ECOs. Proposing an ECO includes whatever preliminary ! investigation is necessary to achieve a sound technical proposal, ! prima facie. The rationale and known consequences must be included. ! Among these are: ! ! o Functional changes including precise textual changes to the ! specification. ! ! o The performance gain (or loss). ! ! o Any required changes to existing or planned implementations, ! for each implementation. ! ! ! The SCA architect is responsible for closure of ECOs in a timely ! manner. ! ! ! ! 1.1.3 ECO Review ! ! The following reviewers will receive the proposed ECO: ! ! o Members of the review group, called SCARG. ! ! o Others directly involved in the technical issue. ! ! o Whomever else the SCARG deems appropriate. ! ! ! The reviewers are responsible for circulating the ECO material within ! their project or organization, collecting the comments and returning ! comments to the SCA architect within the stated deadline. ! ! The SCA architect will collect the comments, tabulate the votes, and ! attempt to build a consensus based on sound judgment, not just ! expedient compromise. Individual discussions, meetings, revisions to ! the ECO, mailings and further votes may be required. ! ! ! ! 1.1.4 ECO Approval And Appeal ! ! An ECO must have the approval of the SCA Architect and the consensus ! of the SCARG. The vote must consist of at least 90 percent of the ! SCARG. A consensus consists of the approval of 75 percent of those ! not explicitly abstaining. Any strong opposition is an indication of ! no consensus. ! ! There are four ways to Vote: YES, NO, ABSTAIN and MEETING. One or ! more MEETING votes causes a meeting to be called for discussion of the ! proposal. ! ! INTRODUCTION Page 1-5 ! ! ! ECOs are voted on twice: Once as precise text changes in isolation ! from the entire specification and again when one or more ECOs are ! incorporated into the specification with all changes marked. ECOs are ! not approved until the vote is made on the entire specification with ! the changes incorporated. Implementation can begin after approval of ! the ECO in isolation and before the approval of the final document. ! ! The SCA architect's decisions can be appealed to the 32bit Systems ! Architecture manager and then to the Corporate Strategy and ! Architecture Manager. ! ! ! ! 1.1.5 ECO Publishing And Distribution ! ! Approved ECOs will be logged by the SCA architect, assigned a number ! and mailed to SCARG members, reviewers and to anyone else who should ! be informed. ! ! There is no schedule for publishing ECOs. The SCA architect will ! publish and distribute the ECOs when they are approved. Final ! distribution normally takes the form of a complete specification with ! change bars where appropriate and possible. ! ! ! ! 1.1.6 Conformance ! ! The entire conditions for the conformance are intended to be in the ! body of the SCA Specification. Wherever the standard is lacking, the ! discrepancy must be brought to the attention of the SCA architect ! before any hardware or software design or implementation decisions are ! committed. ! ! Each SCA implementation will conform to this standard unless it has ! been granted a waiver by this standard's ECO process. A waiver may ! allow an immediate shipment followed by a fix. It may require some ! instances to be fixed and not others, or it may allow a permanent ! exception from the standard. ! ! Conformance to this standard shall be tested by the following: ! ! o Correct operation with current existing implementations. ! ! o Passing an SCA certification procedure (TBS) ! 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 so that system addresses do not collide with Ethernet ! Multicast addresses. 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 characteristics, 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. 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, SYSAP-SCS INTERFACE NOTATION Page 5-3 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 } ! { space filled on } ! { the right } 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 } ! { format is SYSAP } ! { specific } ! 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 ! ! SYSAP-SCS INTERFACE Page 6-3 ! ! ! 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 } 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 } ! ! SYSAP-SCS INTERFACE Page 6-4 ! ! ! ); ! ! FSTATUS = (FAIL,SUCCESS,NULL,NOT_OPEN); { function status } 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. 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 datagram application text (in bytes) ! supported by the destination system. ! ! MAX_MSG the maximum message application text (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. ! ! SW_INCARNATION software incarnation of the destination system. ! This is initialized by the system at its boot ! time. When a PPD Virtual Circuit (VC) is ! ! SYSAP-SCS INTERFACE Page 6-6 ! ! ! 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. ! ! CHAR the characteristics of the destination system ! port. (See the appropriate port specification.) ! ! SYSAP-SCS INTERFACE Page 6-7 ! ! ! 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. 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 receipt 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. This is the ! minimum send credit for the local system and the ! minimum receive credit for the remote system. ! ! SYSAP-SCS INTERFACE Page 6-10 ! ! ! CREDITS the address of a list of message buffers that ! represent an initial credit. 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. ! 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. ! 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 list of message buffers that ! represents an initial credit. ! ! THRSH the minimum number of message buffers the ! destination process should maintain for proper ! operation of the SYSAP procotol. This is the ! minimum send credit for the local system and the ! minimum receive credit for the remote system. 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 destination minimum receive credit. The remote SCS makes the ! decision to cancel buffers based on the current state of credits at ! that end of the connection. 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. 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. In other implementations of the ! PPD layer, it may be adviseable to provide a means to cancel block ! transfers to avoid long delays in disconnecting. 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 example 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. ! 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 message 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 | +---------------+---------------+ ! | RSV | ! +---------------+---------------+ ! | SEND_CONNECT_ID | ! +---------------+---------------+ ! | RSV | 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 +---------------+---------------+ ! | RSV | SCS_TYPE | ! +---------------+---------------+ ! | REC_CONNECT_ID | ! +-------------------------------+ ! | SEND_CONNECT_ID | ! +---------------+---------------+ ! | STATUS | RSV | +---------------+---------------+ 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 | +---------------+---------------+ ! | RSV | 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. ! This is the SEND_CONNECT_ID to be used in all ! further messages on this connection. 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. ! ! SCS MESSAGES AND DATAGRAMS Page 8-6 ! ! ! SEND_DATA connect data from the sending process. ! ! SCS MESSAGES AND DATAGRAMS Page 8-7 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 +---------------+---------------+ ! | RSV | SCS_TYPE | ! +---------------+---------------+ ! | REC_CONNECT_ID | ! +-------------------------------+ ! | SEND_CONNECT_ID | ! +-------------------------------+ ! | REASON | RSV | +-------------------------------+ 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-8 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 +---------------+---------------+ ! | RSV | SCS_TYPE | ! +---------------+---------------+ ! | REC_CONNECT_ID | ! +-------------------------------+ ! | SEND_CONNECT_ID | ! +---------------+---------------+ ! | REASON | RSV | +---------------+---------------+ 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-9 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 +---------------+---------------+ ! | RSV | 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-10 8.2.7 Disconnect Request The DISCONNECT_REQ request message requests disconnection. The format of DISCONNECT_REQ is: 3 1 1 5 0 +---------------+---------------+ ! | RSV | SCS_TYPE | ! +---------------+---------------+ ! | REC_CONNECT_ID | ! +-------------------------------+ ! | SEND_CONNECT_ID | ! +---------------+---------------+ ! | REASON | RSV | +---------------+---------------+ 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-11 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 +---------------+---------------+ ! | RSV | 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-12 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-13 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-14 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-15 8.4 APPLICATION DATAGRAM The APPL_DG datagram carries a SYSAP layer datagram. The format of APPL_DG is: 3 1 1 5 0 +---------------+---------------+ ! | RSV | 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 ! versions to be upgraded in the future. 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. ! An implementation may elect not to talk down to previous versions for ! reasons of product requirements or economy. Implementations not ! electing to talk down simply close the port to port virtual circuit ! after receipt of the START or STACK message from the lowered numbered ! version. ! 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 ! ! SCS OPERATION Page 9-2 ! ! ! 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 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 When a SYSAP opens a connection (CONNECT or ACCEPT ! call), it provides a THRSH value which is stored ! in MIN_SEND_CREDIT and sent in the MINIMUM_CREDIT ! field of the CONNECT_REQ or ACCEPT_REQ message to ! the other side where it becomes ! MIN_RECEIVE_CREDIT. When a SYSAP sends a message ! via SEND_MSG, it provides a THRSH value which is ! compared with SEND_CREDIT. If SEND_CREDIT is not ! larger than THRSH, SEND_MSG fails. 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 ! in order 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 local SYSAP when it specifies the THRSH ! parameter to CONNECT or ACCEPT. 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 partner SYSAP. 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 ! ! SCS OPERATION Page 9-3 ! ! 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-4 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-5 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-6 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-7 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 } ! { } ! { The following functions are included for illustration and are not } ! { intended to specify in detail these operations. For some of these } ! { functions, return values have been included to allow the PASCAL to } ! { compile correctly. These return values are not intended to be } ! { correct in the context of a working implementation. The comments within } ! { the function body indicate the operation desired. } ! { } ! function ALLOC_CB( ! var CID:CONNECT_ID): ! boolean; ! ! ! SCS OPERATION Page 9-8 ! ! 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 } ! ALLOC_CB := true ! ! end;{ALLOC_CB} function CB_CLOSED( { test connection state } CID: CONNECT_ID): boolean; begin {return TRUE if connection is closed, return FALSE otherwise } ! CB_CLOSED := true 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 } ! PBPTR_TO_PBINDEX := 0 end;{PBPTR_TO_PBINDEX} function NEXT_XID: WORD; begin { assign a new transaction number } ! NEXT_XID := 0 ! ! end;{NEXT_XID} ! ! function CONNECT_MATCH( ! PTR: Q_BUF_PTR; ! ! SCS OPERATION Page 9-9 ! ! 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 } ! CONNECT_MATCH := TRUE ! ! end;{CONNECT_MATCH} ! ! function INSERT_CB_Q( ! Q: CB_PTR; 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 } ! INSERT_CB_Q := WAS_EMPTY 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 } ! REMOVE_CB_Q := NOW_EMPTY 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 ! ! SCS OPERATION Page 9-10 ! ! ! its address in PTR: return true if entry removed; ! false otherwise } ! REMOVE_SCS_Q := true 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} ! 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 } ! REMOVE := true ! ! end;{REMOVE} ! {SCSDEF} ! ! SCS OPERATION Page 9-11 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-12 ! ! ! DST_MAX_DG the maximum datagram application text (in bytes) ! supported by the system. ! ! DST_MAX_MSG the maximum message application text (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-13 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-14 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-15 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-16 9.7 CONNECTION MANAGEMENT SERVICE 9.7.1 Connection Block A representative connection block has the following format: ! SCS OPERATION Page 9-17 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-18 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-19 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-20 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 call, ! abort to CONNECT call ! ! CONNECT_ACK rcv REJECT_REQ send REJECT_RSP CLOSED ! rcv ACCEPT_REQ send ACCEPT_RSP OPEN ! DISCONNECT call - CLOSED ! ! CONNECT_REC ACCEPT call send ACCEPT_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 ! REJECT_SENT rcv REJECT_RSP - CLOSED ! ! DISCONNECT call SUCCESS on DISCONNECT CLOSED ! call ! SUCCESS on REJECT call ! ! OPEN DISCONNECT call send DISCONNECT_REQ DISCONNECT_SENT ! ! SCS OPERATION Page 9-21 ! ! ! rcv DISCONNECT_REQ send DISCONNECT_RSP DISCONNECT_REC ! ! DISCONNECT_SENT rcv DISCONNECT_REQ send DISCONNECT_RSP DISCONNECT_MATCH ! rcv DISCONNECT_RSP - DISCONNECT_ACK ! ! DISCONNECT_REC DISCONNECT call Send DISCONNECT_REQ DISCONNECT_MATCH ! ! DISCONNECT_ACK rcv DISCONNECT_REQ send DISCONNECT_RSP CLOSED ! ! DISCONNECT_MATCH ! rcv DISCONNECT_RSP - CLOSED ! ! DISCONNECT call SUCCESS on both CLOSED ! DISCONNECT calls ! ! ! any non-CLOSED close port/port VC - CLOSED ! ! any state receiving any close port/port VC CLOSED ! inappropriate ! message 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. ! ! If an implementation desires to disconnect in ACCEPT_SENT, ! DISCONNECT_SENT, or DISCONNECT_ACK states then it must assure that ! block transfers and other traffic are not in progress. ! ! SCS OPERATION Page 9-22 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-23 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-24 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-25 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-26 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-27 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-28 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-29 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; ! if not RET_FLAG then 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; ! ! SCS OPERATION Page 9-30 ! ! ! PTR^.SEND_CONNECT_ID:=CB$SRC_CONNECT_ID; 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. } ! ! SCS OPERATION Page 9-31 ! ! ! else if CB$REC_CREDIT <= CB$MIN_REC_CREDIT then 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-32 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-33 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-34 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-35 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} ! { The following return value is included to allow the PASCAL } ! { to compile. } ! MAP := SUCCESS ! 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; ! ! SCS OPERATION Page 9-36 ! ! ! REQDAT(CB$DST_PB,PTR); ! READ:=SUCCESS ! end ! else READ:=FAIL 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 ! ! SCS OPERATION Page 9-37 ! ! ! end;{WRITE} ! 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-38 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_SEND_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_SEND_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_SEND_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_SEND_CREDIT; ! PB$MSG_PTR^.STATUS:=0; ! PB$MSG_PTR^.REC_PROC:=PB$CB_Q^.CB$DST_PROC_NAME; ! ! SCS OPERATION Page 9-39 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-40 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-41 DO case PTR^.SCS_TYPE of { begin new case block } CONNECT_REQ: ! { Connect request recieved. Check if this connect 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-42 { 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$DST_CONNECT_ID:=PTR^.SEND_CONNECT_ID; 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; ! ! SCS OPERATION Page 9-43 ! ! ! if REMOVE_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB) <> NOW_EMPTY 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 ! ! SCS OPERATION Page 9-44 ! ! ! begin 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; ! ! SCS OPERATION Page 9-45 ! ! ! PBA[CB$DST_PB].PB$MSG_PTR:=PTR; { 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-46 ! 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.1.4 Error Log Datagram ! ! The ERROR_LOG datagram is used to inform systems that errors have ! occurred and to supply information to be logged for later analysis. ! It is primarily intended to log errors which are outside the realm of ! a particular SYSAP private protocol such as MSCP. It is expected that ! SYSAP specific errors are logged via SYSAP specific protocol messages. ! ! ! 3 1 ! 1 5 0 ! +--------+--------+--------+--------+ ! | PPD_TYPE | LENGTH | 0 ! +--------+--------+--------+--------+ ! | SEQUENCE | RESERVED | 4 ! +--------+--------+--------+--------+ ! | EVENT | FLAGS | FORMAT | 8 ! +--------+--------+--------+--------+ ! | SYSTEM | 12 ! | NAME | ! +--------+--------+--------+--------+ ! | ERROR | 20 ! = LOG = ! | TEXT | ! +--------+--------+--------+--------+ ! where: ! ! LENGTH Number of bytes in the message including the ! PPD_TYPE word. ERROR_LOG_LEN (18 minimum). ! ! PPD_TYPE ERROR_LOG (5) ! ! SEQUENCE A sequential sequence number of all error log ! datagrams sent by the sending system. No special ! action is taken when the sequence number overflows ! a word. Sequence 0 follows FFFFx. ! ! FORMAT A byte describing the format of the ERROR LOG TEXT ! field. FORMAT codes except ASCII (0) are ! implementation specific, and are reserved in this ! specification. FLAGS, EVENT and ERROR_LOG_TEXT ! field formats vary depending on the FORMAT field. ! ! FLAGS Flags describing the error or events leading the ! error. For ASCII FORMAT, FLAGS is RESERVED. For ! other values of FORMAT, FLAGS depends on the ! format. ! ! EVENT A description of the event which follows. For ! ASCII FORMAT, EVENT is RESERVED. For other values ! of FORMAT, EVENT depends on the FORMAT. ! ! SYSTEM_NAME The sending system name. ! ! CI PPD OPERATION Page 10-5 ! ! ! ERROR_LOG_TEXT For ASCII FORMAT, the text of the error log ! message. For other values of FORMAT, this field ! depends on FORMAT. This text is optional and need ! not be present if the error log can be fully ! understood based on EVENT ! ! The following FORMAT types are defined: ! ! ! ASCII (0) ERROR_LOG_TEXT contains a byte count of the text ! as the first word. The remainder of ! ERROR_LOG_TEXT is ASCII text with embedded format ! characters. ! ! HSC50_BINARY (1) The message which follows is binary data and ! should be interpreted according to the event code. ! Events and data format are defined in the HSC50 ! functional specification. ! ! These datagrams are sent only to systems with which virtual circuits ! have been established. The datagram itself does not affect any of the ! state transitions on the receiving node. ! ! This PPD type message requires PRTVRS field (protocol version, ! appendix F) to be greater or equal to one (1). ! ! Implementations are required to benignly deal with unknown FORMAT, ! EVENT and FLAGS values. No implementation is required to process ! error log datagrams. These messages can be ignored. In no case can ! the format of the message cause the port to port VC to be broken ! because the message is not understood by a receiving system. ! ! The LENGTH byte count is minimized by the sender against MAX_DG + ! AP_DG_HDR_LEN, the maximum size of an application datagram to prevent ! sending messages which are beyond the capacity of the remote system to ! receive. The ASCII byte count reflects the actual message length ! which was generated. The receiving system can detect message ! truncation in the case when the receiving port is incapable of ! receiving the entire message. ! ! CI PPD OPERATION Page 10-6 ! ! ! 10.1.5 Node Stop Datagram ! ! ! The NODE_STOP datagram is used to inform the remote PPD layer that it ! should terminate its virtual circuit to the local PPD layer. The ! format of NODE_STOP is: ! ! 3 1 ! 1 5 0 ! +----------------+----------------+ ! | PPD_TYPE | LENGTH | ! +----------------+----------------+ ! ! where: ! ! LENGTH NODE_STOP_LEN( 2 ). ! PPD_TYPE NODE_STOP( 6 ). ! ! These datagrams are sent only to systems with which virtual circuits ! have been established. The datagram causes the receiver to close the ! virtual circuit with the sending system. ! ! This datagram tells the receiver that the sender is shutting down and ! that the sender will not send further messages under the current ! software incarnation. ! ! This PPD type message requires PRTVRS field (protocol version, ! appendix F) to be equal to one (1). This message is only to be used ! for protocol version 1. It is obsolete for protocol version 2 of SCA. ! ! CI PPD OPERATION Page 10-7 ! ! 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 ! rec NODE_STOP none VC_CLOSED ! 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 ! rec NODE_STOP stop timer VC_CLOSED ! 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 ! rec NODE_STOP close port vc VC_CLOSED ! stop timer ! ! VC_OPEN rec START close port VC VC_CLOSED ! notify SCS ! rec STACK send ACK VC_OPEN ! rec ACK - VC_OPEN ! ! CI PPD OPERATION Page 10-8 ! ! ! ! rec NODE_STOP close port vc VC_CLOSED ! notify SCS ! ! VC failure notify SCS VC_CLOSED ! detected ! ! Any State Any close port vc VC_CLOSED ! Inappropriate notify SCS ! Event 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-9 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 ! ERROR_LOG = 5; { Error log datagram } ! ! NODE_STOP = 6; { Node stop datagram } ! { 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 } ! { Lengths of messages are minimum lengths not including } ! { the LENGTH word. } ! 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 = 14; CREDIT_RSP_LEN = 14; AP_MSG_HDR_LEN = 14; AP_DG_HDR_LEN = 14; ! START_LEN = 62; ! ! STACK_LEN = 62; ! ! ACK_LEN = 2; ! ! ERROR_LOG_LEN = 18; {minimum} ! ! NODE_STOP_LEN = 2; {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 } ! INSFCRED = 34; { insufficient credits have } ! { been established for this } ! { connection } {CONREJEND} APPENDIX F CI START DATA FORMAT 3 1 0 +-------------------------------+ | PPD MTYPE | LENGTH | +-------------------------------+ | SEND_SYS | +---------------+ | ! | RSV | PRTVRS| | +---------------+---------------+ | MAX_MSG | MAX_DG | +---------------+---------------+ | SW_TYPE | +-------------------------------+ | SW_VERSION | +-------------------------------+ | SW_INCARNATION | | | +-------------------------------+ | HW_TYPE | +-------------------------------+ | | = HW_VERSION = | | +-------------------------------+ | NODE_NAME | | | +-------------------------------+ | CUR_TIME | | | +-------------------------------+ ! ! CI START DATA FORMAT Page F-2 ! ! ! where: ! ! SEND_SYS the system address of the system sending the start ! data. ! ! PRTVRS protocol version (one (1) at this time). ! ! MAX_DG the maximum size (in bytes) of SYSAP_DG_TEXT field ! of an application datagram supported by the ! system. See section 8.4. ! ! MAX_MSG the maximum size (in bytes) of SYSAP_MSG_TEXT ! field of an application message supported by the ! system. See section 8.3. ! ! SW_TYPE the type of the software in the system. Currently ! defined are 'VMS ','T-10', 'T-20' and 'U-32'. ! ! SW_VERSION the version number of the software in the system. ! ! SW_INCARNATION (8 bytes) the incarnation number of the software ! in the system. This value is intended to change ! with each reboot of the system on this node. 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 ! WAIVERS ! ! ! ! ! 1. ! ! August 1985. TOPS-20 is granted a waiver to use NODE_STOP to ! stop port to port virtual circuits for reasons other than the ! situation where the node is shutting down. This waiver is in ! effect for as long as TOPS-20 uses SCA protcol version 1. ! ! ! ! ! ! ! ! ! ! ! ! ! ! APPENDIX J ! 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 J-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 J-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 J-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 J-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. ! ! Rev. 6 to Rev 7 changes ! ! 1. Add SCA Architecture ECO Process. ! ! 2. Add ERROR_LOG and NODE_STOP datagram definitions. Add ! NODE_STOP implications to start virtual circuit state table ! in section 10.7. These additions constitute protocol version ! one (1). ! ! 3. Define MBZ and RESERVED (RSV) fields. ! ! 4. Correct MAX_DG and MAX_MSG nomenclature to reflect that these ! fields are the maximum size of application text in these ! messages and do not include the size of the headers. ! ! CHANGE HISTORY Page J-6 ! ! ! 5. Correct and amplify descriptions of THRSH as a parameter and ! MIN_SEND_CREDIT as a data value both in descriptions and in ! PASCAL source. Correct SCS_SEND process to reflect ! MIN_SEND_CREDIT being set from THRSH in CONNECT and ACCEPT. ! ! 6. Reword section 6.5.5 which discusses canceling messages to ! make it clearer. ! ! 7. Reword section 6.6 to suggest that other PPD implementations ! may need to provide a PPD cancel function. ! ! 8. Reword descriptions in section 9.3 to make them clearer. ! ! 9. Add "calls" to state table in section 9.7.2 to distinguish ! DISCONNECT call from DISCONNECT state and message. Remove ! DISCONNECT calls from ACCEPT_SENT, DISCONNECT_SENT and ! DISCONNECT_ACK states. Change wording to talk about ! inappropriate messages received instead of inappropriate ! events. ! ! 10. Add ERROR_LOG and NODE_STOP message lengths, correct ACK_LEN ! value, and add description that message lengths do not ! include the length word itself. ! ! 11. Add INSF_CREDITS reason code. ! ! 12. Change zero (0) values in message formats to RSV (RESERVED) ! as per definition in section one. This provides for them to ! be send as zero and ignore on receive. ! ! 13. Add return values to PASCAL functions to fix compilation ! errors. ! ! 14. Fix spelling errors. ! ************ Number of difference sections found: 137 Number of difference records found: 963 DIFFERENCES /IGNORE=(SPACING,EXACT,BLANK_LINES)/MATCH=6/OUTPUT=DD$$:[SCA]SCA.DIF;5- DD$$:[SCA]SCA.MEM;23/CHANGE_BAR=(NONUMBER)- DD$$:[SCA]SCA_V6.MEM;1