! 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 <id indicates a maintenance state> 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:
  
          <generic facility name>$<generic service name>
  
  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 <D connect id, U connect id> 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
