Google
 

Trailing-Edge - PDP-10 Archives - BB-H311D-RM - documentation/sca-info.memos
There are 2 other files named sca-info.memos in the archive. Click here to see a list.
This file contains descriptions of the Systems Communications Architecture
protocol used to communicate over the CI hardware bus.


THIS FILE CONTAINS:

   o	The Corporate SCA Specification (SCA-CORP-SPEC.MEM)
   o	The LSG SCA Functional Specification (SCA.FUNCTIONAL-SPECIFICATION)
   o	SCA Design Specification for TOPS-20 (SCA-DESIGN.SPECIFICATION)
   o	SCA Design Notes (SCA-DESIGN-NOTES.TXT)
   o	More Design Notes (NEW-SCA-DESIGN-NOTES.TXT)
   o	Description of the SCS JSYS (SCS-JSYS.MEM)
   o	SCA Table Descriptions (SCA-TABLES.TXT)
   o	SCA Tester Description (SCSTST.MEM)

-------------------
   SYSTEMS COMMUNICATIONS ARCHITECTURE - DEC COMPANY CONFIDENTIAL  Page 1



   File:   SCA.MEM

   Date:    29-March-1983

   Author: William Strecker


   Abstract:

   This document describes a  communications  architecture  for  building
   clusters   of   computer   systems.   Included  are  message  formats,
   protocols, and implementation independent interface models.


   Revision:       Description     Author          Date

      0            Outline         Strecker        08-Dec-80

      1            Definitions     Strecker        09-Jan-81
                   in PASCAL

      2            Public Review   Strecker        09-Feb-81

      3            Path Blocks,    H. Levy         10-Dec-81
                   Disconnect, 
                   and Updates

      4            Disconnect      H. Levy         20-Jul-82
                   Changes

      5            Updates         Darrell Duffy    5-Oct-82

      6            Minor Updates   Darrell Duffy   29-Mar-83
   SYSTEMS COMMUNICATIONS ARCHITECTURE - DEC COMPANY CONFIDENTIAL  Page 2


   CHAPTER 1       INTRODUCTION


   CHAPTER 2       SCA TOPOLOGICAL NOTATION

           2.1     NETWORK  . . . . . . . . . . . . . . . . . . . . . 2-1
           2.2     SCA CLUSTER  . . . . . . . . . . . . . . . . . . . 2-1
           2.3     COMMMUNICATIONS SERVICE  . . . . . . . . . . . . . 2-1
           2.4     SYSTEM ADDRESS . . . . . . . . . . . . . . . . . . 2-1
           2.5     PORT . . . . . . . . . . . . . . . . . . . . . . . 2-1
           2.6     PORT DRIVER  . . . . . . . . . . . . . . . . . . . 2-2
           2.7     INTERCONNECT . . . . . . . . . . . . . . . . . . . 2-2
           2.8     POINT-TO-POINT INTERCONNECT  . . . . . . . . . . . 2-2
           2.9     MULTIACCESS INTERCONNECT . . . . . . . . . . . . . 2-2
           2.10    PORT ADDRESS . . . . . . . . . . . . . . . . . . . 2-2


   CHAPTER 3       SCA TOPOLOGY


   CHAPTER 4       SCA LAYERING


   CHAPTER 5       SYSAP-SCS INTERFACE NOTATION

           5.1     PROCESS  . . . . . . . . . . . . . . . . . . . . . 5-1
           5.2     PROCESS NAME . . . . . . . . . . . . . . . . . . . 5-1
           5.3     DIRECTORY  . . . . . . . . . . . . . . . . . . . . 5-1
           5.4     SYSTEM LIST  . . . . . . . . . . . . . . . . . . . 5-1
           5.5     SYSTEM BLOCK . . . . . . . . . . . . . . . . . . . 5-1
           5.6     PATH BLOCK . . . . . . . . . . . . . . . . . . . . 5-1
           5.7     CONNECTION . . . . . . . . . . . . . . . . . . . . 5-2
           5.8     CONNECTION BLOCK . . . . . . . . . . . . . . . . . 5-2
           5.9     CONNECT ID . . . . . . . . . . . . . . . . . . . . 5-2
           5.10    DATAGRAM COMMUNICATION SERVICE . . . . . . . . . . 5-2
           5.11    DATAGRAM BUFFER  . . . . . . . . . . . . . . . . . 5-2
           5.12    SEQUENTIAL MESSAGE COMMUNICATIONS SERVICE  . . . . 5-2
           5.13    MESSAGE BUFFER . . . . . . . . . . . . . . . . . . 5-3
           5.14    QUEUED BUFFER  . . . . . . . . . . . . . . . . . . 5-3
           5.15    BLOCK DATA COMMUNICATIONS SERVICE  . . . . . . . . 5-3
           5.16    NAMED BUFFER . . . . . . . . . . . . . . . . . . . 5-3
           5.17    FLOW CONTROL . . . . . . . . . . . . . . . . . . . 5-3
           5.18    CREDIT . . . . . . . . . . . . . . . . . . . . . . 5-3


   CHAPTER 6       SYSAP-SCS INTERFACE

           6.1     TYPE DEFINITIONS . . . . . . . . . . . . . . . . . 6-2
           6.2     CONFIGURATION SERVICES . . . . . . . . . . . . . . 6-5
           6.2.1     System Configuration . . . . . . . . . . . . . . 6-5
           6.2.2     Path Configuration . . . . . . . . . . . . . . . 6-6
           6.3     CONNECTION MANAGEMENT SERVICE  . . . . . . . . . . 6-8
           6.3.1     Connect  . . . . . . . . . . . . . . . . . . . . 6-9
           6.3.2     Listen . . . . . . . . . . . . . . . . . . . .  6-10
           6.3.3     Accept . . . . . . . . . . . . . . . . . . . .  6-11
   SYSTEMS COMMUNICATIONS ARCHITECTURE - DEC COMPANY CONFIDENTIAL  Page 3


           6.3.4     Reject . . . . . . . . . . . . . . . . . . . .  6-11
           6.3.5     Disconnect . . . . . . . . . . . . . . . . . .  6-12
           6.3.6     Connect State Poll . . . . . . . . . . . . . .  6-13
           6.4     DATAGRAM SERVICE . . . . . . . . . . . . . . . .  6-14
           6.4.1     Send Datagram  . . . . . . . . . . . . . . . .  6-14
           6.4.2     Send Datagram Poll . . . . . . . . . . . . . .  6-15
           6.4.3     Receive Datagram . . . . . . . . . . . . . . .  6-15
           6.4.4     Receive Datagram Poll  . . . . . . . . . . . .  6-16
           6.4.5     Cancel Receive Datagram  . . . . . . . . . . .  6-16
           6.5     SEQUENTIAL MESSAGE SERVICE . . . . . . . . . . .  6-17
           6.5.1     Send Message . . . . . . . . . . . . . . . . .  6-18
           6.5.2     Send Message Poll  . . . . . . . . . . . . . .  6-18
           6.5.3     Receive Message  . . . . . . . . . . . . . . .  6-19
           6.5.4     Receive Message Poll . . . . . . . . . . . . .  6-19
           6.5.5     Cancel Receive Message . . . . . . . . . . . .  6-20
           6.5.6     Cancel Receive Message Poll  . . . . . . . . .  6-20
           6.6     BLOCK DATA SERVICE . . . . . . . . . . . . . . .  6-21
           6.6.1     Map Buffer . . . . . . . . . . . . . . . . . .  6-21
           6.6.2     Unmap Buffer . . . . . . . . . . . . . . . . .  6-22
           6.6.3     Read . . . . . . . . . . . . . . . . . . . . .  6-22
           6.6.4     Read Poll  . . . . . . . . . . . . . . . . . .  6-23
           6.6.5     Write  . . . . . . . . . . . . . . . . . . . .  6-24
           6.6.6     Write Poll . . . . . . . . . . . . . . . . . .  6-25


   CHAPTER 7       SCS-PPD INTERFACE

           7.1     DATAGRAM SERVICE . . . . . . . . . . . . . . . . . 7-1
           7.1.1     Send Datagram  . . . . . . . . . . . . . . . . . 7-1
           7.1.2     Receive Datagram . . . . . . . . . . . . . . . . 7-2
           7.1.3     Return Datagram Buffer . . . . . . . . . . . . . 7-2
           7.2     VIRTUAL CIRCUIT SERVICE  . . . . . . . . . . . . . 7-3
           7.2.1     Start Virtual Circuit  . . . . . . . . . . . . . 7-3
           7.3     MESSAGE SERVICE  . . . . . . . . . . . . . . . . . 7-4
           7.3.1     Send Message . . . . . . . . . . . . . . . . . . 7-4
           7.3.2     Receive Message  . . . . . . . . . . . . . . . . 7-4
           7.3.3     Return Message Buffer  . . . . . . . . . . . . . 7-4
           7.4     BLOCK DATA SERVICE . . . . . . . . . . . . . . . . 7-5
           7.4.1     Send Data  . . . . . . . . . . . . . . . . . . . 7-5
           7.4.2     Request Data . . . . . . . . . . . . . . . . . . 7-6
           7.5     RESPONSES  . . . . . . . . . . . . . . . . . . . . 7-7


   CHAPTER 8       SCS MESSAGES AND DATAGRAMS

           8.1     TYPES  . . . . . . . . . . . . . . . . . . . . . . 8-1
           8.2     SCS CONTROL MESSAGES . . . . . . . . . . . . . . . 8-3
           8.2.1     Connect Request  . . . . . . . . . . . . . . . . 8-3
           8.2.2     Connect Response . . . . . . . . . . . . . . . . 8-4
           8.2.3     Accept Request . . . . . . . . . . . . . . . . . 8-5
           8.2.4     Accept Response  . . . . . . . . . . . . . . . . 8-6
           8.2.5     Reject Request . . . . . . . . . . . . . . . . . 8-7
           8.2.6     Reject Response  . . . . . . . . . . . . . . . . 8-8
           8.2.7     Disconnect Request . . . . . . . . . . . . . . . 8-9
           8.2.8     Disconnect Response  . . . . . . . . . . . . .  8-10
   SYSTEMS COMMUNICATIONS ARCHITECTURE - DEC COMPANY CONFIDENTIAL  Page 4


           8.2.9     Credit Request . . . . . . . . . . . . . . . .  8-11
           8.2.10    Credit Response  . . . . . . . . . . . . . . .  8-12
           8.3     APPLICATION MESSAGE  . . . . . . . . . . . . . .  8-13
           8.4     APPLICATION DATAGRAM . . . . . . . . . . . . . .  8-14


   CHAPTER 9       SCS OPERATION

           9.1     RELATION TO PPD VIRTUAL CIRCUIT  . . . . . . . . . 9-1
           9.2     SCS PROTOCOL VERSION RESOLUTION  . . . . . . . . . 9-1
           9.3     SCS CONTROL MESSAGE FLOW CONTROL . . . . . . . . . 9-1
           9.4     SCS OPERATION DESCRIPTION  . . . . . . . . . . . . 9-3
           9.5     TYPE, VARIABLE , FUNCTION, AND PROCEDURE 
                   DEFINITIONS  . . . . . . . . . . . . . . . . . . . 9-5
           9.6     CONFIGURATION SERVICE  . . . . . . . . . . . . .  9-10
           9.6.1     System Block . . . . . . . . . . . . . . . . .  9-10
           9.6.2     Path Block . . . . . . . . . . . . . . . . . .  9-12
           9.6.3     Configuration Services . . . . . . . . . . . .  9-13
           9.7     CONNECTION MANAGEMENT SERVICE  . . . . . . . . .  9-15
           9.7.1     Connection Block . . . . . . . . . . . . . . .  9-15
           9.7.2     Connection States  . . . . . . . . . . . . . .  9-19
           9.7.3     Connect  . . . . . . . . . . . . . . . . . . .  9-21
           9.7.4     Listen . . . . . . . . . . . . . . . . . . . .  9-22
           9.7.5     Accept . . . . . . . . . . . . . . . . . . . .  9-22
           9.7.6     Reject . . . . . . . . . . . . . . . . . . . .  9-23
           9.7.7     Disconnect . . . . . . . . . . . . . . . . . .  9-23
           9.7.8     State Poll . . . . . . . . . . . . . . . . . .  9-24
           9.8     DATAGRAM SERVICE . . . . . . . . . . . . . . . .  9-25
           9.8.1     Send Datagram  . . . . . . . . . . . . . . . .  9-25
           9.8.2     Send Datagram Poll . . . . . . . . . . . . . .  9-25
           9.8.3     Receive Datagram . . . . . . . . . . . . . . .  9-26
           9.8.4     Receive Datagram Poll  . . . . . . . . . . . .  9-26
           9.8.5     Cancel Receive Datagram  . . . . . . . . . . .  9-27
           9.9     SEQUENTIAL MESSAGE SERVICE . . . . . . . . . . .  9-28
           9.9.1     Send Message . . . . . . . . . . . . . . . . .  9-28
           9.9.2     Send Message Poll  . . . . . . . . . . . . . .  9-29
           9.9.3     Receive Message  . . . . . . . . . . . . . . .  9-29
           9.9.4     Receive Message Poll . . . . . . . . . . . . .  9-30
           9.9.5     Cancel Receive Message . . . . . . . . . . . .  9-31
           9.9.6     Cancel Receive Message Poll  . . . . . . . . .  9-31
           9.10    BLOCK DATA SERVICE . . . . . . . . . . . . . . .  9-33
           9.10.1    Buffer Descriptor Table  . . . . . . . . . . .  9-33
           9.10.2    Map Buffer . . . . . . . . . . . . . . . . . .  9-34
           9.10.3    Unmap Buffer . . . . . . . . . . . . . . . . .  9-34
           9.10.4    Read . . . . . . . . . . . . . . . . . . . . .  9-34
           9.10.5    Read Poll  . . . . . . . . . . . . . . . . . .  9-35
           9.10.6    Write  . . . . . . . . . . . . . . . . . . . .  9-35
           9.10.7    Write Poll . . . . . . . . . . . . . . . . . .  9-36
           9.11    SCS SEND . . . . . . . . . . . . . . . . . . . .  9-37
           9.12    SCS RECEIVE  . . . . . . . . . . . . . . . . . .  9-39


   CHAPTER 10      CI PPD OPERATION

           10.1    PPD DATAGRAMS  . . . . . . . . . . . . . . . . .  10-1
   SYSTEMS COMMUNICATIONS ARCHITECTURE - DEC COMPANY CONFIDENTIAL  Page 5


           10.1.1    Start  . . . . . . . . . . . . . . . . . . . .  10-1
           10.1.2    Start Acknowledge  . . . . . . . . . . . . . .  10-2
           10.1.3    Acknowledge  . . . . . . . . . . . . . . . . .  10-3
           10.2    START VIRTUAL CIRCUIT  . . . . . . . . . . . . .  10-4
           10.3    CONFIGURATION  . . . . . . . . . . . . . . . . .  10-6
           10.4    OTHER PPD INTERFACE FUNCTIONS  . . . . . . . . .  10-6


   CHAPTER 11      NI PPD OPERATION


   CHAPTER 12      BI PPD OPERATION


   APPENDIX A      PROCESS NAMING


   APPENDIX B      DIRECTORY SERVICE

           B.1     INTRODUCTION . . . . . . . . . . . . . . . . . . . B-1
           B.2     LOCAL DIRECTORY MANAGEMENT . . . . . . . . . . . . B-1
           B.2.1     Enter  . . . . . . . . . . . . . . . . . . . . . B-1
           B.2.2     Delete . . . . . . . . . . . . . . . . . . . . . B-2
           B.3     REMOTE DIRECTORY ACCESS  . . . . . . . . . . . . . B-2
           B.3.1     Lookup Request . . . . . . . . . . . . . . . . . B-3
           B.3.2     Lookup Response  . . . . . . . . . . . . . . . . B-4


   APPENDIX C      THIRD PARTY I/O


   APPENDIX D      SCS/PPD TYPE AND LENGTH CODES


   APPENDIX E      REJECTION AND DISCONNECTION REASON CODES


   APPENDIX F      CI START DATA FORMAT


   APPENDIX G      EXAMPLE CI MESSAGE


   APPENDIX H      MINIMAL SUPPORT


   APPENDIX I      CHANGE HISTORY











                                 CHAPTER 1

                                INTRODUCTION



   This document describes the Systems Communications Architecture (SCA).
   SCA  should  be  contrasted with a network communications architecture
   (e.g.   DECNET/DNA).   SCA  is  intended  to  be  useful  as  an   I/O
   architecture  in  the  traditional  sense:   it  is optimized for high
   performance.  This high performance is  achieved  by  restricting  the
   topologies,   by  specializing  the  function  of  the  communications
   services, and by assuming  that  communicating  processes  are  highly
   trustworthy.   A  network communications architecture, in contrast, is
   designed to support varied topologies, more generalized  communication
   services, and less trustworthy communicating processes.
|  
|  This document describes  an  architecture  and  is  not  a  functional
|  specification  for an implementation.  An architecture document can be
|  contrasted with a functional specification in several ways:
|  
|        o  The descriptions of  the  interfaces  (calls)  and  the  data
|           structures  are general and need not be adhered to exactly in
|           an implementation.   They  werve  to  specifiy  the  services
|           present but need not restrict additional services provided.
|  
|        o  An architecture provides a model of an implementation through
|           which  it describes the algorithms used in am implementation.
|           It is the algorithms that are important and not  the  details
|           of   the   data   passing   and   synchronization   that   an
|           implementation uses to embody those algorithms.
|  
|           Polling is used as the model of synchronization here  because
|           it  is  simple  to  describe  and  because  it requires fewer
|           interface calls.  To describe a model using polling  requires
|           only calls to lower layers and not calls from lower layers to
|           higher layers.
|  
|           The algorithms are important in so far as their  results  are
|           visible  at  interfaces  and in the protocol.  It may be that
|           implementations can modify the  algorithms  and  achieve  the
|           same result.
|  
|        o  Descriptions of protocol messages are exact and  their  order
|           is  important.   These  serve to allow all implementations of
|           the architecture to communicate.
   INTRODUCTION                                                  Page 1-2


   The current revision of  this  document  is  focused  on  clusters  of
   systems  interconnected  with  the  CI.   Later revisions will include
   additional information on the relation of SCA to the NI and BI.











                                 CHAPTER 2

                          SCA TOPOLOGICAL NOTATION



   2.1  NETWORK

   A set of interconnected  systems  that  communicate  using  a  network
   communications service (e.g.  DECNET/DNA NSP).
|  
|  
|  
|  2.2  SCA CLUSTER
|  
   A set of interconnected systems that  communicate  using  the  Systems
   Communications  Services  (SCS).  The systems in a cluster are managed
   by a single system manager and lie within a single security boundary.



   2.3  COMMMUNICATIONS SERVICE

   A module or process that provides a set of communications services  to
   a user.



   2.4  SYSTEM ADDRESS

   The 48-bit address  of  a  system  in  a  cluster  or  network.   More
   specifically,  it  is  the address of a network communications service
   and/or an SCS.  Not all systems necessarily  contain  both  a  network
   communications   service   and  an  SCS.   The  system  addresses  are
   necessarily unique within the cluster or network  and  are  preferably
   globally  unique.   System  addresses  with  bit 47 equal to 1 are not
   allowed.  System address 0 is not allowed.



   2.5  PORT

   The interface between an interconnect and the physical processor  that
   implements network communications services and/or SCS.
   SCA TOPOLOGICAL NOTATION                                      Page 2-2


   2.6  PORT DRIVER

   The software that controls a port.



   2.7  INTERCONNECT

   A physical communications path between ports.



   2.8  POINT-TO-POINT INTERCONNECT

   An interconnect joining two ports.



   2.9  MULTIACCESS INTERCONNECT

   An  interconnect   joining   multiple   ports   that   allows   direct
   communication   between   all  port  pairs.   An  n  port  multiaccess
   interconnect  is  logically  equivalent  to  n(n-1)/2   point-to-point
   interconnects.    The  CI  (Computer  Interconnect)  and  NI  (Network
   Interconnect) are multiaccess interconnects.
|  
|  
|  
|  2.10  PORT ADDRESS
|  
|  The 48 bit address of a port on a multiaccess interconnect.  The  port
|  address may or may not be related to the system address.  For example,
|  the 48-bit NI port address is  normally  the  system  address  of  the
|  system it interfaces.











                                 CHAPTER 3

                                SCA TOPOLOGY



   The basic topology supported by SCA is a fully, directly connected set
   of systems.  This can be realized either by a multiaccess interconnect
   or an equivalent set of point-to-point interconnects.  The purpose  of
   this restricted support is to eliminate the complexity of routing from
   SCA.  The multiaccess CI is the current focus for SCA:


                                                   CI
           --------+---------------+---------------+--------
                   |               |               |
                   |               |               |
             +-----+-----+   +-----+-----+   +-----+-----+
             |   system  |...|   system  |...|   system  | 
             +-----------+   +-----------+   +-----------+


   Note that the redundant dual path CI is logically a single CI.

   In large clusters a single CI may have inadequate bandwidth.  In  this
   case the acceptable topology is paralleled CI's:




                                           CI
           -----------+---------------+---------------+-----
                      |               |               |
                      |               |    CI         |                    
           --------+---------------+---------------+--------
                   |  |            |  |            |  |
                   |  |            |  |            |  |
             +-----+--+--+   +-----+--+--+   +-----+--+--+
             |   system  |...|   system  |...|   system  |
             +-----------+   +-----------+   +-----------+



   This topology retains the fully interconnected property.
   SCA TOPOLOGY                                                  Page 3-2


   Non-fully connected systems may be interconnected using multiple CI's.
   An  example  would  be several CPU's sharing file storage systems on a
   common CI but with private paging systems on private CI's:


                                   Common CI
           --------+-----------------+-----------------+--------
                   |                 |                 |
                   |                 |                 |
             +-----+------+    +-----+-----+    +------+-----+
             |  system X  |... |   system  |... |   system Y |
             +-----+------+    +-----------+    +------+-----+
                   |                                   |
           pvt     |                                   |    pvt
           CI      |                                   |    CI
                   |                                   |
                   |                                   |
             +-----+-----+                      +------+-----+
             |   system  |                      |  system Z  |
             +-----------+                      +------------+



   In this topology system X cannot communicate with system Z using  SCS.
   If  the services provided by system Z are to be available to system X,
   an intercept process (not part of SCA) must be provided in system Y.











                                 CHAPTER 4

                                SCA LAYERING



   SCA is described as a multilayer communications architecture.  Layer 0
   is  the  Physical  Interconnect (PI) layer (e.g., the CI).  Layer 1 is
   the Port/Port (PPD) Driver layer, which  controls  the  PI  layer  and
   provides  reliable,  sequential transfers of data between ports on the
   PI.  (In the case of the CI, most of the PPD layer is  implemented  by
   the  CI  port.)  Layer  2  is the Systems Communication Services (SCS)
   layer, which provides the process and  system  addressing,  connection
   management, and flow control necessary to multiplex the basic PPD data
   services among multiple users.  Layer 3  is  the  System  Applications
   (SYSAP) layer, which represents the users of SCS.
                      
                      
                      3.   System Applications (SYSAP)

                   -------------------------------------

                      2.   Systems Communications
                           Services (SCS)

                   -------------------------------------

                      1.   Port/Port Driver (PPD)

                   -------------------------------------

                      0.   Physical Interconnect (PI)

                   

   By analogy to DECNET/DNA  the  SCA  SYSAP  layer  corresponds  to  the
   DECNET/DNA Network Applications layer, SCS to NSP, and PPD to DDCMP.











                                 CHAPTER 5

                        SYSAP-SCS INTERFACE NOTATION



   5.1  PROCESS

   A communicating entity that uses SCS:  i.e., a SYSAP.



   5.2  PROCESS NAME

   A 16-byte string that identifies a SYSAP process within a system.  See
   Appendix A.



   5.3  DIRECTORY

   A list of SYSAP process names that exist in a system.  See Appendix B.



   5.4  SYSTEM LIST

   A data structure that contains information on systems  in  a  cluster.
   Included  are  system chracteristics, system port characteristics, and
   the state of port-to-port communications with the systems.



   5.5  SYSTEM BLOCK

   A data structure on the system list that describes the characteristics
   of a system in a cluster.



   5.6  PATH BLOCK

   A data structure on the system list that describes the characteristics
   of a particular interconnect used for port-to-port communications to a
   specific system in a cluster.
   SYSAP-SCS INTERFACE NOTATION                                  Page 5-2


   5.7  CONNECTION

   The synchronization of two connection blocks in the same or  different
   systems  to define a logical communications path between processes.  A
   process may participate in more than one connection at a time.



   5.8  CONNECTION BLOCK

   A data structure that contains the state of a connection.



   5.9  CONNECT ID

   The 32-bit identifier of a connection block within a system.  This  is
   normally  treated  as a 16-bit connection number and a 16-bit sequence
   number.
|  
|  
|  
|  5.10  DATAGRAM COMMUNICATION SERVICE
|  
|  The transmission of an independent information unit (datagram) over  a
|  connection.   Delivery  of  the datagram occurs with high probability,
|  but is not guaranteed.  Also, the order of delivery of a  sequence  of
|  datagrams is not guaranteed.



   5.11  DATAGRAM BUFFER

   A buffer that contains (or can contain) a datagram.  In SCA a datagram
   buffer  appears  in  layers  1,  2,  and  3.  To avoid copying between
   layers, a datagram buffer is defined large enough to support layer  1,
   2,  and  3  data.   Layer  3  ignores the layer 1 and 2 data;  layer 2
   ignores the layer 1 data.
|  
|  
|  
|  5.12  SEQUENTIAL MESSAGE COMMUNICATIONS SERVICE
|  
|  The transmission  of  a  sequence  of  independent  information  units
|  (messages)  over  a connection.  The messages are guaranteed to arrive
|  in the order they were sent (without loss or duplication) or an  error
|  condition is indicated to the sender.
   SYSAP-SCS INTERFACE NOTATION                                  Page 5-3


   5.13  MESSAGE BUFFER

   A buffer that contains (or can contain) a message.  A  message  buffer
   is  also  used  to  contain  control  information  for  the block data
   communications service.  In SCA a message buffer appears in layers  1,
   2,  and  3.   To  avoid  copying  between  layers, a message buffer is
   defined large enough to support layer 1,  2,  and  3  data.   Layer  3
   ignores the layer 1 and 2 data;  Layer 2 ignores the layer l data.



   5.14  QUEUED BUFFER

   Either a datagram or a message buffer.
|  
|  
|  
|  5.15  BLOCK DATA COMMUNICATIONS SERVICE
|  
|  The direct transmission of information (block data)  between  a  named
|  local  buffer  and a named destination buffer.  The transmission takes
|  place over a connection between the system containing the local  named
|  buffer  and  the  system containing the destination named buffer.  The
|  block data is guaranteed to arrive completely or an error condition is
|  indicated to the sender.



   5.16  NAMED BUFFER

   A named memory buffer used by the block data service.  A  buffer  name
   is  a 32-bit value.  A buffer is considered byte addressable with each
   byte specified by a 32-bit unsigned offset from the beginning (byte 0)
   of the buffer.



   5.17  FLOW CONTROL

   The method by which the rate of information flow from  the  sender  to
   the  receiver  is controlled.  In SCS there is no flow control applied
   to the datagram service.  For the sequential message  and  block  data
   services,  flow is controlled by a credit-based protocol that inhibits
   a sender from sending information (messages, block  data  control,  or
   block  data)  until  the receiver has provided a buffer to receive the
   information.



   5.18  CREDIT

   A logical token held by  a  sending  process  that  indicates  that  a
   receiving process has queued a message buffer to (1) receive a message
   or (2) permit a block data operation.











                                 CHAPTER 6

                            SYSAP-SCS INTERFACE



   The SCS interface  is  modelled  as  a  set  of  PASCAL  functions  or
   procedures of the form:

           function FUNCTIONNAME ([var] ARGUMENTNAME:TYPE
           [;[var]ARGUMENTNAME:TYPE]...):FUNCTIONSTATUS;

   or              
           procedure PROCEDURENAME([var]ARGUMENTNAME:TYPE
           [;[var]ARGUMENTNAME:TYPE]...);



   where:

   [] - indicates optional.

   var - indicates an output argument.

   FUNCTIONNAME - the name of the function.

   PROCEDURENAME - the name of the procedure.

   ARGUMENTNAME - the name of the argument.

   TYPE - the type of the argument.

   ...  - indicates replication.

   FUNCTIONSTATUS - the status of function execution.
   SYSAP-SCS INTERFACE                                           Page 6-2


   6.1  TYPE DEFINITIONS

   The following PASCAL  type  definitions  apply  to  the  function  and
   procedure arguments:

|  type    BYTE = -128..127;
|          
|          WORD = -32768..32767;
|          
|          LONG = {32-bit} integer;
|          
|          QUAD = packed array [1..8] of BYTE;
|  
|          SEPTA = packed array [1..12] of BYTE;
|  
|          OCTA = packed array [1..16] of BYTE;
|  
|          SYSTEM = packed array [1..6] of BYTE;           { system address }
|          
|          PORT = packed array [1..6] of BYTE;             { port address }
|          
|          PROC_NAME = packed array [1..16] of BYTE;       { process name }
|          
|          CONNECT_ID = record                             { connect id } 
|                  INDEX: WORD;
|                  SEQ: WORD
|                  end;
|          
|          SB_INDEX = WORD;                                { system block index }
|  
|          PB_INDEX = WORD;                                { path block index }
|  
|          C_DATA = packed array [1..16] of BYTE;          { connect data }
|          
|          APPL_MSG_LEN = 0..MAX_APPL_MSG;                 { SYSAP message length }
|          
|          APPL_DG_LEN = 0..MAX_APPL_DG;                   { SYSAP datagram length } 
|          
|          BUF_USE = (BLK_ARG,MSG_DG);                     { variant record selector }
|          
|          MSGDG = (MSG,DG);                               { variant record selector }
|  
|          MSG_USE = (CONTROL,APPL);                       { variant record selector }
|          
|          Q_BUF_PTR = ^Q_BUFFER;                          { address of a queued buffer }
|  
|          Q_BUFFER = record                               { queued command buffer for message, datagram, or block transfer }
|                  NEXT: Q_BUF_PTR;                        { next buffer in queue }
|                  { PPD layer data }
|                  case BUF_USE of
|  
|                  BLK_ARG:(                               { block data command }
|                          SEND_BLOCK_ID: WORD;            { connection block index for the transfer }
|                          SEND_XID: WORD;                 { transaction number }
|                          DATA_LENGTH: LONG;              { number of bytes to be transferred }
   SYSAP-SCS INTERFACE                                           Page 6-3


|                          SEND_NAME: LONG;                { buffer name of source buffer }
|                          SEND_OFFSET: LONG;              { starting byte in source buffer }
|                          REC_NAME: LONG;                 { buffer name of destination buffer }
|                          REC_OFFSET: LONG);              { starting byte in destination buffer }
|  
|                  MSG_DG:(                                { message or datagram command }
|                          LENGTH: WORD;                   { length in bytes of following fields }
|                          PPD_TYPE: WORD;                 { PPD message type code }
|                          SCS_TYPE: WORD;                 { SCS message type code }
|                          CREDIT: WORD;                   { number of credits to extend }
|                          REC_CONNECT_ID: CONNECT_ID;     { destination connect ID }
|                          SEND_CONNECT_ID: CONNECT_ID;    { source connect ID }
|                          case MSGDG of
|  
|                          DG:(                            { if Datagram, just include application info. }
|                                  DG_TEXT: packed array [1..MAX_APPL_DG]
|                                  of BYTE);
|  
|                          MSG:(                           { if Message ... }
|                                  case MSG_USE of
|  
|                                  CONTROL:(               { ... and this is SCS control message, then ... }
|                                          MIN_CREDIT: WORD;       { credit extended }
|                                          STATUS: WORD;           { reason for accept/reject }
|                                          REC_PROC: PROC_NAME;    { destination process name }
|                                          SEND_PROC: PROC_NAME;   { source process name }
|                                          SEND_DATA: C_DATA);     { connect data }
|  
|                                  APPL:(                  { ... else SYSAP message, so just include SYSAP stuff. }
|                                          MSG_TEXT: packed array
|                                          [1..MAX_APPL_MSG] of BYTE)))
|                  end;
|                                  
|          
|          { BUF_DESCR = implementation specific named buffer descriptor }
|  
|          
|  
|          C_STATE = (                             { process-to-process connection state }
|                  CLOSED,                         { connection is closed by command }
|                  LISTENING,                      { listening for connection request }
|                  CONNECT_SENT,                   { connect request was transmitted }
|                  CONNECT_REC,                    { connect request was received }
|                  CONNECT_ACK,                    { connect response was received }
|                  OPEN,                           { connection is open }
|                  ACCEPT_SENT,                    { accept request was sent }
|                  REJECT_SENT,                    { reject request was sent }
|                  DISCONNECT_SENT,                { disconnect message was transmitted }
|                  DISCONNECT_REC,                 { disconnect message was received }
|                  DISCONNECT_ACK,                 { response received, waiting for remote disconnect }
|                  DISCONNECT_MATCH                { waiting for matching response confirmation }  
|                  );
|  
|          FSTATUS = (FAIL,SUCCESS,NULL,NOT_OPEN); { function status }
|  
   SYSAP-SCS INTERFACE                                           Page 6-4


|          PORT_CHAR = packed array [1..16] of BYTE; { see appropriate port specification }
|  
|          VC_STATE = (                            { port-to-port virtual circuit state }
|                  MAINT,                          { maintenance state }
|                  VC_CLOSED,                      { virtual circuit closed }
|                  START_SENT,                     { start sequence initiated }
|                  START_REC,                      { start sequence received }
|                  VC_OPEN                         { virtual circuit is open }
|                  ); { virtual circuit state }{SYSAPDEF}
   SYSAP-SCS INTERFACE                                           Page 6-5


   6.2  CONFIGURATION SERVICES

   The configuration services allow the caller to determine the  identity
   of  the  connected  systems and the number of paths to each system.  A
   system block is read by calling CONFIG_SYS.  The system block contains
   information   on   a   remote   system,   its  hardware  and  software
   characteristics, and the number of connecting paths.  A path block  is
   read   by   calling   CONFIG_PATH.    The  path  block  contains  port
   characteristics and the state of port  to  port  communications.   The
   REQ_ID  procedure  updates  the  port  characteristics field of a path
   block.



   6.2.1  System Configuration

   This function reads a system block:

|  function CONFIG_SYS(
|          ENTRY: SB_INDEX;
|          var FIRST_PB: PB_INDEX;
|          var SYS: SYSTEM;
|          var MAX_DG: WORD;
|          var MAX_MSG: WORD;
|          var SW_TYPE: LONG;
|          var SW_VERSION: LONG;
|          var SW_INCARNATION: QUAD;
|          var HW_TYPE: LONG;
|          var HW_VERSION: SEPTA;
|          var NODE_NAME: QUAD;
|          var PORT_COUNT: WORD):
|          FSTATUS;
   where:

       ENTRY           the system list entry:  entries start at one.

       FIRST_PB        the path block index of  the  first  path  to  the
                       destination system.

       SYS             the destination system address.

       MAX_DG          the maximum size datagram (in bytes) supported  by
                       the destination system.

       MAX_MSG         the maximum size message (in bytes)  supported  by
                       the destination system.

       SW_TYPE         4-character ASCII software type of the destination
                       system.

       SW_VERSION      4-character  ASCII   software   version   of   the
                       destination system.
   SYSAP-SCS INTERFACE                                           Page 6-6


|      SW_INCARNATION  software incarnation of  the  destination  system.
|                      This  is  initialized  by  the  system at its boot
|                      time.  When  a  ppd  vc  is  established  and  the
|                      SW_INCARNATION  changes  from a previous value, it
|                      indicates that all of the  system  software  state
|                      has been lost.

       HW_TYPE         the hardware type of the destination system.

       HW_VERSION      the hardware version of the destination system.

       NODE_NAME       the 8-byte ASCII  node  name  of  the  destination
                       system.

       PORT_COUNT      the number of ports to the destination system.

       FSTATUS         SUCCESS if entry is valid;  FAIL otherwise.



   6.2.2  Path Configuration

   This function reads a path block.  The path block index for the  first
   path  block  to  a  destination  system is determined by first calling
   CONFIG_SYS for that system.  Successive calls to  CONFIG_PATH  can  be
   made to scan the list of path blocks for a particular system.

   function CONFIG_PATH(
           ENTRY: PB_INDEX;
           var STATE: VC_STATE;
           var PRT: PORT;
           var NEXT_PB: PB_INDEX;
           var SB: SB_INDEX;
           var CHAR: PORT_CHAR):
           FSTATUS;

   where:

       ENTRY           the index of the path block to be examined;   path
                       block indices start at one.

       STATE           the  virtual  circuit  state  to  the  destination
                       system   over   this   path.   (MAINT,  VC_CLOSED,
                       START_SENT, START_REC, VC_OPEN)

       PRT             the destination system port address.

       NEXT_PB         the path block index of  the  next  path  to  this
                       system, or zero if this is the last path block.

       SB              the system block index  of  the  system  block  to
                       which this path block is queued.
   SYSAP-SCS INTERFACE                                           Page 6-7


       CHAR            the  characteristics  of  the  destination  system
                       port.  (See the appropriate port specification.)

       FSTATUS         SUCCESS if entry is valid;  FAIL otherwise.

   Only if STATE =  VC_OPEN  can  the  connection  management,  datagram,
   sequential message, and block data services be used.
|  
|  REQUEST ID REMOVED
   SYSAP-SCS INTERFACE                                           Page 6-8


   6.3  CONNECTION MANAGEMENT SERVICE

|  A connection exists in one  of  several  states:   CLOSED,  LISTENING,
|  CONNECT_SENT,   CONNECT_ACK,  CONNECT_REC,  ACCEPT_SENT,  REJECT_SENT,
|  OPEN,    DISCONNECT_SENT,    DISCONNECT_REC,    DISCONNECT_ACK     and
|  DISCONNECT_MATCH.
|  
|  There are two sides to a connection termed the  active  side  and  the
|  passive side.
|  
|  The passive side indicates a willingness to establish a connection  by
|  calling LISTEN.  This moves the passive side to the LISTENING state.
|  
|  The  active  side  initiates  a  connection  by  calling  CONNECT.   A
|  CONNECT_REQ  message  is  sent and the state moves to CONNECT_SENT.  A
|  CONNECT_RSP is received with a status of NO_MATCH indicating  that  no
|  such  process  is  listening,  NO_RESOURCES  if  no  connect  block is
|  available, or CONNECTED if  the  connection  can  be  handled  by  the
|  destination  system.  The connect request is handed to the destination
|  SYSAP at this point.  When  CONNECTED  is  returned,  the  CONNECT_ACK
|  state is entered, otherwise the CLOSED state is entered.
|  
|  In the CONNECT_ACK state a REJECT_REQ  causing  the  state  to  go  to
|  CLOSED  or  ACCEPT_REQ message can be received causing the state to go
|  to OPEN.
|  
|  When the SYSAP on the destination receives  the  connect  request,  it
|  responds  with  an  ACCEPT  causing  its side to go to the ACCEPT_SENT
|  state or a REJECT causing its side to  go  to  the  REJECT_SENT.   The
|  appropriate  reply from the active side of ACCEPT_RSP causes the state
|  to go OPEN, and recept of REJECT_RSP causes the state to go CLOSED.

   When the connection is OPEN,  the  datagram,  sequenced  message,  and
   block data services may be used.

   Either  side  initiates  termination  of  the  connection  by  calling
   DISCONNECT.   Following  the  DISCONNECT call, no datagram, sequential
   message, or block transfer transmission operations can be performed by
   the  disconnecting  side.   Attempts  to initiate a transfer will fail
   with status NOT_OPEN.  The sequence of  states  is  dependent  on  the
   order  of  the DISCONNECT calls.  The protocol is generally asymmetric
   with one side, called the active side, initiating the disconnect.

   The active side calling DISCONNECT moves to the DISCONNECT_SENT  state
   while the passive side moves to DISCONNECT_REC state.  When the active
   side is notified of receipt of the disconnect request by  the  passive
   side,  it  moves  to  DISCONNECT_ACK  state.   Both sides wait for the
   passive SYSAP to be notified of the request and to  respond  with  its
   own  DISCONNECT.  When the passive SYSAP calls DISCONNECT, the passive
   side moves to DISCONNECT_MATCH and notifies the  active  side  of  the
   SYSAP's  action.   The  active  side  moves  to  CLOSED state, and the
   passive side moves to CLOSED upon  confirmation.   Should  both  sides
   issue   DISCONNECT  requests  simultaneously,  the  protocol  will  be
   symmetric   with   both   active   sides   moving    through    states
   DISCONNECT_SENT, DISCONNECT_MATCH, and CLOSED.
   SYSAP-SCS INTERFACE                                           Page 6-9


|  If there is any failure  of  lower  SCA  layers,  both  sides  of  any
|  non-closed connection move to the CLOSED state.

   The (local side) state  of  a  connection  is  determined  by  calling
   CONNECT_STATE_POLL.    Section   9.6   contains  a  full  state  table
   describing the above states and transition conditions.
|  
|  SYSAPs that require a minimum size for messages and datagrams  operate
|  in the following manner to assure that these message sizes are present
|  on a connection:  When the SYSAP starts, it checks the  message  sizes
|  on the local system and does not perform a LISTEN if the message sizes
|  are too small.  Before a SYSAP  performs  a  connect,  it  checks  the
|  message sizes of the remote system and does not perform the CONNECT if
|  the remote systems message sizes are too small.  The message sizes can
|  be determined with the CONFIG_SYS request.



   6.3.1  Connect

   This function allocates a connection block  and  actively  requests  a
   connection:

|  function CONNECT(
|          var CID: CONNECT_ID;
|          SRC_PROC: PROC_NAME;
|          DST_PROC: PROC_NAME;
|          DST: SB_INDEX;
|          THRSH: WORD;
|          { [CREDITS: Q_BUF_PTR];... }
|          DATA: C_DATA
|          { [PATH: PB_INDEX] }
|          ):
|          FSTATUS;
   where:

       CID             the connect id of the connection  block  allocated
                       by CONNECT.

       SRC_PROC        the local process name.

       DST_PROC        the destination process name.

       DST             the system block corresponding to the  destination
                       system.

       THRSH           the  minimum  number  of   message   buffers   the
                       destination  process  should  maintain  for proper
                       operation of the SYSAP protocol.
|  
|      CREDITS         the address of a  list  of  message  buffers  that
|                      represent an initial credit.
   SYSAP-SCS INTERFACE                                          Page 6-10


       DATA            initial connection data.  The format  of  DATA  is
                       process specific.

       PATH            optional Path  Block  index,  if  SYSAP  needs  to
                       request connection over a specific interconnect.
|  
|      ERROR           REMOVED

       FSTATUS         SUCCESS if a connection block is allocated;   FAIL
                       otherwise.



   6.3.2  Listen

   This function allocates a connection block and passively listens for a
   connection request from a destination process:

|  function LISTEN(
|          var CID: CONNECT_ID;
|          SRC_PROC: PROC_NAME;
|          DST_PROC: PROC_NAME;
|          DST: SB_INDEX ):
|          FSTATUS;
   where:

       CID             the connect id of the connection  block  allocated
                       by LISTEN.

       SRC_PROC        the local process name.

       DST_PROC        the destination process name.  A DST_PROC field of
                       all  blanks  indicates a willingness to connect to
                       any process.

       DST             the system block corresponding to the  destination
                       system.   A DST field of 0 indicates a willingness
                       to connect to any system.
|  
|      THRSH           REMOVED

       FSTATUS         SUCCESS if a connection block is available;   FAIL
                       otherwise.
   SYSAP-SCS INTERFACE                                          Page 6-11


   6.3.3  Accept

   This procedure accepts a requested connection:

|  procedure ACCEPT(
|          CID: CONNECT_ID;
|          { [CREDITS: Q_BUF_PTR];...}
|          THRSH : WORD;
|          DATA: C_DATA);

   where:

       CID             the local connect id.

       CREDITS         the address of a message buffer that represents an
                       initial credit.
|  
|      THRSH           the  minimum  number  of   message   buffers   the
|                      destination  process  should  maintain  for proper
|                      operation of the SYSAP procotol.

       DATA            initial connection data.  The format  of  DATA  is
                       process specific.



   6.3.4  Reject

   This procedure rejects a requested connection:

   procedure REJECT(
           CID: CONNECT_ID;
           REASON: WORD);

   where:

       CID             the local connect id.
|  
|      REASON          the reason for rejection.  See Appendix E.
   SYSAP-SCS INTERFACE                                          Page 6-12


   6.3.5  Disconnect

   This procedure requests termination  of  a  connection.   Following  a
   disconnect  call,  further  transfer requests will be returned with an
   error.

   procedure DISCONNECT(
           CID: CONNECT_ID;
           REASON: WORD);

   where:

       CID             the local connect id.
|  
|      REASON          the reason for disconnection.  See Appendix E.
|  
|  /Due to the port design of the CI port, there is a restriction in  the
|  CI  PPD  layer.   DISCONNECT  cannot  be  called  until  all  (locally
|  initiated) outstanding block data transfers have completed.  SCS based
|  on  other  interconnects  need  not  have  this  restriction.  On some
|  interconnects waiting for block transfers could be too time  consuming
|  to make waiting practical./

   After DISCONNECT is called only the following connection  related  SCS
   calls are valid:

        1.  STATE_POLL

        2.  SEND_DG_POLL

        3.  REC_DG_POLL

        4.  CANCEL_REC_DG

        5.  SEND_MSG_POLL

        6.  REC_MSG_POLL

        7.  CANCEL_REC_MSG_POLL
   SYSAP-SCS INTERFACE                                          Page 6-13


   6.3.6  Connect State Poll

   This procedure returns the state of a connection:

   procedure STATE_POLL(
           CID: CONNECT_ID;
           var STATE: C_STATE;
           var DST_CID: CONNECT_ID;
           var DST_PROC: PROC_NAME;
           var DST_SB: SB_INDEX;
           var DST_PB: PB_INDEX;
           var DATA: C_DATA;
           var REASON: WORD);

   where:

       CID             the local connect id.
|  
|      STATE           the   connection   state.    (CLOSED,   LISTENING,
|                      CONNECT_SENT,       CONNECT_ACK,      CONNECT_REC,
|                      ACCEPT_SENT, REJECT_SENT,  OPEN,  DISCONNECT_SENT,
|                      DISCONNECT_REC,         DISCONNECT_ACK,         or
|                      DISCONNECT_MATCH.)

       DST_CID         the destination connect id.

       DST_PROC        the destination process name.

       DST_SB          the system block corresponding to the  destination
                       system.

       DST_PB          the path block corresponding to  the  interconnect
                       over which the connection exists.

       DATA            connect data.

       REASON          the reason for rejection or disconnection.

   Any queued datagram or message buffers remaining after a connection is
   closed are disposed of in an implementation specific manner.
   SYSAP-SCS INTERFACE                                          Page 6-14


   6.4  DATAGRAM SERVICE

   A datagram is sent by calling SEND_DG.  A  parameter  in  the  SEND_DG
   call  determines whether the buffer containing the datagram to be sent
   is to be returned or queued to receive  a  datagram.   In  the  former
   case,  the  datagram  buffer  is  returned by calling SEND_DG_POLL.  A
   datagram buffer is queued to receive  a  message  by  calling  REC_DG.
   Receipt  of a datagram is checked by calling REC_DG_POLL.  Return of a
   queued datagram buffer is requested by calling CANCEL_REC_DG.
|  
|  Datagrams are queued and accounted for on a per connection basis.   It
|  is possible to return datagrams quickly to the receive queues when too
|  many arrive for a connection and thereby  make  it  more  likely  that
|  datagram  receive buffers are available to connections which carefully
|  manage the number of datagram receive buffers they queue.



   6.4.1  Send Datagram

   This function sends a datagram over a connection:

   function SEND_DG(
           CID: CONNECT_ID;
           RET_FLAG: boolean;
           DLEN: APPL_DG_LEN;
           PTR: Q_BUF_PTR):
           FSTATUS;

   where:

       CID             the local connect id.

       RET_FLAG        true if the datagram buffer  is  to  be  returned,
                       false otherwise.

       DLEN            the length (in bytes) of the datagram text.

       PTR             the address of the datagram buffer.

       FSTATUS         SUCCESS if the send is  queued,  NOT_OPEN  if  the
                       connection has been closed.

   When RET_FLAG is false, SEND_DG  does  an  implicit  Receive  Datagram
   since  the  datagram  buffer  is  available after sending to receive a
   datagram.
   SYSAP-SCS INTERFACE                                          Page 6-15


   6.4.2  Send Datagram Poll

   This function checks the return of a datagram sent with  the  RET_FLAG
   true:

   function SEND_DG_POLL(
           CID: CONNECT_ID;
           var PTR: Q_BUF_PTR):
           FSTATUS;

   where:

       CID             the local connect id.

       PTR             the address of the datagram buffer.

       FSTATUS         SUCCESS  if  the   buffer   is   returned;    FAIL
                       otherwise.

   Note that the original buffer contents are returned intact.



   6.4.3  Receive Datagram

   This function queues a datagram buffer to receive a datagram:

   function REC_DG(
           CID: CONNECT_ID;
           PTR: Q_BUF_PTR):
           FSTATUS;

   where:

       CID             the local connect id.

       PTR             the address of the datagram buffer.

       FSTATUS         SUCCESS if the receive buffer is queued,  NOT_OPEN
                       if the connection has been closed.
   SYSAP-SCS INTERFACE                                          Page 6-16


   6.4.4  Receive Datagram Poll

   This function checks if a datagram has been received in  a  previously
   queued datagram buffer:

   function REC_DG_POLL(
           CID: CONNECT_ID;
           var DLEN: APPL_DG_LEN;
           var PTR: Q_BUF_PTR):
           FSTATUS;

   where:

       CID             the local connect id.

       DLEN            the length (in bytes) of the datagram text.

       PTR             the address of the datagram buffer.

       FSTATUS         SUCCESS if a datagram  has  been  received;   FAIL
                       otherwise.



   6.4.5  Cancel Receive Datagram

   This function dequeues a datagram buffer:

   function CANCEL_REC_DG(
           CID: CONNECT_ID;
           var PTR: Q_BUF_PTR):
           FSTATUS;

   where:

       CID             the local connect id.

       PTR             the address of the datagram buffer.

       FSTATUS         SUCCESS if a buffer is dequeued;  FAIL otherwise.
   SYSAP-SCS INTERFACE                                          Page 6-17


   6.5  SEQUENTIAL MESSAGE SERVICE

   A message is sent by calling SEND_MSG.  A parameter  in  the  SEND_MSG
   call  determines  whether  the  buffer containing the message is to be
   returned or queued to receive a message.   In  the  former  case,  the
   message buffer is returned by calling SEND_MSG_POLL.  A message buffer
   is queued to receive a message  by  calling  REC_MSG.   Receipt  of  a
   message  is  checked  by  calling  REC_MSG_POLL.   Return  of a queued
   message buffer is requested by  calling  CANCEL_REC_MSG.   The  queued
   message buffer is returned by calling CANCEL_REC_MSG_POLL.

   The  sequential  message  service  uses  credit-based  flow   control.
   Consider  two  sides of a connection X and Y.  When X queues a message
   buffer, Y receives a send credit.  In general, if Y queues  y  buffers
   and X queues x buffers, Y has x send credits and X has y send credits.

   To send a message, a send credit is needed.  When the message is sent,
   the number of send credits is decremented by 1.

   In order to support messages  of  different  importance  on  a  single
   connection,  a threshold mechanism is employed.  A threshold parameter
   appears in two places:

        1.  When a  connection  is  established  each  side  specifies  a
            threshold  which  is  the  minimum  number  of queued message
            buffers the other side should maintain for  proper  operation
            of  the  SYSAP  protocol  (i.e.   the  support of messages of
            different importance).  A CANCEL_REC_MSG call does not return
            buffers  that  would  drop  the number of send credits on the
            other side below the SYSAP protocol threshold.

        2.  A SEND_MSG call (also the READ  and  WRITE  calls:   see  the
            section  on  block  data service) has a threshold number that
            results in a message being sent only if at least that  number
            of send credits would remain after sending the message.
   SYSAP-SCS INTERFACE                                          Page 6-18


   6.5.1  Send Message

   This function sends a message over a connection:

   function SEND_MSG(
           CID: CONNECT_ID;
           THRSH: WORD;
           RET_FLAG: boolean;
           MLEN: APPL_MSG_LEN;
           PTR: Q_BUF_PTR):
           FSTATUS;

   where:

       CID             the local connect id.

       THRSH           the message is sent only if  at  least  this  many
                       send   flow  control  credits  will  remain.   The
                       minimum value of THRSH is 0.

       RET_FLAG        true if the message  buffer  is  to  be  returned;
                       false otherwise.

       MLEN            the length (in bytes) of the message.

       PTR             the address of the message buffer.

       FSTATUS         SUCCESS if the send is queued,  FAIL  if  no  flow
                       control  credit  is  available,  NOT_OPEN  if  the
                       connection has been closed.

   When RET_FLAG is false, SEND_MSG  does  an  implicit  Receive  Message
   since the message buffer is available to receive a message.



   6.5.2  Send Message Poll

   This function checks the return of a message sent  with  the  RET_FLAG
   true:

   function SEND_MSG_POLL(
           CID:CONNECT_ID;
           var PTR: Q_BUF_PTR):
           FSTATUS;

   where:

       CID             the local connect id.

       PTR             the address of the message buffer.

       FSTATUS         SUCCESS if a buffer is returned;  FAIL otherwise.
   SYSAP-SCS INTERFACE                                          Page 6-19


   Note that the original buffer contents are returned intact.



   6.5.3  Receive Message

   This function queues a message buffer to receive a message and extends
   a flow control credit to the destination process:

   function REC_MSG(
           CID: CONNECT_ID;
           PTR: Q_BUF_PTR):
           FSTATUS;

   where:

       CID             the local connect id.

       PTR             the address of the message buffer.

       FSTATUS         SUCCESS if the buffer has been queued, NOT_OPEN if
                       the connection has been closed.



   6.5.4  Receive Message Poll

   This function checks if a message has been received  in  a  previously
   queued message buffer:

   function REC_MSG_POLL(
           CID: CONNECT_ID;
           var MLEN: APPL_MSG_LEN;
           var PTR: Q_BUF_PTR):
           FSTATUS;

   where:

       CID             the local connect id.

       MLEN            the length (in bytes) of the message.

       PTR             the address of the message buffer.

       FSTATUS         SUCCESS if a  message  has  been  received;   FAIL
                       otherwise.
   SYSAP-SCS INTERFACE                                          Page 6-20


   6.5.5  Cancel Receive Message

   This procedure requests return of a message buffer (and the associated
   flow control credit from the destination process):

   procedure CANCEL_REC_MSG(
           CID: CONNECT_ID);

   where:

       CID             the local connect id.

   Cancellation does not occur if (1) the flow control  credit  has  been
   used  by the destination process to send a message or for a block data
   operation, or (2) the number of destination credits would  drop  below
   the SYSAP protocol threshold.



   6.5.6  Cancel Receive Message Poll

   This function checks if a cancel operation has completed:

   function CANCEL_REC_MSG_POLL(
           CID: CONNECT_ID;
           var PTR: Q_BUF_PTR):
           FSTATUS;

   where:

       CID             the local connect id.

       PTR             the address of the message buffer.

       FSTATUS         SUCCESS if a buffer  is  returned;   NULL  if  the
                       cancel cannot be completed;  FAIL otherwise.

   CANCEL_REC_MSG_POLL must be called until every cancel has  a  matching
   SUCCESS  or  NULL FSTATUS.  Null status indicates that the destination
   would not allow the buffer to be returned in order to keep the  number
   of credits above threshold.
   SYSAP-SCS INTERFACE                                          Page 6-21


   6.6  BLOCK DATA SERVICE

   A name is associated with a named buffer by calling  MAP.   This  name
   may  be used locally or passed to the other side of a connection using
   one of the communications services.  A name is  disassociated  from  a
   buffer by calling UNMAP.

   By calling WRITE, data is transferred  from  the  local  side  to  the
   destination  side.   The  completion  of  the  transfer  is checked by
   calling WRITE_POLL.  Similarly, by calling READ, data  is  transferred
   from  the  destination  side to the local side.  The completion of the
   transfer is checked by calling READ_POLL.

   To initiate a block data transfer, the local side  must  hold  a  send
   credit.  The send credit is used for the duration of the transfer, but
   is available again after completion of the transfer.
|  
|  In the following description, no  provision  is  made  for  cancelling
|  block  data  transfers.   An  implementation  must  provide  a  cancel
|  function.  Due to a restriction in the CI-780 port, it is not possible
|  to  withdraw  a  block transfer that has started without shutting down
|  the port to port VC.  This is not the intent  of  SCA  and  should  be
|  viewed as an implementation restriction.



   6.6.1  Map Buffer

   This function associates a name with a local named buffer:

   function MAP(
           {BLOCK_BUF: BUF_DESCR;}
           var NAME: LONG):
           FSTATUS;

   where:

       BLOCK_BUF       a descriptor of  a  named  buffer  (implementation
                       specific).

       NAME            the name of buffer returned by MAP.

       FSTATUS         SUCCESS if a name is associated;  FAIL otherwise.

   The  MAP  function  may  have   additional   implementation   specific
   parameters.   An  examples  is  a  connect  id that indicates that the
   connection block has additional information on how to map the  buffer.
   This  would  be needed if there were multiple ports on the system with
   different named buffer mapping techniques.
   SYSAP-SCS INTERFACE                                          Page 6-22


   6.6.2  Unmap Buffer

   This procedure disassociates a name from a named buffer:

   procedure UNMAP(
           NAME: LONG);

   where:

       NAME            the buffer name.



   6.6.3  Read

   This function requests transfer  of  data  from  a  destination  named
   buffer to a local block data buffer:

   function READ(
           CID: CONNECT_ID;
           THRSH: WORD;
           PTR: Q_BUF_PTR;
           var XID: WORD):
           FSTATUS;

   where:

       CID             the local connect id.

       THRSH           the transfer is started only if at least this many
                       send   flow  control  credits  will  remain.   The
                       minimum value of THRSH is 0.

       PTR             the address of the message buffer  containing  the
                       block data arguments.

       XID             the transaction id assigned by READ.

       FSTATUS         SUCCESS if the transfer is queued, FAIL if no flow
                       control  credit  is  available,  NOT_OPEN  if  the
                       connection has been closed.

   The block data arguments include:

       DATA_LENGTH     the number of bytes to be transferred.

       SEND_NAME       the name of the buffer  from  which  the  data  is
                       read.

       SEND_OFFSET     the starting byte in sending buffer.

       REC_NAME        the name of  the  buffer  to  which  the  data  is
                       written.
   SYSAP-SCS INTERFACE                                          Page 6-23


       REC_OFFSET      the starting byte in the receiving buffer.



   6.6.4  Read Poll

   This function checks if a read transfer has completed:

   function READ_POLL(
           CID: CONNECT_ID;
           var PTR: Q_BUF_PTR;
           var XID: WORD):
           FSTATUS;

   where:

       CID             local connect id.

       PTR             the address of  the  message  buffer  returned  by
                       READ_POLL.

       XID             the transaction id of the completed read.

       FSTATUS         SUCCESS if a read has completed;  FAIL otherwise.
   SYSAP-SCS INTERFACE                                          Page 6-24


   6.6.5  Write

   This function requests transfer of data from a local named buffer to a
   destination block data buffer:

   function WRITE(
           CID: CONNECT_ID;
           THRSH: WORD;
           PTR: Q_BUF_PTR;
           var XID: WORD):
           FSTATUS;

   where:

       CID             the local connect id.

       THRSH           the transfer is started only  if  this  many  send
                       flow  control  credits  will  remain.  The minimum
                       value of THRSH is 0.

       PTR             the address of the message buffer  containing  the
                       block data arguments.

       XID             the transaction id assigned by WRITE.

       FSTATUS         SUCCESS if the transfer is queued, FAIL if no flow
                       control  credit  is  available,  NOT_OPEN  if  the
                       connection has been closed.

   The block data arguments include:

       DATA_LENGTH     the number of bytes to be transferred.

       SEND_NAME       the name of the buffer  from  which  the  data  is
                       read.

       SEND_OFFSET     the starting byte in sending buffer.

       REC_NAME        the name of  the  buffer  to  which  the  data  is
                       written.

       REC_OFFSET      the starting byte in the receiving buffer.
   SYSAP-SCS INTERFACE                                          Page 6-25


   6.6.6  Write Poll

   This function checks if a write transfer has completed:

   function WRITE_POLL(
           CID: CONNECT_ID;
           var PTR: Q_BUF_PTR;
           var XID: WORD):
           FSTATUS;

   where:

       CID             the local connect id.

       PTR             the address of  the  message  buffer  returned  by
                       WRITE_POLL.

       XID             the transaction id of the completed write.

       FSTATUS         SUCCESS if a write has completed;  FAIL otherwise.











                                 CHAPTER 7

                             SCS-PPD INTERFACE



   The PPD interface is modelled as a set of function and procedure calls
   of  the  same  form  as  the  SCS  interface.   The  PPD  interface is
   essentially the CI port architecture, and the function  and  procedure
   names  (where  appropriate)  are  the  corresponding  CI  port command
   mnemonics.
|  
|  REQUEST ID REMOVED



   7.1  DATAGRAM SERVICE

   7.1.1  Send Datagram

   This procedure sends a datagram to a destination system:

   procedure SNDDG(
           DST: PB_INDEX;
           RET_FLAG: boolean;
           PTR: Q_BUF_PTR);

   where:

       DST             the destination port path block address.

       RET_FLAG        true if a  DGSNT  response  is  to  be  generated;
                       false otherwise.

       PTR             the address of the datagram buffer.
   SCS-PPD INTERFACE                                             Page 7-2


   7.1.2  Receive Datagram

   This procedure queues a datagram buffer to receive a datagram:

   procedure INSERT_DFREEQ(
           PTR: Q_BUF_PTR);

   where:

       PTR             the address of the datagram buffer.



   7.1.3  Return Datagram Buffer

   This function dequeues a datagram buffer:

   function REMOVE_DFREEQ(
           var PTR: Q_BUF_PTR):
           FSTATUS;

   where:

       PTR             the address of the datagram buffer.

       FSTATUS         SUCCESS if a buffer is dequeued;  FAIL otherwise.
   SCS-PPD INTERFACE                                             Page 7-3


   7.2  VIRTUAL CIRCUIT SERVICE

   7.2.1  Start Virtual Circuit

   This procedure requests the opening of a virtual circuit  between  the
   local and a destination system:

   procedure START_VC(
           DST: PB_INDEX;
           DATA: START_DATA;
           MPTR1: Q_BUF_PTR;
           MPTR2: Q_BUF_PTR;
           DPTR: Q_BUF_PTR);

   where:

       DST             the path block corresponding  to  the  destination
                       port.

       DATA            start data.  See Appendix G.

       MPTR1           the address of a message buffer.

       MPTR2           the address of a message buffer.

       DPTR            the address of a datagram buffer.
|  
|  Both message buffers, MPTR1 and MPTR2, are used to communicate between
|  SCS  instances  to establish and maintain connections.  One is used to
|  send control messages and  is  immediately  queued  as  a  receive  to
|  receive  the response.  One buffer is queued at all times as a receive
|  for commands from the other side and is queued as a transmit  for  the
|  response.   After  the response transmit it is queued as a receive for
|  the next incoming command.  There  is  at  most  one  outstanding  SCS
|  command  being  processed by the other side and one being processed by
|  this side.
|  
|  The datagram message buffer, DPTR, is used to start the port  to  port
|  virtual circuit and is used for both transmit and receive.
   SCS-PPD INTERFACE                                             Page 7-4


   7.3  MESSAGE SERVICE

   7.3.1  Send Message

   This procedure sends a message to a destination system:

   procedure SNDMSG(
           DST: PB_INDEX;
           RET_FLAG: boolean;
           PTR: Q_BUF_PTR);

   where:

       DST             the destination port path block address.

       RET_FLAG        true if a MSGSNT  response  is  to  be  generated;
                       false otherwise.

       PTR             the address of the message buffer.

   SNDMSG requires an open virtual circuit to exist to DST.



   7.3.2  Receive Message

   This procedure queues a message buffer to receive a message:

   procedure INSERT_MFREEQ(
           PTR: Q_BUF_PTR);

   where:

       PTR             the address of the message buffer.



   7.3.3  Return Message Buffer

   This function dequeues a message buffer:

   function REMOVE_MFREEQ(
           var PTR: Q_BUF_PTR):
           FSTATUS;

   where:

       PTR             the address of the message buffer.

       FSTATUS         SUCCESS if a buffer is dequeued;  FAIL otherwise.
   SCS-PPD INTERFACE                                             Page 7-5


   7.4  BLOCK DATA SERVICE

   7.4.1  Send Data

   This procedure sends data from a named buffer in the local system to a
   named buffer in the destination system:

   procedure SNDDAT(
           DST: PB_INDEX;
           PTR: Q_BUF_PTR);

   where:

       DST             the destination port path block address.

       PTR             the address of the message buffer  containing  the
                       block data arguments.

   The block data arguments include:

       DATA_LENGTH     the number of bytes to be transferred.

       SEND_NAME       the name of the buffer  from  which  the  data  is
                       read.

       SEND_OFFSET     the starting byte in sending buffer.

       REC_NAME        the name of  the  buffer  to  which  the  data  is
                       written.

       REC_OFFSET      the starting byte in the receiving buffer.

   SNDDAT requires a open virtual circuit to exist to DST.
   SCS-PPD INTERFACE                                             Page 7-6


   7.4.2  Request Data

   This procedure requests the sending of data from a named buffer  in  a
   destination system to a named buffer in the local system:

   procedure REQDAT(
           DST: PB_INDEX;
           PTR: Q_BUF_PTR);

   where:

       DST             the destination port path block address.

       PTR             the address of the message buffer  containing  the
                       block data arguments.

   The block data arguments include:

       DATA_LENGTH     the number of bytes to be transferred.

       SEND_NAME       the name of the buffer  from  which  the  data  is
                       read.

       SEND_OFFSET     the starting byte in sending buffer.

       REC_NAME        the name of  the  buffer  to  which  the  data  is
                       written.

       REC_OFFSET      the starting byte in the receiving buffer.

   REQDAT requires a open virtual circuit to exist to DST.
   SCS-PPD INTERFACE                                             Page 7-7


   7.5  RESPONSES

   This function checks if a message has been sent, a  message  has  been
   received, a datagram has been sent, a datagram has been received, sent
   data has been confirmed, requested data has been received,  or  an  id
   has been received.

   function RSP_POLL(
           var RSP: RSP_TYPE;
           var DST: PB_INDEX;
           var PTR: Q_BUF_PTR):
           FSTATUS;

   where:

       RSP             the response type:  (MSGSNT, DGSNT, MSGREC, DGREC,
                       CNFREC, DATREC, IDREC, MCNFREC, MDATREC).

       DST             the destination port path block address.

       PTR             the  address  of  a  queued  buffer  returned   by
                       RSP_POLL.   The  buffer  is  a messsage buffer for
                       MSGSNT, MSGREC, CNFREC, and DATREC and a  datagram
                       buffer otherwise.

       FSTATUS         SUCCESS if a response is present;  FAIL otherwise.











                                 CHAPTER 8

                         SCS MESSAGES AND DATAGRAMS



   8.1  TYPES

   SCS messages and datagrams  are  of  two  basic  types:   control  and
   application.   Control  messages  carry  information  between peer SCS
   processes while application messages and datagrams  carry  information
   between  peer  SYSAP processes.  Control messages are of two subtypes:
   request and response.  A request message from SCS  process  X  to  SCS
   process  Y is followed by a response message from SCS process Y to SCS
   process X that acknowledges the previous request and  enables  sending
   the next request.
   SCS MESSAGES AND DATAGRAMS                                    Page 8-2


   The general format of an SCS message or datagram is:



                    3               1
                    1               5             0
                   +---------------+---------------+
                   |    CREDIT     |   SCS_TYPE    |
                   +---------------+---------------+
                   |         REC_CONNECT_ID        |
                   +-------------------------------+
                   |         SEND_CONNECT_ID       |
                   +-------------------------------+
                   |                               |
                   =        SCS_TYPE_SPECIFIC      =
                   |                               |
                   +-------------------------------+



   where:
                       SCS_TYPE the message or datagram type.

       CREDIT          the flow control credit.

       REC_CONNECT_ID  the connect id of the process  that  is  receiving
                       the  message  or datagram or on whose behalf it is
                       being received.

       SEND_CONNECT_ID the connect id of the process that is sending  the
                       messsage  or  datagram  or  on  whose behalf it is
                       being sent.

       SCS_TYPE_SPECIFIC depends on SCS_TYPE.
   SCS MESSAGES AND DATAGRAMS                                    Page 8-3


   8.2  SCS CONTROL MESSAGES

   8.2.1  Connect Request

   The CONNECT_REQ request message requests a connection.  The format  of
   CONNECT_REQ is:


                    3               1
                    1               5             0
                   +---------------+---------------+
                   |      CREDIT   |    SCS_TYPE   |
                   +---------------+---------------+
                   |               0               |
                   +---------------+---------------+
                   |        SEND_CONNECT_ID        |
                   +---------------+---------------+
                   |       0       |  MIN_CREDIT   |
                   +---------------+---------------+
                   |                               |
                   =           REC_PROC            =
                   |                               |
                   +-------------------------------+
                   |                               |
                   =           SEND_PROC           =
                   |                               |
                   +-------------------------------+
                   |                               |
                   =           SEND_DATA           =
                   |                               |
                   +-------------------------------+



   where:

       SCS_TYPE         CONNECT_REQ.

       CREDIT          the  initial  number  of  flow   control   credits
                       extended.  CREDIT must be non-negative.

       SEND_CONNECT_ID the connect id of the process sending the  connect
                       request.

       MIN_CREDIT      the minimum number of flow control credits needed.
                       MIN_CREDIT must be non-negative.

       REC_PROC        the name of the process to receive the request.

       SEND_PROC       the name of the process sending the request.

       SEND_DATA       connect data from the sending process.
   SCS MESSAGES AND DATAGRAMS                                    Page 8-4


   8.2.2  Connect Response

   The CONNECT_RSP response message acknowledges the CONNECT_REQ  message
   and   enables  sending  the  next  request  message.   The  format  of
   CONNECT_RSP is:


                    3               1
                    1               5             0
                   +---------------+---------------+
                   |       0       |   SCS_TYPE    |
                   +---------------+---------------+
                   |         REC_CONNECT_ID        |
                   +-------------------------------+
                   |         SEND_CONNECT_ID       |
                   +---------------+---------------+
                   |     STATUS    |       0       |
                   +---------------+---------------+



   where:

       SCS_TYPE        CONNECT_RSP.

       REC_CONNECT_ID  the connect id of the process sending the  connect
                       request.

       SEND_CONNECT_ID the connect id of the process  responding  to  the
                       connect request.
|  
|      STATUS          CONNECTED  if  the  connect  request  was  queued,
|                      NO_MATCH or NO_RESOURCES otherwise.
   SCS MESSAGES AND DATAGRAMS                                    Page 8-5


   8.2.3  Accept Request

   The ACCEPT_REQ request message  accepts  a  connection  request.   The
   format of ACCEPT_REQ is:


                    3               1
                    1               5             0        
                   +---------------+---------------+
                   |     CREDIT    |    SCS_TYPE   |
                   +---------------+---------------+
                   |         REC_CONNECT_ID        |
                   +-------------------------------+
                   |         SEND_CONNECT_ID       |
                   +---------------+---------------+
                   |       0       |   MIN_CREDIT  |
                   +---------------+---------------+
                   |                               |
                   =            REC_PROC           =
                   |                               |
                   +-------------------------------+
                   |                               |
                   =            SEND_PROC          =
                   |                               |
                   +-------------------------------+
                   |                               |
                   =            SEND_DATA          =
                   |                               |
                   +-------------------------------+




   where:

       SCS_TYPE        ACCEPT_REQ.

       CREDIT          the initial number of  credits  extended.   CREDIT
                       must be non-negative.

       REC_CONNECT_ID  the  connect  id  of  the  process  receiving  the
                       request.

       SEND_CONNECT_ID the connect id of the process sending the request.

       MIN_CREDIT      the minimum number of flow control credits needed.
                       MIN_CREDIT must be non-negative.

       REC_PROC        the name of the process receiving the request.

       SEND_PROC       the name of the process sending the request.

       SEND_DATA       connect data from the sending process.
   SCS MESSAGES AND DATAGRAMS                                    Page 8-6


   8.2.4  Accept Response

   The ACCEPT_RSP response message acknowledges  the  ACCEPT_REQ  message
   and   enables  sending  the  next  request  message.   The  format  of
   ACCEPT_RSP response is:
|  
|  
|                   3               1
|                   1               5             0
|                  +---------------+---------------+
|                  |       0       |   SCS_TYPE    |
|                  +---------------+---------------+
|                  |         REC_CONNECT_ID        |
|                  +-------------------------------+
|                  |         SEND_CONNECT_ID       |
|                  +-------------------------------+
|                  |   REASON      |       0       |
|                  +-------------------------------+
|  

   where:

       SCS_TYPE        ACCEPT_RSP.

       REC_CONNECT_ID  same as SEND_CONNECT_ID in the ACCEPT_REQ message.

       SEND_CONNECT_ID same as REC_CONNECT_ID in the ACCEPT_REQ  message.
|                      REASON  reason  for  failure to accept connection.
|                      NO_RESOURCES  and   DISCONNECTED   are   possible.
|                      CONNECTED  means  that  the  ACCEPT_REQ  is  being
|                      processed.
   SCS MESSAGES AND DATAGRAMS                                    Page 8-7


   8.2.5  Reject Request

   The REJECT_REQ request message  rejects  a  connection  request.   The
   format of REJECT_REQ is:
|  
|  
|                   3               1
|                   1               5             0
|                  +---------------+---------------+
|                  |       0       |   SCS_TYPE    |
|                  +---------------+---------------+
|                  |         REC_CONNECT_ID        |
|                  +-------------------------------+
|                  |         SEND_CONNECT_ID       |
|                  +---------------+---------------+
|                  |    REASON     |       0       |
|                  +---------------+---------------+
|                  
|  

   where:

       SCS_TYPE        REJECT_REQ.

       REC_CONNECT_ID  the connect id of process receiving the request.

       SEND_CONNECT_ID the connect id of the process sending the request.
|  
|      REASON          the reason for rejection.  See Appendix E.
   SCS MESSAGES AND DATAGRAMS                                    Page 8-8


   8.2.6  Reject Response

   The REJECT_RSP response message acknowledges  the  REJECT_REQ  message
   and   enables  sending  the  next  request  message.   The  format  of
   REJECT_RSP is:

                    3               1
                    1               5             0
                   +---------------+---------------+
                   |       0       |   SCS_TYPE    |
                   +---------------+---------------+
                   |         REC_CONNECT_ID        |
                   +-------------------------------+
                   |         SEND_CONNECT_ID       |
                   +-------------------------------+



   where:

       SCS_TYPE        REJECT_RSP.

       REC_CONNECT_ID  same as SEND_CONNECT_ID in the REJECT_REQ message.

       SEND_CONNECT_ID same as REC_CONNECT_ID in the REJECT_REQ message.
   SCS MESSAGES AND DATAGRAMS                                    Page 8-9


   8.2.7  Disconnect Request

   The DISCONNECT_REQ request message requests disconnection.  The format
   of DISCONNECT_REQ is:
|  
|  
|                   3               1
|                   1               5             0                
|                  +---------------+---------------+
|                  |     0         |    SCS_TYPE   |
|                  +---------------+---------------+
|                  |         REC_CONNECT_ID        |
|                  +-------------------------------+
|                  |         SEND_CONNECT_ID       |
|                  +---------------+---------------+
|                  |     REASON    |       0       |
|                  +---------------+---------------+
|  
|  

   where:

       SCS_TYPE        DISCONNECT_REQ.

       REC_CONNECT_ID  the  connect  id  of  the  process  receiving  the
                       request.

       SEND_CONNECT_ID the connect id of the process sending the request.
|  
|      REASON          the reason for disconnection.  See Appendix E.
   SCS MESSAGES AND DATAGRAMS                                   Page 8-10


   8.2.8  Disconnect Response

   The DISCONNECT_RSP response message  acknowledges  the  DISCONNECT_REQ
   message  and  enables sending the next request message.  The format of
   DISCONNECT_RSP is:


                    3               1
                    1               5             0
                   +---------------+---------------+
                   |     0         |    SCS_TYPE   |
                   +---------------+---------------+
                   |         REC_CONNECT_ID        |
                   +-------------------------------+
                   |         SEND_CONNECT_ID       |
                   +-------------------------------+



   where:

       SCS_TYPE        DISCONNECT_RSP.

       REC_CONNECT_ID  same  as  SEND_CONNECT_ID  in  the  DISCONNECT_REQ
                       message.

       SEND_CONNECT_ID same  as  REC_CONNECT_ID  in  the   DISCONNECT_REQ
                       message.
   SCS MESSAGES AND DATAGRAMS                                   Page 8-11


   8.2.9  Credit Request

   The CREDIT_REQ request message carries credits for flow control.   The
   format of CREDIT_REQ is:


                    3               1
                    1               5             0
                   +---------------+---------------+
                   |     CREDIT    |    SCS_TYPE   |
                   +---------------+---------------+
                   |         REC_CONNECT_ID        |                 
                   +-------------------------------+
                   |        SEND_CONNECT_ID        |
                   +-------------------------------+


   where:

       SCS_TYPE        CREDIT_REQ.

       CREDIT          a signed  integer  giving,  if  non-negative,  the
                       number   of   additional   credits  extended;   if
                       negative, the number of credits  requested  to  be
                       returned.

       REC_CONNECT_ID  the  connect  id  of  the  process  receiving  the
                       credits.

       SEND_CONNECT_ID the connect id of the process sending the credits.
   SCS MESSAGES AND DATAGRAMS                                   Page 8-12


   8.2.10  Credit Response

   The CREDIT_RSP response message acknowledges  the  CREDIT_REQ  message
   and  enables  sending  of  the  next  request  message.  The format of
   CREDIT_RSP is:


                    3               1
                    1               5             0
                   +---------------+---------------+
                   |     CREDIT    |    SCS_TYPE   |
                   +---------------+---------------+
                   |         REC_CONNECT_ID        |
                   +-------------------------------+
                   |         SEND_CONNECT_ID       |
                   +-------------------------------+


   where:

       SCS_TYPE        CREDIT_RSP.

       CREDIT          if the CREDIT field in the CREDIT_REQ message  was
                       non-negative, then the value of CREDIT;  otherwise
                       the negative of the  number  of  credits  actually
                       returned.

       REC_CONNECT_ID  same as SEND_CONNECT_ID in the CREDIT_REQ message.

       SEND_CONNECT_ID  same as REC_CONNECT_ID in the CREDIT_REQ message.
   SCS MESSAGES AND DATAGRAMS                                   Page 8-13


   8.3  APPLICATION MESSAGE

   The APPL_MSG application message carries a SYSAP layer  message.   The
   format of APPL_MSG is:


                    3               1
                    1               5             0
                   +---------------+---------------+
                   |     CREDIT    |    SCS_TYPE   |
                   +---------------+---------------+
                   |         REC_CONNECT_ID        |
                   +-------------------------------+
                   |         SEND_CONNECT_ID       |
                   +-------------------------------+
                   |                               |
                   =         SYSAP_MSG_TEXT        =
                   |                               |
                   +-------------------------------+



   where:

       SCS_TYPE        APPL_MSG.

       CREDIT          the number of flow control credits being extended.
                       CREDIT must be non-negative.

       REC_CONNECT_ID  the  connect  id  of  the  process  receiving  the
                       message.

       SEND_CONNECT_ID the connect id of the process sending the message.

       SYSAP_MSG_TEXT  the SYSAP layer message text.
   SCS MESSAGES AND DATAGRAMS                                   Page 8-14


   8.4  APPLICATION DATAGRAM

   The APPL_DG datagram carries a SYSAP layer datagram.   The  format  of
   APPL_DG is:


                    3               1
                    1               5             0
                   +---------------+---------------+
                   |     0         |    SCS_TYPE   |
                   +---------------+---------------+
                   |         REC_CONNECT_ID        |
                   +-------------------------------+
                   |         SEND_CONNECT_ID       |
                   +-------------------------------+
                   |                               |
                   =          SYSAP_DG_TEXT        =
                   |                               |
                   +-------------------------------+



   where:

       SCS_TYPE        APPL_DG.

       REC_CONNECT_ID  the  connect  id  of  the  process  receiving  the
                       datagram.

       SEND_CONNECT_ID the  connect  id  of  the  process   sending   the
                       datagram.

       SYSAP_DG_TEXT   the SYSAP layer datagram text.











                                 CHAPTER 9

                               SCS OPERATION



   9.1  RELATION TO PPD VIRTUAL CIRCUIT

   All SCS messages flow over a port-to-port virtual circuit provided  by
   the  PPD  layer.   All  SYSAP-SCS  connections are multiplexed on this
   virtual circuit.  Closing the PPD virtual  circuit  by  either  system
   requires  closing  all  SCS  connections.   The SYSAPs are notified of
   connection close by calling the STATE_POLL function.
|  
|  
|  
|  9.2  SCS PROTOCOL VERSION RESOLUTION
|  
|  The start data contains a protocol version number.   This  allows  SCA
|  version  upgrade  in  the future.  The first version of SCA is version
|  zero.
|  
|  The version field is compared in such a way to allow newer versions to
|  be  written  to  talk  down  to  older  versions  as  well as to their
|  contemporary versions.  This is done by leaving the decision of making
|  the start_vc to the higher numbered version.  The lower number version
|  always accepts starts from the same or higher versions.  Higher number
|  versions  always  accept  equal  version starts and may as well accept
|  starts from lower numbered versions if the higher version  is  willing
|  to  talk down to the older version.  Talking down is an implementation
|  decision.  Accepting connects from higher versions is required.



   9.3  SCS CONTROL MESSAGE FLOW CONTROL

   When a port-to-port virtual circuit is opened, each system supplies  2
   message  buffers.  The first, termed the local message buffer, is used
   to send SCS  control  request  messages  and  receive  the  associated
   response control message.  This buffer is initially queued on the path
   block, dequeued to send a request  message,  and  requeued  after  the
   response  is  received.   The  second,  termed the destination message
   buffer, is used to receive SCS control request messages and  send  the
   associated  response control message.  This buffer is initially queued
   on the PPD MFREEQ, dequeued when a SCS control  request  is  received,
   and requeued after the response is sent.  At most 1 request message on
   SCS OPERATION                                                 Page 9-2


   each direction of the virtual circuit can be outstanding  at  a  time.
   Only  when  the  destination  of  the request responds with a response
   message can another request message be sent.
|  
|  These are some descriptions of the credit variables used  in  the  SCS
|  operation description which will help to understand credit management.
|  
|      THRSH           this value is the name of a call  parameter  which
|                      corresponds to MIN_SEND_CREDIT.  When a connection
|                      is    established,    this    parameter    becomes
|                      MIN_SEND_CREDIT.  In other calls when a circuit is
|                      running,  it  is  compared  to   SEND_CREDIT   and
|                      SEND_CREDIT   must  be  at  least  this  value  to
|                      succeed.
|  
|      SEND_CREDIT     credits extended  to  this  side  by  partner  for
|                      transmit  buffers.   Or  the  number  of  receives
|                      queued by the partner.
|  
|      MIN_SEND_CREDIT minimum number of credits a SYSAP expects to  have
|                      to  transmit to the other side.  In other words, a
|                      SYSAP expects to have this many buffers queued  as
|                      receives  by  its partner.  This is a constant for
|                      each connection and is established by the  partner
|                      SYSAP.
|  
|      REC_CREDITS     credits this side has extended to the  other  side
|                      to transmit.  The number of receives queued here.
|  
|      MIN_REC_CREDIT  minimum number of credits the other  side  expects
|                      to  have  to  transmit.   Or the minimum number of
|                      receives we will keep  queued  here.   This  is  a
|                      constant for each connection and is established by
|                      the SYSAP on this side.
|  
|      PEND_REC_CREDIT accumulated  number  of  credits  that  have  been
|                      queued  as receives here but have not been sent to
|                      the partner in a credit message.
|  
|      REQ_CREDIT      the number of credits sent in the last  CREDIT_REQ
|                      message.   This  cell  is used for the duration of
|                      the credit_req, _rsp pair to  enable  the  correct
|                      setting of RET_NULL.
|  
|      RET_CREDIT      number  of  credits  actually  obtained  from  the
|                      partner    or   deducted   on   this   side   from
|                      PEND_REC_CREDIT by cancel credit calls.   This  is
|                      the  count  of buffers that can be returned to the
|                      SYSAP caller requesting to cancel receives.
|  
|      RET_NULL        the number of cancel credit requests for which  no
|                      buffer  is  available  because  they have not been
|                      returned in a credit_rsp message  from  the  other
|                      side.
   SCS OPERATION                                                 Page 9-3


   9.4  SCS OPERATION DESCRIPTION

   The SCS process is described as expansions of the SCS interface  calls
   and as 2 subprocesses, SCS_SEND and SCS_REC.

   SCS_SEND sends SCS control request messages.  An  SCS  interface  call
   needing  the  SCS  request  message  service  queues  the  appropriate
   connection block on the appropriate path block.  The  path  block,  if
   not  already queued, is placed on the SCS_SEND_Q work queue.  SCS_SEND
   removes the path block from the work queue and sends a request message
   (using   the   local   message   buffer).   The  following  shows  the
   relationship of the data structures used by SCS_SEND:


                                           +-------+       
                                           |       |-----> next system
                                           |system |          block
                                           | block |
                                           |       |
                                           +-------+
                                               ^
                                               |
                                               |
                                               V
           +-------+       +-------+       +-------+       +-------+
   <-------|       |<------|       |<------|       |------>|       |
           |connect|       |connect|       | path  |       | local |
           | block |       | block |       | block |       |msg buf|
           |       |       |       |       |       |       |       |
           +-------+       +-------+       +-------+       +-------+
                                               |
                                               |
                                               |
                                               V
                                           next path
                                             block
   SCS OPERATION                                                 Page 9-4


   SCS_REC receives all incoming messages  and  datagrams  and  does  the
   following:

        1.  Processes and delivers SYSAP messages and datagrams;  DATREC;
            MDATREC;  DATCNF;  and MDATCNF responses.

        2.  Processes  SCS  request  control  messages  and   sends   the
            appropriate response.

        3.  Processes SCS response control  messages,  queues  the  local
            message buffer on the path block, and if the CB_Q in the path
            block is non-empty, queues the path block on  the  SCS_SEND_Q
            work queue.

        4.  Delivers IDREC responses.  If  the  IDREC  is  from  a  'new'
            system, calls START_VC to start the PPD virtual circuit.


   The focal points of SCS operation are the path and  connection  blocks
   that  are  modified by the SCS interface calls, SCS_SEND, and SCS_REC.
   It is assumed that modifications to a path and  connection  block  are
   synchronized  by some standard technique:  e.g.  all the modifications
   are done at the same IPL.
   SCS OPERATION                                                 Page 9-5


   9.5  TYPE, VARIABLE , FUNCTION, AND PROCEDURE DEFINITIONS

   The  following  PASCAL  definitions  apply  to   the   SCS   operation
   description.

   type
           SB = record { system block definition }
                   SB$NEXT_SB: SB_PTR;             { address of next SB }
                   SB$FIRST_PB: PB_INDEX;          { array index of first path block }
                   SB$DST_PORT_COUNT: WORD;        { number of interconnects to dst }
                   SB$DST_SYS: SYSTEM;             { destination system address }
                   SB$DST_MAX_DG: WORD;            { max. datagram size allowed }
                   SB$DST_MAX_MSG: WORD;           { max. message size allowed }
                   SB$DST_SW_TYPE: LONG;           { software type }
                   SB$DST_SW_VERSION: LONG;        { software version }
                   SB$DST_SW_INCAR: QUAD;          { software incarnation number }
                   SB$DST_HW_TYPE: LONG;           { hardware type }
                   SB$DST_HW_VERSION: SEPTA;       { hardware version }
                   SB$DST_NODE_NAME: QUAD          { ASCII node name }
                   end;


           PB = record { path block definition }
                   PB$NEXT_PB: PB_INDEX;           { index of next path block to system }
                   PB$SB: SB_INDEX;                { index of system block for this PB }
                   PB$DST_VC_STATE: VC_STATE;      { state of port-to-port virtual circuit }
                   PB$DST_PORT: PORT;              { destination port address }
                   PB$DG_Q: Q_BUF_PTR;             { datagram return queue }
                   PB$MSG_PTR: Q_BUF_PTR;          { scs control message pointer }
                   PB$CB_Q: CB_PTR;                { queue of CBs requiring SCS service }
                   PB$DST_PORT_CHAR: PORT_CHAR     { characteristics of remote port }
                   end;
                   

           B_STATE = ( { Connection block state for CB$BLOCK_STATE.  This field is used as
                         an opcode to SCS_SEND, which examines it to determine what type of 
                         control message to send. }
                   FREE,                           { connection block is unused }
                   ALLOC,                          { connection block is allocated }
                   CONNECT_PEND,                   { send a connect message }
                   ACCEPT_PEND,                    { send an accept message }
                   REJECT_PEND,                    { send a reject message }
                   CREDIT_PEND,                    { send a credit message }
                   DISCONNECT_PEND                 { send a disconnect message }
                   );

           
           CB = record { connection block }
                   CB$NEXT_CB: CB_PTR;             { address of next CB in queue }
                   CB$CONNECT_STATE: C_STATE;      { state of process-to-process connection }
                   CB$BLOCK_STATE: B_STATE;        { state of this connection block }
                   CB$SRC_CONNECT_ID: CONNECT_ID;  { id of local connection block }
                   CB$DST_CONNECT_ID: CONNECT_ID;  { id of remote connection block }
                   CB$SRC_PROC_NAME: PROC_NAME;    { local process name }
                   CB$DST_PROC_NAME: PROC_NAME;    { remote process name }
   SCS OPERATION                                                 Page 9-6


                   CB$CONNECT_DATA: C_DATA;        { connection data }
                   CB$SRC_REASON: WORD;            { local reason for reject or disconnect }
                   CB$DST_REASON: WORD;            { remote reason for reject or disconnect }
                   CB$SEND_CREDIT: WORD;           { number of available send credits }
                   CB$MIN_SEND_CREDIT: WORD;       { protocol threshold }
                   CB$REC_CREDIT: WORD;            { max. unused credits held by remote side }
                   CB$MIN_REC_CREDIT: WORD;        { min. send credits needed by remote side }
                   CB$PEND_REC_CREDIT: WORD;       { receive buffers queued, or cancels pending }
                   CB$REQ_CREDIT: WORD;            { credits sent but not acknowledged }
                   CB$RET_CREDIT: WORD;            { credits actually returned from remote side }
                   CB$RET_NULL: WORD;              { credits requested but not returned from remote side }
                   CB$DG_REC: WORD;                { number of datagram buffers queued }
                   CB$RESERVED: WORD;              { unused }
                   CB$DST_SB: SB_INDEX;            { system block for destination system }
                   CB$DST_PB: PB_INDEX;            { path block for interconnect to destination }
                   CB$DG_Q: Q_BUF_PTR;             { queue of DGREC responses }
                   CB$MSG_Q: Q_BUF_PTR;            { queue of MSGREC responses }
                   CB$READ_Q: Q_BUF_PTR;           { queue of DATREC responses }
                   CB$WRITE_Q: Q_BUF_PTR;          { queue of CNFREC responses }
                   CB$DG_RET_Q: Q_BUF_PTR;         { queue of DGSNT responses }
                   CB$MSG_RET_Q: Q_BUF_PTR         { queue of MSGSNT responses }
                   end;

           CB_Q_STATE = (FILLED,WAS_EMPTY,NOW_EMPTY); { connection block queue state }

           RSP_TYPE = (DGREC,DGSNT,MSGREC,MSGSNT,DATREC,CNFREC,
                           IDREC,MDATREC,MCNFREC); { PPD response type }


           START_DATA = packed array [1..36] of BYTE;

   var     CBA: array [1..MAX_CB] of CB;           { connection blocks }

           SBA: array [1..MAX_SB] of SB;           { system blocks }

           PBA: array [1..MAX_PB] of PB;           { path blocks }

           CUR_SB: WORD;                           { the highest current system list entry }

           CUR_PB: WORD;                           { the highest current path list entry }

           SCS_SEND_Q: SB_PTR;                     { SCS_SEND work queue }

   function ALLOC_CB(
           var CID:CONNECT_ID):
           boolean;
           
           begin

           { allocate connect block, initialize to zero,
           set CB$NEXT_CB to point to itself,
           set CB$BLOCK_STATE to ALLOC, and return CID:
           return true if block allocated; false otherwise }

           end;{ALLOC_CB}
   SCS OPERATION                                                 Page 9-7



   function CB_CLOSED( { test connection state }
           CID: CONNECT_ID):
           boolean;

           begin

           {return TRUE if connection is closed,
           return FALSE otherwise }

           end;{CB_CLOSED}

   procedure CHOOSE_PATH( { select path to system }
           ENTRY: SB_INDEX;
           var PATH: PB_INDEX);

           begin

           { select path over which connection to
           specified system is to be attempted. }

           end;{CHOOSE_PATH}

   function PBPTR_TO_PBINDEX(  { change pointer to index }
           PTR: PB_PTR): PB_INDEX;

           begin

           { calculate index from address pointer }

           end;{PBPTR_TO_PBINDEX}

   function NEXT_XID:
           WORD;

           begin

           { assign a new transaction number }

           end;{NEXT_XID}

   function CONNECT_MATCH(
           PTR: Q_BUF_PTR;
           var CNCT_INDEX: WORD):
           boolean;

           begin

           { search for connect block in LISTENING connect
           state which matches the connect request: set CB$DST_SB, CB$DST_PB }

           end;{CONNECT_MATCH}

   function INSERT_CB_Q(
           Q: CB_PTR;
   SCS OPERATION                                                 Page 9-8


           PTR: CB_PTR):
           CB_Q_STATE;

           begin

           { insert entry whose address is PTR in queue Q:
           return WAS_EMPTY if queue was previously empty;
           FILLED otherwise }

           end;

   function REMOVE_CB_Q(
           Q: CB_PTR;
           var PTR: CB_PTR):
           CB_Q_STATE;

           begin

           { remove entry from queue Q and return address in
           PTR : return NOW_EMPTY if queue is now empty;
           FILLED otherwise }

           end;

   procedure INSERT_SCS_Q(
           INDEX: PB_INDEX);
           
           begin

           { insert path block identified by INDEX
           on the SCS_SEND_Q work queue }

           end;{INSERT_SCS_Q}
           
   function REMOVE_SCS_Q(
           var PTR: PB_PTR):
           boolean;
           
           begin

           { remove an entry from the SCS_SEND_Q work queue and return
           its address in PTR: return true if entry removed;
           false otherwise }

           end;{REMOVE_SCS_Q}
           
   procedure INSERT(
           Q: Q_BUF_PTR;
           PTR: Q_BUF_PTR);

           begin

           { insert entry whose address is PTR in queue Q }

           end;{INSERT}
   SCS OPERATION                                                 Page 9-9



   function REMOVE(
           Q: Q_BUF_PTR;
           var PTR: Q_BUF_PTR):
           boolean;

           begin

           { remove entry from queue Q and return address of
           entry in PTR: return true if entry removed;
           false otherwise }

           end;{REMOVE}
           {SCSDEF}
   SCS OPERATION                                                Page 9-10


   9.6  CONFIGURATION SERVICE

   9.6.1  System Block

   The system list is a data structure built and maintained  by  the  PPD
   layer  and  used  by  the  SCS  layer.  An entry on the system list is
   termed  a  system  block.   A  representative  system  block  has  the
   following format:

                    3
                    1                             0
                   +-------------------------------+
                   |            NEXT_SB            |
                   +---------------+---------------+
                   |DST_PORT_COUNT |FIRST_PB_INDEX |
                   +-------------------------------+               
                   |               |   RESERVED    |
                   |               +---------------+
                   |           DST_SYS             |
                   +---------------+---------------+
                   | DST_MAX_MSG   | DST_MAX_DG    |
                   +---------------+---------------+
                   |         DST_SW_TYPE           |
                   +-------------------------------+
                   |        DST_SW_VERSION         |
                   +-------------------------------+
                   |       DST_SW_INCARNATION      |
                   |                               |
                   +-------------------------------+
                   |         DST_HW_TYPE           |
                   +-------------------------------+
                   |                               |
                   =        DST_HW_VERSION         =
                   |                               |
                   +-------------------------------+
                   |           NODE_NAME           |
                   |                               |
                   +-------------------------------+


   where:

       NEXT_SB         the address of the next system block  on  the  the
                       SCS_SEND_Q.

       FIRST_PB_INDEX  path block index of the first path block for  this
                       system.

       DST_PORT_COUNT  number of paths to the destination system.

       RESERVED        reserved word.

       DST_SYS         the destination system.
   SCS OPERATION                                                Page 9-11


       DST_MAX_DG      the maximum datagram size (in bytes) supported  by
                       the system.

       DST_MAX_MSG     the maximum message size (in bytes)  supported  by
                       the system.

       DST_SW_TYPE     the 4-character ASCII type of the software in  the
                       system.

       DST_SW_VERSION  the  4-character  ASCII  version  number  of   the
                       software in the system.

       DST_SW_INCARNATION  (8  bytes)  the  incarnation  number  of   the
                       software in the system.

       DST_HW_TYPE     the type of system hardware.
|  
|      DST_HW_VERSION  (12  bytes)  the  version  number  of  the  system
|                      hardware.

       NODE_NAME       (8 bytes) the ASCII node name of the system.
   SCS OPERATION                                                Page 9-12


   9.6.2  Path Block

   The path block is a data  structure  containing  information  about  a
   single   system-to-system   path.    That  is,  it  describes  one  of
   potentially several ports to a destination system.

                    3
                    1                              0
                   +-------------------------------+
                   |      SB       |   NEXT_PB     |
                   +-------------------------------+
                   |               | DST_VC_STATE  |
                   |               +---------------|
                   |          DST_PORT             |
                   +-------------------------------+
                   |              DG_Q             |
                   +-------------------------------+
                   |            MSG_PTR            |
                   +-------------------------------+
                   |             CB_Q              |
                   +---------------+---------------+
                   |                               |
                   =         DST_PORT_CHAR         =
                   |                               |
                   +-------------------------------+


       NEXT_PB         path  block  index  of  the  next  path   to   the
                       destination system.

       SB              system block index of the system  block  to  which
                       this path block is queued.

       DST_VC_STATE    the  state  of  the   virtual   circuit   to   the
                       destination port.

       DST_PORT        the destination system port address.

       DG_Q            the  datagram   return   queue   for   maintenance
                       operations.

       MSG_PTR         the address of the local message buffer associated
                       with the port-to-port virtual circuit.

       CB_Q            the queue  of  connection  blocks  of  connections
                       requiring SCS control message service.

       DST_PORT_CHAR   the characteristics of the destination port.
   SCS OPERATION                                                Page 9-13


   9.6.3  Configuration Services


|  REQ_ID REMOVED

   function CONFIG_SYS(
           ENTRY: SB_INDEX;
           var FIRST_PB: PB_INDEX;
           var SYS: SYSTEM;
           var MAX_DG: WORD;
           var MAX_MSG: WORD;
           var SW_TYPE: LONG;
           var SW_VERSION: LONG;
           var SW_INCARNATION: QUAD;
           var HW_TYPE: LONG;
           var HW_VERSION: SEPTA;
           var NODE_NAME: QUAD;
           var PORT_COUNT: WORD):
           FSTATUS;

           { Return information about destination SYSTEM from the
           specified System Block. }

           begin
           if ENTRY <= CUR_SB then with SBA[ENTRY] do
                   begin
                   FIRST_PB:=SB$FIRST_PB;
                   SYS:=SB$DST_SYS;
                   MAX_DG:=SB$DST_MAX_DG;
                   MAX_MSG:=SB$DST_MAX_MSG;
                   SW_TYPE:=SB$DST_SW_TYPE;
                   SW_VERSION:=SB$DST_SW_VERSION;
                   SW_INCARNATION:=SB$DST_SW_INCAR;
                   HW_TYPE:=SB$DST_HW_TYPE;
                   HW_VERSION:=SB$DST_HW_VERSION;
                   NODE_NAME:=SB$DST_NODE_NAME;
                   PORT_COUNT:=SB$DST_PORT_COUNT;
                   CONFIG_SYS:=SUCCESS
                   end
           else CONFIG_SYS:=FAIL
           end;{CONFIG_SYS}


   function CONFIG_PATH(
           ENTRY: PB_INDEX;
           var STATE: VC_STATE;
           var PRT: PORT;
           var NEXT_PB: PB_INDEX;
           var SB: SB_INDEX;
           var CHAR: PORT_CHAR):
           FSTATUS;

           { Return information about the specified INTERCONNECT
           from the specified Path Block. }
   SCS OPERATION                                                Page 9-14


           begin
           if ENTRY <= CUR_PB then with PBA[ENTRY] do
                   begin
                   STATE:=PB$DST_VC_STATE;
                   PRT:=PB$DST_PORT;
                   NEXT_PB:=PB$NEXT_PB;
                   SB:=PB$SB;
                   CHAR:=PB$DST_PORT_CHAR;
                   CONFIG_PATH:=SUCCESS
                   end
           else CONFIG_PATH:=FAIL
           end;{CONFIG_PATH}
   SCS OPERATION                                                Page 9-15


   9.7  CONNECTION MANAGEMENT SERVICE

   9.7.1  Connection Block

   A representative connection block has the following format:
   SCS OPERATION                                                Page 9-16



                    3
                    1                             0
                   +-------------------------------+
                   |            NEXT_CB            |
                   +---------------+---------------+
                   |  BLOCK_STATE  | CONNECT_STATE |
                   +---------------+---------------+
                   |         SRC_CONNECT_ID        |
                   +-------------------------------+
                   |         DST_CONNECT_ID        |
                   +-------------------------------+
                   |                               |
                   =         SRC_PROC_NAME         =
                   |                               |
                   +-------------------------------+
                   |                               |
                   =         DST_PROC_NAME         =
                   |                               |
                   +-------------------------------+
                   |                               |
                   =          CONNECT-DATA         =
                   |                               |
                   +---------------+---------------+
                   |   DST_REASON  |  SRC_REASON   |
                   +---------------+---------------+
                   |MIN_SEND_CREDIT|  SEND_CREDIT  |
                   +---------------+---------------+
                   |MIN_REC_CREDIT |  REC_CREDIT   |
                   +---------------+---------------+
                   |  REQ_CREDIT   |PEND_REC_CREDIT|
                   +---------------+---------------+
                   |    RET_NULL   |  RET_CREDIT   |
                   +---------------+---------------+
                   |   RESERVED    |    DG_REC     |
                   +---------------+---------------+
                   |    DST_PB     |    DST_SB     |
                   +---------------+---------------+
                   |             DG_Q              |
                   +-------------------------------+
                   |             MSG_Q             |
                   +-------------------------------+
                   |            READ_Q             |
                   +-------------------------------+
                   |            WRITE_Q            |
                   +-------------------------------+
                   |            DG_RET_Q           |
                   +-------------------------------+
                   |            MSG_RET_Q          |
                   +-------------------------------+
   SCS OPERATION                                                Page 9-17


   where:

       NEXT_CB         the address of the next connection  block  on  the
                       SCS send queue.

       CONNECT_STATE   the connection state.

       BLOCK_STATE     the state of the connection block.

       SRC_CONNECT_ID  the connect id of the local connection block.

       DST_CONNECT_ID  the connect id of destination connection block.

       SRC_PROC_NAME   the process name of local process  allocating  the
                       connection block.

       DST_PROC_NAME   the process name of destination process.

       CONNECT_DATA    connection data.

       SRC_REASON      the local reject or disconnect reason.

       DST_REASON      the destination reject or disconnect reason.

       SEND_CREDIT     the number of available credits to send.

       MIN_SEND_CREDIT the SYSAP protocol threshold.

       REC_CREDIT      the upper bound  of  the  number  of  unused  send
                       credits held by the destination SYSAP process.

       MIN_REC_CREDIT  the minimum number of send credits needed  by  the
                       destination SYSAP process.

       PEND_REC_CREDIT if non-negative, the number of buffers  queued  to
                       receive  messages,  but  not  yet  credited to the
                       destination process;  otherwise  the  negative  of
                       the   number  of  cancels  not  yet  sent  to  the
                       destination process.

       REQ_CREDIT      the number of  credits  sent  to  the  destination
                       process  in a CREDIT_REQ, but not yet responded to
                       by a CREDIT_RSP.

       RET_CREDIT      the number of credits returned by the  destination
                       as specified in the CREDIT_RSP.

       RET_NULL        the number of credits requested to be returned  in
                       a   CREDIT   message   but  not  returned  in  the
                       CREDIT_RSP.

       DG_REC          the number  datagram  buffers  queued  to  receive
                       datagrams.
   SCS OPERATION                                                Page 9-18


       RESERVED        reserved word.

       DST_SB          system  block  corresponding  to  the  destination
                       system.

       DST_PB          path   block   on   which   this   connection   is
                       established.

       DG_Q            the queue of DGREC responses.

       MSG_Q           the queue of MSGREC responses.

       READ_Q          the queue of DATREC responses.

       WRITE_Q         the queue of CNFREC responses.

       DG_RET_Q        the queue of DGSNT responses.

       MSG_RET_Q       the queue of MSGSNT response.
   SCS OPERATION                                                Page 9-19


   9.7.2  Connection States

|  A  connection  exists  in  1  of  several  states:   CLOSED,   LISTEN,
|  CONNECT_SENT,   CONNECT_ACK,  CONNECT_REC,  ACCEPT_SENT,  REJECT_SENT,
|  OPEN, DISCONNECT_SENT, DISCONNECT_REC, DISCONNECT_ACK, and  DISCONNECT
|  MATCH.  Events cause transitions between states.  An event is either a
|  connection  management  function  call  or  receipt  of  a  connection
|  management control message.
|  
|  The connection state table follows:
|  
|  Current           Event                      Action               New
|  State                                                            State
|  
|  CLOSED          LISTEN call                     -               LISTENING
|                  CONNECT call            send CONNECT_REQ        CONNECT_SENT
|                  *rcv CONNECT_REQ        send CONNECT_RSP        CLOSED
|                                          with NO_MATCH
|                  *rcv ACCEPT_REQ         send ACCEPT_RSP         CLOSED
|                                          with NO_MATCH
|                  DISCONNECT call         nop                     CLOSED
|  
|  LISTENING       rcv CONNECT_REQ         send CONNECT_RSP        CONNECT_REC
|  
|                  DISCONNECT call         cancel listen           CLOSED
|  
|  CONNECT_SENT    rcv CONNECT_RSP
|                  with SUCCESS            await ACCEPT or         CONNECT_ACK
|                                          REJECT
|                  with NO_MATCH                   -               CLOSED
|                  with NO_RESOURCES               -               CLOSED
|  
|                  DISCONNECT call         return success on       CLOSED
|                                          DISCONNECT, abort on
|                                          CONNECT
|  
|  CONNECT_ACK     rcv REJECT_REQ          send REJECT_RSP         CLOSED
|                  rcv ACCEPT_REQ          send ACCEPT_RSP         OPEN
|                  DISCONNECT call                 -               CLOSED
|  
|  CONNECT_REC     ACCEPT call             send ACCPET_REQ         ACCEPT_SENT
|                  REJECT call             send REJECT_REQ         REJECT_SENT
|                  DISCONNECT call         send REJECT_REQ         REJECT_SENT
|  
|  ACCEPT_SENT     rcv ACCEPT_RSP
|                  with SUCCESS                    -               OPEN
|                  with DISCONNECTED               -               CLOSED
|  
|                  DISCONNECT call         SUCCESS on DISCONNECT   CLOSED
|  
|                                          ABORT on ACCEPT
|  
|  REJECT_SENT     rcv REJECT_RSP                  -               CLOSED
|  
|                  DISCONNECT call         SUCCESS on DISCONNECT   CLOSED
   SCS OPERATION                                                Page 9-20


|                                          SUCCESS on REJECT
|  
|  OPEN            DISCONNECT call         send DISCONNECT_REQ     DISCONNECT_SENT
|                  rcv DISCONNECT_REQ      send DISCONNECT_RSP     DISCONNECT_REC
|  
|  DISCONNECT_SENT rcv DISCONNECT_REQ      send DISCONNECT_RSP     DISCONNECT_MATCH
|                  rcv DISCONNECT_RSP              -               DISCONNECT_ACK
|  
|                  DISCONNECT call         SUCCESS on both         CLOSED
|                                          DISCONNECTs
|  
|  DISCONNECT_REC  DISCONNECT call         Send DISCONNECT_REQ     DISCONNECT_MATCH
|  
|  DISCONNECT_ACK  rcv DISCONNECT_REQ      send DISCONNECT_RSP     CLOSED
|  
|                  DISCONNECT call         SUCCESS on both         CLOSED
|                                          DISCONNECTs
|  
|  
|  DISCONNECT_MATCH
|                  rcv DISCONNECT_RSP              -               CLOSED
|  
|                  DISCONNECT call         SUCCESS on both         CLOSED
|                                          DISCONNECTs
|  
|  
|  
|  any non-CLOSED  close port/port VC            -                 CLOSED
|  
|  any state       any inappropriate       close port/port VC      CLOSED
|                  event
|  

   The reason that ACCEPT/REJECT are separated  from  CONNECT_RSP  is  to
   allow  a  system  to  initiate  a potentially time consuming operation
   (e.g.  process creation)  in  response  to  an  incoming  CONNECT_REQ.
   DISCONNECT_ACK and DISCONNECT_MATCH states are used to ensure that (1)
   both sides wait until the passive SYSAP issues a  DISCONNECT  request,
   and  (2)  both  sides  have  acknowledged  that  they  know the second
   DISCONNECT was issued.  At that point, no  further  transfer  requests
   can  be issued by either side.  To ensure that all messages in transit
   when the DISCONNECT was issed have completed before the connection  is
   closed,  all  disconnect messages should be sent at lowest priority on
   ports that implement multiple priority messages.
   SCS OPERATION                                                Page 9-21


   9.7.3  Connect


|  function CONNECT(
|          var CID: CONNECT_ID;
|          SRC_PROC: PROC_NAME;
|          DST_PROC: PROC_NAME;
|          DST: SB_INDEX;
|          THRSH: WORD;
|          { [CREDITS: Q_BUF_PTR];... }
|          DATA: C_DATA
|          { [PATH: PB_INDEX] }
|          ):
|          FSTATUS;
|          
|          begin
|  
|           { Allocate a connection block, fill in appropriate fields, and place
|           on SCS work queue for processing. }
|  
|          if ALLOC_CB(CID) then with CBA[CID.INDEX] do 
|                  begin
|                  CB$CONNECT_STATE:=CLOSED;
|                  CB$BLOCK_STATE:=CONNECT_PEND;
|                  CB$SRC_CONNECT_ID:=CID;
|                  CB$SRC_PROC_NAME:=SRC_PROC;
|                  CB$DST_PROC_NAME:=DST_PROC;
|                  CB$CONNECT_DATA:=DATA;
|                  CB$MIN_SEND_CREDIT:=THRSH;
|                  { CB$PEND_REC_CREDIT:= count of CREDITS;
|                  queue buffers with INSERT_MFREEQ }
|                  CB$DST_SB:=DST;
|                  
|                   { Select a path to destination and store path block index 
|                   in CB. Insert CB on connection queue in chosen path block.
|                   If queue is currently empty, then place the PB on
|                   the SCS work queue for processing. }
|  
|                  CHOOSE_PATH(DST,CB$DST_PB); 
|                  if INSERT_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB) = WAS_EMPTY
|                          then INSERT_SCS_Q(CB$DST_PB);
|                  CONNECT:=SUCCESS
|                  end
|          else CONNECT:=FAIL
|          end;{CONNECT}
   SCS OPERATION                                                Page 9-22


   9.7.4  Listen


|  function LISTEN(
|          var CID: CONNECT_ID;
|          SRC_PROC: PROC_NAME;
|          DST_PROC: PROC_NAME;
|          DST: SB_INDEX ):
|          FSTATUS;
|          
|          { Allocate a connection block and initialize fields to
|          indicate waiting for matching connection request. }
|          
|          begin
|          if ALLOC_CB(CID) then with CBA[CID.INDEX] do
|                  begin
|                  CB$CONNECT_STATE:=LISTENING;
|                  CB$SRC_CONNECT_ID:=CID;
|                  CB$SRC_PROC_NAME:=SRC_PROC;
|                  CB$DST_PROC_NAME:=DST_PROC;
|                  CB$DST_SB:=DST;
|                  LISTEN:=SUCCESS
|                  end
|          else LISTEN:=FAIL
|          end{LISTEN};



   9.7.5  Accept


|  procedure ACCEPT(
|          CID: CONNECT_ID;
|          { [CREDITS: Q_BUF_PTR];...}
|          THRSH : WORD;
|          DATA: C_DATA);
|          
|          { Accept a connection request.  Set CB$BLOCK_STATE for SCS_SEND
|          process and insert PB on work queue.  Queue some message buffers
|          so credits can be extended.}
|  
|          begin with CBA[CID.INDEX] do
|                  begin
|                  CB$BLOCK_STATE:=ACCEPT_PEND;
|                  CB$CONNECT_DATA:=DATA;
|                  { CB$PEND_REC_CREDIT:= count of CREDITS;
|                  queue buffers with INSERT_MFREEQ }
|                  CB$MIN_SEND_CREDIT:=THRSH;
|                  if INSERT_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB) = WAS_EMPTY
|                                  then INSERT_SCS_Q(CB$DST_PB);
|                  end
|          end;{ACCEPT}
   SCS OPERATION                                                Page 9-23


   9.7.6  Reject


   procedure REJECT(
           CID: CONNECT_ID;
           REASON: WORD);
           
           { Reject a connection request.  Set CB$BLOCK_STATE for SCS_SEND
           process, note reason for rejection, and queue PB for processing. }

           begin with CBA[CID.INDEX] do
                   begin
                   CB$BLOCK_STATE:=REJECT_PEND;
                   CB$SRC_REASON:=REASON;
                   if INSERT_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB) = WAS_EMPTY
                                   then INSERT_SCS_Q(CB$DST_PB);
                   end
           end;{REJECT}



   9.7.7  Disconnect

   procedure DISCONNECT(
           CID: CONNECT_ID;
           REASON: WORD);

           { Disconnect the connection.  First, check to see if 
           the connection is in operation.  If so, transmit the 
           DISCONNECT_REQ message and move to DISCONNECT_SENT state.
           Otherwise, disconnection has already begun due to remote
           disconnect request.  Move to DISCONNECT_MATCH state and send
           DISCONNECT_REQ message to notify the other side that local
           SYSAP has disconnected.  Set connection state, set block
           state for SCS_SEND, and insert PB if needed for sending. }

           begin
           with CBA[CID.INDEX] do
               begin
               case  CB$CONNECT_STATE of

               OPEN:
                   begin
                   CB$CONNECT_STATE := DISCONNECT_SENT;
                   CB$BLOCK_STATE := DISCONNECT_PEND
                   end;

               DISCONNECT_REC:
                   begin
                   CB$CONNECT_STATE := DISCONNECT_MATCH;
                   CB$BLOCK_STATE := DISCONNECT_PEND
                   end;

               CONNECT_REC:
                   begin
   SCS OPERATION                                                Page 9-24


                   CB$CONNECT_STATE := REJECT_SENT;
                   CB$BLOCK_STATE := REJECT_PEND
                   end;

               OTHERWISE
                   begin
                   CB$CONNECT_STATE := CLOSED;
                   CB$BLOCK_STATE := FREE
                   end;

               end;
               CB$SRC_REASON:=REASON;
               if INSERT_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB) = WAS_EMPTY
                       then INSERT_SCS_Q(CB$DST_PB)
               end;
           end;{DISCONNECT}



   9.7.8  State Poll


   procedure STATE_POLL(
           CID: CONNECT_ID;
           var STATE: C_STATE;
           var DST_CID: CONNECT_ID;
           var DST_PROC: PROC_NAME;
           var DST_SB: SB_INDEX;
           var DST_PB: PB_INDEX;
           var DATA: C_DATA;
           var REASON: WORD);
           
           { Return the state of a process-to-process connection}

           begin with CBA[CID.INDEX] do
                   begin
                   STATE:=CB$CONNECT_STATE;
                   DST_CID:=CB$DST_CONNECT_ID;
                   DST_PROC:=CB$DST_PROC_NAME;
                   DST_SB:=CB$DST_SB;
                   DST_PB:=CB$DST_PB;
                   DATA:=CB$CONNECT_DATA;
                   REASON:=CB$DST_REASON
                   end
           end;{STATE_POLL}
   SCS OPERATION                                                Page 9-25


   9.8  DATAGRAM SERVICE

   9.8.1  Send Datagram


   function SEND_DG(
           CID: CONNECT_ID;
           RET_FLAG: boolean;
           DLEN: APPL_DG_LEN;
           PTR: Q_BUF_PTR):
           FSTATUS;
           
           { Check to see that connection is still open.  Fill in SCS header 
           information and call PPD send datagram. }

           begin with CBA[CID.INDEX] do 
                   if CB_CLOSED(CID) then SEND_DG:=NOT_OPEN else
                   begin
                   if not RET_FLAG then CB$DG_REC:=CB$DG_REC+1;
                   PTR^.LENGTH:=DLEN+AP_DG_HDR_LEN;
                   PTR^.SCS_TYPE:=APPL_DG;
                   PTR^.CREDIT:=0;
                   PTR^.REC_CONNECT_ID:=CB$DST_CONNECT_ID;
                   PTR^.SEND_CONNECT_ID:=CB$SRC_CONNECT_ID;
                   SNDDG(CB$DST_PB,RET_FLAG,PTR);
                   SEND_DG:=SUCCESS
                   end
           end;{SEND_DG}



   9.8.2  Send Datagram Poll


   function SEND_DG_POLL(
           CID: CONNECT_ID;
           var PTR: Q_BUF_PTR):
           FSTATUS;

           { Check datagram return queue for datagram transmission buffer
           from previous send. }

           begin with CBA[CID.INDEX] do
                   if REMOVE(CB$DG_RET_Q,PTR) then
                           SEND_DG_POLL:=SUCCESS
                   else SEND_DG_POLL:=FAIL
           end;{SEND_DG_POLL}
   SCS OPERATION                                                Page 9-26


   9.8.3  Receive Datagram


   function REC_DG(
           CID: CONNECT_ID;
           PTR: Q_BUF_PTR):
           FSTATUS;
           
           { Queue a buffer to the datagram receive queue. }

           begin with CBA[CID.INDEX] do
                   if CB_CLOSED(CID) then REC_DG:=NOT_OPEN else
                   begin
                   CB$DG_REC:=CB$DG_REC+1;
                   INSERT_DFREEQ(PTR);
                   REC_DG:=SUCCESS;
                   end
           end;{REC_DG}



   9.8.4  Receive Datagram Poll


   function REC_DG_POLL(
           CID: CONNECT_ID;
           var DLEN: APPL_DG_LEN;
           var PTR: Q_BUF_PTR):
           FSTATUS;

           { Check CB datagram queue and return datagram if any
           have been received. }

           begin with CBA[CID.INDEX] do if REMOVE(CB$DG_Q,PTR) then
                   begin
                   DLEN:=PTR^.LENGTH-AP_DG_HDR_LEN;
                   REC_DG_POLL:=SUCCESS
                   end
           else
                   REC_DG_POLL:=FAIL
           end;{REC_DG_POLL}
   SCS OPERATION                                                Page 9-27


   9.8.5  Cancel Receive Datagram


   function CANCEL_REC_DG(
           CID: CONNECT_ID;
           var PTR: Q_BUF_PTR):
           FSTATUS;
           
           { Return a queued datagram receive buffer.  Function FAILS if
           no buffers are queued for this connection or if the global
           queue is empty. }

           begin with CBA[CID.INDEX] do if CB$DG_REC > 0 then
                   if REMOVE_DFREEQ(PTR) = SUCCESS then
                           begin
                           CB$DG_REC:=CB$DG_REC-1;
                           CANCEL_REC_DG:=SUCCESS
                           end
                   else CANCEL_REC_DG:=FAIL
           else CANCEL_REC_DG:=FAIL
           end;{CANCEL_REC_DG}
   SCS OPERATION                                                Page 9-28


   9.9  SEQUENTIAL MESSAGE SERVICE

   9.9.1  Send Message


   function SEND_MSG(
           CID: CONNECT_ID;
           THRSH: WORD;
           RET_FLAG: boolean;
           MLEN: APPL_MSG_LEN;
           PTR: Q_BUF_PTR):
           FSTATUS;

           { Check that connection is operating.  Send Message if credits are 
           available. }
           
           begin with CBA[CID.INDEX] do 
               if CB_CLOSED(CID) then SEND_MSG:=NOT_OPEN 
               else if CB$SEND_CREDIT > THRSH then

               begin
                   CB$SEND_CREDIT:=CB$SEND_CREDIT-1;
                   
                   { If we're keeping this buffer, note one more credit to extend. }

                   if not RET_FLAG then CB$PEND_REC_CREDIT:=
                           CB$PEND_REC_CREDIT+1;

                   { If we have extra receive buffers to report, update estimated
                   unused credits held by destination (CB$REC_CREDIT), send
                   the outstanding credits by placing in message CREDIT field,
                   and zero PENDING_REC_CREDIT to note that we're up to date. }

                   if CB$PEND_REC_CREDIT > 0 then
                           begin
                           CB$REC_CREDIT:=CB$REC_CREDIT+CB$PEND_REC_CREDIT;
                           PTR^.CREDIT:=CB$PEND_REC_CREDIT;
                           CB$PEND_REC_CREDIT:=0;
                           end
                   else

                           { Otherwise, we have not reported some
                           cancelled buffers. }

                           begin
                           PTR^.CREDIT:=0;
                           CB$RET_CREDIT:=CB$RET_CREDIT+1
                           end;

                   { Fill in SCS header and transmit messge. }

                   PTR^.LENGTH:=AP_MSG_HDR_LEN+MLEN;
                   PTR^.SCS_TYPE:=APPL_MSG;
                   PTR^.REC_CONNECT_ID:=CB$DST_CONNECT_ID;
                   PTR^.SEND_CONNECT_ID:=CB$SRC_CONNECT_ID;
   SCS OPERATION                                                Page 9-29


                   SNDMSG(CB$DST_PB,RET_FLAG,PTR);
                   SEND_MSG:=SUCCESS
                   end
               else 
                   SEND_MSG:=FAIL
           end;{SEND_MSG}



   9.9.2  Send Message Poll


   function SEND_MSG_POLL(
           CID:CONNECT_ID;
           var PTR: Q_BUF_PTR):
           FSTATUS;

           { Check message return queue for received message }

           begin with CBA[CID.INDEX] do
                   if REMOVE(CB$MSG_RET_Q,PTR) then
                           SEND_MSG_POLL:=SUCCESS
                   else SEND_MSG_POLL:=FAIL
           end;{SEND_MSG_POLL}



   9.9.3  Receive Message


   function REC_MSG(
           CID: CONNECT_ID;
           PTR: Q_BUF_PTR):
           FSTATUS;
           
           { Receive message.  Check connection status, queue the supplied buffer,
           and note that there is one more credit for the connection. } 
           
           begin with CBA[CID.INDEX] do if CB_CLOSED(CID) 
               then REC_MSG:=NOT_OPEN 
               else
                   begin
                   REC_MSG:=SUCCESS;
                   INSERT_MFREEQ(PTR);
                   CB$PEND_REC_CREDIT:=CB$PEND_REC_CREDIT+1;

                   { If we were going to ask for credits back, note that we
                   got one back. }

                   if CB$PEND_REC_CREDIT <= 0 then
                           CB$RET_CREDIT:=CB$RET_CREDIT+1

                   { If remote side is below threshold, send credit message now. }

                   else if CB$REC_CREDIT <= CB$MIN_REC_CREDIT then
   SCS OPERATION                                                Page 9-30


                           begin
                           if CB$BLOCK_STATE = ALLOC then
                                   begin
                                   CB$BLOCK_STATE:=CREDIT_PEND;
                                   if INSERT_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB)
                                     = WAS_EMPTY then 
                                           INSERT_SCS_Q(CB$DST_PB);
                                   end
                           end
                   end
           end;{REC_MSG}



   9.9.4  Receive Message Poll


   function REC_MSG_POLL(
           CID: CONNECT_ID;
           var MLEN: APPL_MSG_LEN;
           var PTR: Q_BUF_PTR):
           FSTATUS;

           { Check for reception of a message.  Return buffer and data length. }

           begin with CBA[CID.INDEX] do if REMOVE(CB$MSG_Q,PTR) then
                   begin
                   MLEN:=PTR^.LENGTH-AP_MSG_HDR_LEN;
                   REC_MSG_POLL:=SUCCESS
                   end
           else
                   REC_MSG_POLL:=FAIL
           end;{REC_MSG_POLL}
   SCS OPERATION                                                Page 9-31


   9.9.5  Cancel Receive Message


   procedure CANCEL_REC_MSG(
           CID: CONNECT_ID);
           
           { Cancel a receive message request.  Note one less credit to send (or
           one more to take back).  If we're going to extend more credits then
           note that we got one back (increment CB$RET_CREDIT) so that user will
           get buffer back.  Otherwise, prepare CB so that credit message will
           be sent.  The buffer is returned by calling CANCEL_REC_MSG_POLL. }

           begin with CBA[CID.INDEX] do
                   begin
                   CB$PEND_REC_CREDIT:=CB$PEND_REC_CREDIT-1;
                   if CB$PEND_REC_CREDIT >= 0 then
                           CB$RET_CREDIT:=CB$RET_CREDIT+1
                   else
                           begin
                           if CB$BLOCK_STATE = ALLOC then
                                   begin
                                   CB$BLOCK_STATE:=CREDIT_PEND;
                                   if INSERT_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB)
                                     = WAS_EMPTY then 
                                           INSERT_SCS_Q(CB$DST_PB);
                                   end
                           end
                   end
           end;{CANCEL_REC_MSG}



   9.9.6  Cancel Receive Message Poll


   function CANCEL_REC_MSG_POLL(
           CID: CONNECT_ID;
           var PTR: Q_BUF_PTR):
           FSTATUS;
           
           { Request return of buffers cancelled by CANCEL_REC_MESSAGE.
           CB$RET_CREDIT indicates number of buffers that can be returned.
           CB$RET_NULL indicates number of cancels requested but credits not
           returned from remote side.  Status of NULL indicates that the
           cancel succeeded but the buffer can not be given back to the caller. }

           begin with CBA[CID.INDEX] do
                   begin
                   if CB$RET_CREDIT > 0 then
                           begin
                           CB$RET_CREDIT:=CB$RET_CREDIT-1;
                           CANCEL_REC_MSG_POLL:=REMOVE_MFREEQ(PTR)
                           end
                   else if CB$RET_NULL > 0 then
                           begin
   SCS OPERATION                                                Page 9-32


                           CB$RET_NULL:=CB$RET_NULL-1;
                           CANCEL_REC_MSG_POLL:=NULL
                           end
                   else CANCEL_REC_MSG_POLL:=FAIL
                   end
           end;{CANCEL_REC_MSG_POLL}
   SCS OPERATION                                                Page 9-33


   9.10  BLOCK DATA SERVICE

   9.10.1  Buffer Descriptor Table

   The buffer descriptor table is a data structure maintained by the  SCS
   layer  and  readable by the PPD layer.  The buffer descriptor table is
   referenced by buffer name and contains the length, address, and access
   control information for named buffers.

   A representative buffer  descriptor  table  entry  has  the  following
   format:


                    3                             
                    1                             0
                   +-------------------------------+
                   |          BUF_LENGTH           |
                   +-------------------------------+
                   |          BUF_ADDRESS          |
                   +-------------------------------+
                   |          BUF_ACCESS           |
                   +-------------------------------+



   where:

       BUF_LENGTH      the length of buffer.

       BUF_ADDR        the address of the buffer  and/or  buffer  mapping
                       tables.

       BUF_ACCESS      the buffer access control.
   SCS OPERATION                                                Page 9-34


   9.10.2  Map Buffer


   function MAP(
           {BLOCK_BUF: BUF_DESCR;}
           var NAME: LONG):
           FSTATUS;
           
           begin
           {fill in Buffer Descriptor Table entry
           end return buffer name}
           end;{MAP}



   9.10.3  Unmap Buffer


   procedure UNMAP(
           NAME: LONG);
           
           begin
           {invalidate name and free Buffer Descriptor
           Table entry}
           end;{UNMAP}



   9.10.4  Read


   function READ(
           CID: CONNECT_ID;
           THRSH: WORD;
           PTR: Q_BUF_PTR;
           var XID: WORD):
           FSTATUS;
           
           { Request block data transfer from destination.  First check for
           connection condition and sufficient credits to perform operation. 
           Assign a new transaction number for this transaction and return
           it to caller. }

           begin with CBA[CID.INDEX] do if CB_CLOSED(CID) 
               then READ:=NOT_OPEN 
               else if CB$SEND_CREDIT > THRSH then
                   begin
                   CB$SEND_CREDIT:=CB$SEND_CREDIT-1;
                   PTR^.SEND_BLOCK_ID:=CID.INDEX;
                   XID:=NEXT_XID;
                   PTR^.SEND_XID:=XID;
                   REQDAT(CB$DST_PB,PTR);
                   READ:=SUCCESS
                   end
           else READ:=FAIL
   SCS OPERATION                                                Page 9-35


           end;{READ}



   9.10.5  Read Poll


   function READ_POLL(
           CID: CONNECT_ID;
           var PTR: Q_BUF_PTR;
           var XID: WORD):
           FSTATUS;
           
           { Check for completion of read block transfer. }

           begin with CBA[CID.INDEX] do if REMOVE(CB$READ_Q,PTR) then
                   begin
                   XID:= PTR^.SEND_XID;
                   READ_POLL:=SUCCESS;
                   end
           else READ_POLL:=FAIL;
           end{READ_POLL};



   9.10.6  Write


   function WRITE(
           CID: CONNECT_ID;
           THRSH: WORD;
           PTR: Q_BUF_PTR;
           var XID: WORD):
           FSTATUS;
           
           { Request block data transfer to destination system. Verify that
           connection is open, assign a new transaction number, and call
           PPD routine to perform the transfer. }

           begin with CBA[CID.INDEX] do if CB_CLOSED(CID) 
               then WRITE:=NOT_OPEN 
               else if CB$SEND_CREDIT > THRSH then
                   begin
                   CB$SEND_CREDIT:=CB$SEND_CREDIT-1;
                   PTR^.SEND_BLOCK_ID:=CID.INDEX;
                   XID:=NEXT_XID;
                   PTR^.SEND_XID:=XID;
                   SNDDAT(CB$DST_PB,PTR);
                   WRITE:=SUCCESS
                   end
           else WRITE:=FAIL
           end;{WRITE}
   SCS OPERATION                                                Page 9-36


   9.10.7  Write Poll


   function WRITE_POLL(
           CID: CONNECT_ID;
           var PTR: Q_BUF_PTR;
           var XID: WORD):
           FSTATUS;
           
           { Check for completion of write block transfer. }

           begin with CBA[CID.INDEX] do if REMOVE(CB$WRITE_Q,PTR) then
                   begin
                   XID:=PTR^.SEND_XID;
                   WRITE_POLL:= SUCCESS
                   end
           else WRITE_POLL:=FAIL
           end{WRITE_POLL};
   SCS OPERATION                                                Page 9-37


   9.11  SCS SEND

|  procedure SCS_SEND; {PROCESS}
|  
|          var     PTR: PB_PTR;
|  
|          { SCS work queue process to send SCS command messages.  Path blocks
|          are queued to the work queue when a command is to be sent for
|          a connection.  The CB$BLOCK_STATE field of the first connect
|          block queued to the PB specifies the work to be performed.
|          A control message is constructed in the single SCS command buffer
|          queued to the path block (PB), and the message is transmitted. }
|  
|          begin
|          
|          { Get next path block address in PTR.  Dispatch on block state. }
|  
|          while REMOVE_SCS_Q(PTR) do with PTR^ do begin
|          case PB$CB_Q^.CB$BLOCK_STATE of
|  
|          CONNECT_PEND:
|  
|                  { Prepare Connect Request Message.  Fill in number of credits
|                  now available (CB$PEND_REC_CREDIT) and the minimum number
|                  of credits needed by destination (CB$MIN_REC_CREDIT). }
|  
|                  begin
|                  PB$MSG_PTR^.LENGTH:=CONNECT_REQ_LEN;
|                  PB$MSG_PTR^.SCS_TYPE:=CONNECT_REQ;
|                  PB$MSG_PTR^.CREDIT:=PB$CB_Q^.CB$PEND_REC_CREDIT;
|                  { Update CB to note credits extended }
|                  PB$CB_Q^.CB$PEND_REC_CREDIT:=0;
|                  PB$MSG_PTR^.MIN_CREDIT:=PB$CB_Q^.CB$MIN_REC_CREDIT;
|                  PB$MSG_PTR^.STATUS:=0;
|                  PB$MSG_PTR^.REC_PROC:=PB$CB_Q^.CB$DST_PROC_NAME;
|                  PB$MSG_PTR^.SEND_PROC:=PB$CB_Q^.CB$SRC_PROC_NAME;
|                  PB$MSG_PTR^.SEND_DATA:=PB$CB_Q^.CB$CONNECT_DATA;
|                  PB$CB_Q^.CB$CONNECT_STATE:=CONNECT_SENT
|                  end;
|  
|          ACCEPT_PEND:
|  
|                  { Prepare Accept message.  Fill in number of credits
|                  now available (CB$PEND_REC_CREDIT) and the minimum number
|                  of credits needed by destination (CB$MIN_REC_CREDIT). }
|  
|                  begin
|                  PB$MSG_PTR^.LENGTH:=ACCEPT_REQ_LEN;
|                  PB$MSG_PTR^.SCS_TYPE:=ACCEPT_REQ;
|                  PB$MSG_PTR^.CREDIT:=PB$CB_Q^.CB$PEND_REC_CREDIT;
|                  { Update CB to note credits extended }
|                  PB$CB_Q^.CB$PEND_REC_CREDIT:=0;
|                  PB$MSG_PTR^.MIN_CREDIT:=PB$CB_Q^.CB$MIN_REC_CREDIT;
|                  PB$MSG_PTR^.STATUS:=0;
|                  PB$MSG_PTR^.REC_PROC:=PB$CB_Q^.CB$DST_PROC_NAME;
   SCS OPERATION                                                Page 9-38


|                  PB$MSG_PTR^.SEND_PROC:=PB$CB_Q^.CB$SRC_PROC_NAME;
|                  PB$MSG_PTR^.SEND_DATA:=PB$CB_Q^.CB$CONNECT_DATA;
|                  PB$CB_Q^.CB$CONNECT_STATE:=ACCEPT_SENT
|                  end;
|  
|          REJECT_PEND:
|  
|                  { Prepare Reject message with reason for rejection.
|                  Give no credits (adding insult to injury). }
|  
|                  begin
|                  PB$MSG_PTR^.LENGTH:=REJECT_REQ_LEN;
|                  PB$MSG_PTR^.SCS_TYPE:=REJECT_REQ;
|                  PB$MSG_PTR^.CREDIT:=0;
|                  PB$MSG_PTR^.MIN_CREDIT:=0;
|                  PB$MSG_PTR^.STATUS:=PB$CB_Q^.CB$SRC_REASON;
|                  PB$CB_Q^.CB$CONNECT_STATE:=REJECT_SENT
|                  end;
|  
|          DISCONNECT_PEND:
|  
|                  { Prepare Disconnect Request message. Connection state has 
|                  already been set to DISCONNECT_SENT or DISCONNECT_MATCH. }
|  
|                  begin
|                  PB$MSG_PTR^.LENGTH:=DISCON_REQ_LEN;
|                  PB$MSG_PTR^.SCS_TYPE:=DISCON_REQ;
|                  PB$MSG_PTR^.CREDIT:=0;
|                  PB$MSG_PTR^.MIN_CREDIT:=0;
|                  PB$MSG_PTR^.STATUS:=PB$CB_Q^.CB$SRC_REASON
|                  end;
|  
|          CREDIT_PEND:
|  
|                  { Prepare credit message. }
|  
|                  begin
|                  PB$MSG_PTR^.LENGTH:=CREDIT_REQ_LEN;
|                  PB$MSG_PTR^.SCS_TYPE:=CREDIT_REQ;
|                  PB$MSG_PTR^.CREDIT:=PB$CB_Q^.CB$PEND_REC_CREDIT;
|                  PB$CB_Q^.CB$REQ_CREDIT:=PB$CB_Q^.CB$PEND_REC_CREDIT;
|                  PB$CB_Q^.CB$PEND_REC_CREDIT:=0
|                  end;
|          end;
|  
|          { Now that message has been prepared, fill in source and 
|          destination connect ID and send the message. }
|  
|          PB$MSG_PTR^.REC_CONNECT_ID:=PB$CB_Q^.CB$DST_CONNECT_ID;
|          PB$MSG_PTR^.SEND_CONNECT_ID:=PB$CB_Q^.CB$SRC_CONNECT_ID;
|          { must convert PTR to a PB Index for SNDMSG call }
|          SNDMSG( PBPTR_TO_PBINDEX(PTR) , false , PB$MSG_PTR);
|          end;
|          end;{SCS_SEND}
   SCS OPERATION                                                Page 9-39


   9.12  SCS RECEIVE

|  procedure SCS_REC; {PROCESS}
|  
|          var     PTR: Q_BUF_PTR;
|                  RSP: RSP_TYPE;
|                  CNCT_INDEX: WORD;
|                  DST: PB_INDEX;
|          
|          { Process to handle reception of messages, datagrams, and command
|          responses.  There is a single SCS command buffer for each 
|          port-to-port virtual circuit.  Therefore, only one command can be
|          outstanding per path block.  The buffer is consumed when an SCS
|          command is transmitted.  When a response is received, the buffer
|          containing the response can be used to transmit another command.
|          This is done immediately if an immediate response is required.  
|          Otherwise, the buffer is queued to the PB, and if any other CBs
|          are waiting on the PB, the PB is queued to the send work queue
|          for service. }
|  
|          begin
|          while RSP_POLL(RSP,DST,PTR) = SUCCESS do case RSP of
|  
|          { PTR now has address of a buffer (Q_BUF_PTR)
|          that has been received.  Dispatch on the type
|          of response received.  If DGSNT or MSGSNT response,
|          insert buffer on DG or MSG response queue. }
|  
|          DGSNT:
|                  INSERT(CBA[PTR^.SEND_CONNECT_ID.INDEX].CB$DG_RET_Q,PTR);
|  
|          MSGSNT:
|                  INSERT(CBA[PTR^.SEND_CONNECT_ID.INDEX].CB$MSG_RET_Q,PTR);
|  
|  
|          DGREC:
|  
|          { Datagram received.  If receive queue has a buffer, insert
|          datagram on CB and note one less buffer available.  Otherwise,
|          return buffer to datagram receive queue. }
|  
|                  with CBA[PTR^.REC_CONNECT_ID.INDEX] do if CB$DG_REC > 0
|                          then
|                          begin
|                          CB$DG_REC:=CB$DG_REC-1;
|                          INSERT(CB$DG_Q,PTR)
|                          end
|                  else INSERT_DFREEQ(PTR);
|  
|          MSGREC:
|  
|          { Message received.  Locate CB for the message and dispatch
|          on the SCS message type. }
|  
|                  with CBA[PTR^.REC_CONNECT_ID.INDEX] 
   SCS OPERATION                                                Page 9-40


|                  DO case PTR^.SCS_TYPE of
|  
|                  { begin new case block }
|  
|                  CONNECT_REQ:
|  
|                  { Connect request recieved.  Check if this conect
|                  matches a pending Listen request.  If so, initialize
|                  credit and name fields.  Return the Connect Response
|                  message with proper status. }
|  
|                  begin
|                  if CONNECT_MATCH(PTR,CNCT_INDEX) then
|                          with CBA[CNCT_INDEX] do
|                          begin
|                          CB$CONNECT_STATE:=CONNECT_REC;
|                          CB$SEND_CREDIT:=PTR^.CREDIT;
|                          CB$DST_CONNECT_ID:=PTR^.SEND_CONNECT_ID;
|                          CB$DST_PROC_NAME:=PTR^.SEND_PROC;
|                          CB$MIN_REC_CREDIT:=PTR^.MIN_CREDIT;
|                          CB$CONNECT_DATA:=PTR^.SEND_DATA;
|                          PTR^.STATUS:=CONNECTED
|                          end
|                  else PTR^.STATUS:=NO_MATCH;
|                  PTR^.LENGTH:=CONNECT_RSP_LEN;
|                  PTR^.SCS_TYPE:=CONNECT_RSP;
|                  PTR^.CREDIT:=0;
|                  PTR^.REC_CONNECT_ID:=PTR^.SEND_CONNECT_ID;
|                  PTR^.SEND_CONNECT_ID:=CB$SRC_CONNECT_ID;
|                  PTR^.MIN_CREDIT:=0;
|                  SNDMSG(DST,false,PTR)
|                  end;
|                  
|                  CONNECT_RSP:
|  
|                  { Connect response received.  Note whether connect was 
|                  processed or no matching listen was found.  Restore the
|                  message buffer for this PB, remove CB from queue, and 
|                  reinsert PB on work queue if more CB's are waiting. }
|  
|                  begin
|                  if PTR^.STATUS = CONNECTED then
|                          CB$CONNECT_STATE:=CONNECT_ACK
|                  else
|                      begin
|                      CB$CONNECT_STATE:=CLOSED;
|                      CB$DST_REASON := PTR^.STATUS
|                      end;
|                  PBA[CB$DST_PB].PB$MSG_PTR:=PTR;
|                  if REMOVE_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB) <> NOW_EMPTY
|                          then INSERT_SCS_Q(CB$DST_PB);
|                  end;
|  
|                  ACCEPT_REQ:
|  
   SCS OPERATION                                                Page 9-41


|                  { Accept Request received.  Open connection and 
|                  initialize credit and connect data information.  Send
|                  The Accept Response message. }
|  
|                  begin
|                  CB$SEND_CREDIT:=PTR^.CREDIT;
|                  CB$MIN_REC_CREDIT:=PTR^.MIN_CREDIT;
|                  CB$CONNECT_STATE:=OPEN;
|                  CB$CONNECT_DATA:=PTR^.SEND_DATA;
|                  PTR^.LENGTH:=ACCEPT_RSP_LEN;
|                  PTR^.SCS_TYPE:=ACCEPT_RSP;
|                  PTR^.CREDIT:=0;
|                  PTR^.REC_CONNECT_ID:=PTR^.SEND_CONNECT_ID;
|                  PTR^.SEND_CONNECT_ID:=CB$SRC_CONNECT_ID;
|                  SNDMSG(DST,false,PTR)
|                  end;
|  
|                  ACCEPT_RSP:
|  
|                  { Accept Response message received.  Save our message buffer,
|                  remove CB from queue, and requeue PB if more to do for this
|                  path. }
|  
|                  begin
|                  CB$CONNECT_STATE:=OPEN;
|                  PBA[CB$DST_PB].PB$MSG_PTR:=PTR;
|                  if REMOVE_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB) <> NOW_EMPTY
|                          then INSERT_SCS_Q(CB$DST_PB);
|                  end;
|  
|                  REJECT_REQ:
|  
|                  { Reject Request received.  Close the channel, save the reject
|                  reason, and send the Reject Response message. }
|  
|                  begin
|                  CB$CONNECT_STATE:=CLOSED;
|                  CB$DST_REASON:=PTR^.STATUS;
|                  PTR^.LENGTH:=REJECT_RSP_LEN;
|                  PTR^.SCS_TYPE:=REJECT_RSP;
|                  PTR^.CREDIT:=0;
|                  PTR^.REC_CONNECT_ID:=PTR^.SEND_CONNECT_ID;
|                  PTR^.SEND_CONNECT_ID:=CB$SRC_CONNECT_ID;
|                  SNDMSG(DST,false,PTR)
|                  end;
|  
|                  REJECT_RSP:
|  
|                  { Reject Response received.  Save our SCS message buffer
|                  and check if more work for this PB. }
|  
|                  begin
|                  CB$CONNECT_STATE:=CLOSED;
|                  PBA[CB$DST_PB].PB$MSG_PTR:=PTR;
|                  if REMOVE_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB) <> NOW_EMPTY
   SCS OPERATION                                                Page 9-42


|                          then INSERT_SCS_Q(CB$DST_PB);
|                  end;
|  
|                  DISCON_REQ:
|  
|                  { Disconnect request received.  The connection can be in
|                  one of three states:  OPEN, DISCONNECT_SENT, or DISCONNECT_ACK.
|                  For each state, set the correct new state.  For OPEN or
|                  DISCONNECT_SENT states, a DISCONNECT_RSP message must
|                  be transmitted.  A DISCONNECT_REQ message received while in
|                  DISCONNECT_SENT state means that both SYSAPS initated 
|                  disconnection simultaneously.  If the connection is in 
|                  DISCONNECT_ACK  state, the connection is closed, the message 
|                  buffer is saved, and the queue is checked for more work. }
|  
|                  begin
|                  case CB$CONNECT_STATE of
|                      OPEN:  CB$CONNECT_STATE:=DISCONNECT_REC;
|                      DISCONNECT_SENT:  CB$CONNECT_STATE:=DISCONNECT_MATCH;
|                      DISCONNECT_ACK:  CB$CONNECT_STATE:=CLOSED
|                  end;
|                  
|                  if CB$CONNECT_STATE=CLOSED
|                  then
|                      begin
|                      PBA[CB$DST_PB].PB$MSG_PTR:=PTR;
|                      if REMOVE_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB) <>
|                          NOW_EMPTY then INSERT_SCS_Q(CB$DST_PB)
|                      end
|                  else
|                      begin
|                      CB$DST_REASON:=PTR^.STATUS;
|                      PTR^.LENGTH:=DISCON_RSP_LEN;
|                      PTR^.SCS_TYPE:=DISCON_RSP;
|                      PTR^.CREDIT:=0;
|                      PTR^.REC_CONNECT_ID:=PTR^.SEND_CONNECT_ID;
|                      PTR^.SEND_CONNECT_ID:=CB$SRC_CONNECT_ID;
|                      SNDMSG(DST,false,PTR)
|                      end
|                  end;
|  
|                  DISCON_RSP:
|  
|                  { Disconnect Response received.  The connection can be
|                  in one of two states.  If in DISCONNECT_SENT state, we initiated
|                  the disconnect, and now move to DISCONNECT_ACK to wait for
|                  the remote SYSAP to disconnect.  If in DISCONNECT_MATCH state,
|                  we're waiting for confirmation that the initator knows that
|                  we've received the passive SYSAP disconnect.  Here we close
|                  down the connection and look for more work to do. }
|  
|                  begin
|                  if CB$CONNECT_STATE = DISCONNECT_SENT
|                  then
|                      begin
   SCS OPERATION                                                Page 9-43


|                      CB$CONNECT_STATE:= DISCONNECT_ACK;
|                      CB$DST_REASON:=PTR^.STATUS;
|                      PTR^.LENGTH:=DISCON_RSP_LEN;
|                      PTR^.SCS_TYPE:=DISCON_RSP;
|                      PTR^.REC_CONNECT_ID:=PTR^.SEND_CONNECT_ID;
|                      PTR^.SEND_CONNECT_ID:=CB$SRC_CONNECT_ID;
|                      SNDMSG(DST,false,PTR)
|                      end
|                  else { CB$CONNECT_STATE = DISCONNECT_MATCH }
|                      begin
|                      CB$CONNECT_STATE:=CLOSED;
|                      PBA[CB$DST_PB].PB$MSG_PTR:=PTR;
|                      if REMOVE_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB) <>
|                          NOW_EMPTY then INSERT_SCS_Q(CB$DST_PB)
|                      end
|                  end;
|  
|                  CREDIT_REQ:
|  
|                  { Credit Request received.  Credit request can be positive
|                  (to indicate more credits) or negative (to take some back).
|                  If negative, only give back the minimum of the number 
|                  requested and the number available without going below
|                  the SCS threshold for this connection.  Return
|                  Credit Response message. }
|  
|                  begin
|                  if PTR^.CREDIT < 0 
|                      then PTR^.CREDIT:=
|                             -MIN(  MAX(0,CB$SEND_CREDIT-CB$MIN_SEND_CREDIT),
|                                    -PTR^.CREDIT);
|  
|                  { make positive or negative adjustment }
|  
|                  CB$SEND_CREDIT:=CB$SEND_CREDIT+PTR^.CREDIT;
|                  PTR^.LENGTH:=CREDIT_RSP_LEN;
|                  PTR^.SCS_TYPE:=CREDIT_RSP;
|                  PTR^.REC_CONNECT_ID:=PTR^.SEND_CONNECT_ID;
|                  PTR^.SEND_CONNECT_ID:=CB$SRC_CONNECT_ID;
|                  SNDMSG(DST,false,PTR)
|                  end;
|                  
|                  CREDIT_RSP:
|  
|                  { Credit Response received.  Adjust credit values for
|                  number actually returned, if credit return was requested.  }
|  
|                  begin
|                  if CB$REQ_CREDIT < 0 then
|                          begin
|                          CB$RET_CREDIT:=CB$RET_CREDIT-PTR^.CREDIT;
|                          CB$RET_NULL:=CB$RET_NULL+PTR^.CREDIT-CB$REQ_CREDIT;
|                          end;
|                  CB$REC_CREDIT:=CB$REC_CREDIT+PTR^.CREDIT;
|                  PBA[CB$DST_PB].PB$MSG_PTR:=PTR;
   SCS OPERATION                                                Page 9-44


|  
|                  { If credits are waiting to be taken back from the destination
|                  due to cancels, OR if there are buffers not credited AND
|                  the destination is below threshold, then insert this PB
|                  on the work queue to send the credit message. }
|  
|                  if (CB$PEND_REC_CREDIT < 0) or
|                  ((CB$PEND_REC_CREDIT > 0) and
|                          (CB$REC_CREDIT < CB$MIN_REC_CREDIT)) then
|                          INSERT_SCS_Q(CB$DST_PB)
|  
|                  { Otherwise, just check to see if there's anything else to do. }
|  
|                  else if REMOVE_CB_Q(PBA[CB$DST_PB].PB$CB_Q,CB$NEXT_CB) <>
|                          NOW_EMPTY then INSERT_SCS_Q(CB$DST_PB)
|                  end;
|  
|                  APPL_MSG:
|  
|                  { Application Message received.  Insert on message queue for
|                  this connection. }
|  
|                  begin
|                  CB$REC_CREDIT:=CB$REC_CREDIT-1;
|                  CB$SEND_CREDIT:=CB$SEND_CREDIT+PTR^.CREDIT;
|                  INSERT(CB$MSG_Q,PTR)
|                  end;
|  
|          end;{case PTR^.SCS_TYPE}
|  
|  
|          DATREC:
|                  with CBA[PTR^.SEND_BLOCK_ID] do begin
|                  INSERT(CB$READ_Q,PTR);
|                  CB$SEND_CREDIT:=CB$SEND_CREDIT+1;
|                  end;
|  
|          CNFREC:
|                  with CBA[PTR^.SEND_BLOCK_ID] do begin
|                  INSERT(CB$WRITE_Q,PTR);
|                  CB$SEND_CREDIT:= CB$SEND_CREDIT+1;
|                  end;
|  
|          IDREC:
|                  {if <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-45


|          end;{case RSP}
|          end;{SCS_REC}











                                 CHAPTER 10

                              CI PPD OPERATION



   The operation of  the  PPD  layer  is  port  specific.   This  section
   describes the operation of the CI PPD layer.



   10.1  PPD DATAGRAMS

   10.1.1  Start

   The START datagram is used to start  virtual  circuit  initialization.
   The format of START is:


                    3               1
                    1               5             0
                   +---------------+---------------+
                   |    PPD_TYPE   |    LENGTH     |
                   +---------------+---------------+
                   |                               |
                   =           START_DATA          =
                   |                               |
                   +-------------------------------+


   where:

       LENGTH          START_LEN.

       PPD_TYPE        START.

       START_DATA      start data.  See Appendix F.
   CI PPD OPERATION                                             Page 10-2


   10.1.2  Start Acknowledge

   The STACK datagram is used to acknowledge receipt  of  a  START.   The
   format of STACK is:


                    3               1
                    1               5             0
                   +---------------+---------------+
                   |    PPD_TYPE   |    LENGTH     |
                   +---------------+---------------+
                   |                               |
                   =           START_DATA          =
                   |                               |
                   +-------------------------------+


   where:

       LENGTH          STACK_LEN.

       PPD_TPE         STACK.

       START_DATA      start data.  See Appendix F.
   CI PPD OPERATION                                             Page 10-3


   10.1.3  Acknowledge

   The ACK datagram is used to acknowledge the receipt of a  STACK.   The
   format of ACK is:


                    3               1
                    1               5             0
                   +---------------+---------------+
                   |    PPD_TYPE   |    LENGTH     |
                   +---------------+---------------+



   where:

       LENGTH          ACK_LEN.

       PPD_TYPE        ACK.
   CI PPD OPERATION                                             Page 10-4


   10.2  START VIRTUAL CIRCUIT

   A  virtual  circuit  exists  in  one  of  four   states:    VC_CLOSED,
   START_SENT,  START_REC,  and  VC_OPEN.   The  state  is  stored in the
   appropriate system block.  Events cause  transitions  between  states.
   An   event   is  either  an  initialization  function  call,  a  timer
   expiration, or receipt of a virtual circuit initialization datagram.

   The initialization sequence is a standard 3-way handshake  (used,  for
   example, by DECNET/DNA DDCMP).

   The initialization state table follows:


   CURRENT STATE   EVENT           ACTION                  NEW STATE


   VC_CLOSED       START call      send START              START_SENT
                                   start timer

   START_SENT      rec STACK       open port VC            VC_OPEN
                                   send ACK
                                   stop timer

                   rec START       open port VC            START_REC
                                   send STACK
                                   start timer

                   timer expires   send START              START_SENT
                                   start timer

   START_REC       rec ACK         stop timer              VC_OPEN
                   rec SCS request stop timer              VC_OPEN
                   control message 

                   rec STACK       send ACK                VC_OPEN
                                   stop timer

                   rec START       send STACK              START_REC
                                   start timer

                   timer expires   send STACK              START_REC
                                   start timer

   VC_OPEN         rec START       close port VC           VC_CLOSED
                                   notify SCS
                   rec STACK       send ACK                VC_OPEN
                   rec ACK         -                       VC_OPEN

                   VC failure      notify SCS              VC_CLOSED
                   detected
   CI PPD OPERATION                                             Page 10-5


   Notes:
|  
|       1.  The initial value of the timer is at least one second.

        2.  The port VC is opened and closed using the SETCKT command.
   CI PPD OPERATION                                             Page 10-6


   10.3  CONFIGURATION

|  The system list is built by the PPD  layer  polling  with  REQID  port
|  functions  directed  to  all  possible  destination  ports.  The IDREC
|  responses are used to fill in the system blocks.   This  procedure  is
|  repeated  periodically  to  insure  that  the  system list is current.
|  Also, any unsolicited IDREC responses received are used to fill in the
|  system blocks and path blocks.



   10.4  OTHER PPD INTERFACE FUNCTIONS

   The other PPD interface functions and  procedures  are  in  one-to-one
   correspondence with CI port commands and responses.











                                 CHAPTER 11

                              NI PPD OPERATION



   \TBS\











                                 CHAPTER 12

                              BI PPD OPERATION



   \TBS\











                                 APPENDIX A

                               PROCESS NAMING



   A process name is a 16 byte string.  A process  name  starts  with  an
   upper  case  letter  (A-Z)  or  a  dollar  sign  ($).   The  remaining
   characters can be upper case letters, numbers (0-9), dollar signs,  or
   underlines  (_) except that the last character cannot be an underline.
   Blank () characters are added to the end of the string if necessary to
   fill the string to 16 characters.

   It is intended in SCA that process names be human understandable.  The
   preferred structure for naming is as follows:

           <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


|  
|          { PPD message types with the sign bit set are reserved for }
|          { implementation use and are not part of the protocol over }
|          { the interconnect. }
|  
|                  { Define SCS/PPD  message lengths }
|  
|          CONNECT_REQ_LEN = 66;
|  
|          CONNECT_RSP_LEN = 18;
|  
|          ACCEPT_REQ_LEN  = 66;
|  
|          ACCEPT_RSP_LEN  = 18;
|  
|          REJECT_REQ_LEN  = 18;
|  
|          REJECT_RSP_LEN  = 14;
|  
|          DISCON_REQ_LEN  = 18;
|  
|          DISCON_RSP_LEN  = 14;
|  
|          CREDIT_REQ_LEN  = 18;
|  
|          CREDIT_RSP_LEN  = 14;
|  
|          AP_MSG_HDR_LEN  = 14;
|  
|          AP_DG_HDR_LEN   = 14;
|  
|          START_LEN       = 42;
|  
|          STACK_LEN       = 42;
|  
|          ACK_LEN         = 6;                    {SCSPPDEND}











                                 APPENDIX E

                  REJECTION AND DISCONNECTION REASON CODES




|  There is no guarantee that additional assigned codes are  contiguously
|  assigned.   All  unassigned  values are reserved for SYSAP private use
|  and their use may overlap between different SYSAP  protocols.   Common
|  useage is encouraged, however.
|                                                  {CONREJDEF}
|  
|                  { Connection accept/reject reason codes. }
|  
|          { Message codes have two fields.  The lower three bits are }
|          { the severity and the bits 3-15 are the code. }
|  
|          { Severity values }
|  
|          { 0 = warning }
|          { 1 = success }
|          { 2 = error }
|          { 3 = reserved }
|          { 4 = severe error }
|          { 5 - 7 = reserved }
|  
|          CONNECTED       = 1;                    { general success }
|          
|          NO_MATCH        = 10;                   { no matching listen found }
|  
|          NO_RESOURCES    = 18;                   { no resources available to process request }
|  
|          DISCONNECTED    = 26;                   { connection has been broken }
|  
|          RESERVED        = 34;                   { RESERVED }
|  
|                                                  {CONREJEND}











                                 APPENDIX F

                            CI START DATA FORMAT



|          
|                   3                             
|                   1                             0
|                  +-------------------------------+
|                  |   PPD MTYPE   |   LENGTH      |
|                  +-------------------------------+
|                  |           SEND_SYS            |
|                  +---------------+               |
|                  | MBZ   | PRTVRS|               |
|                  +---------------+---------------+
|                  |    MAX_MSG    |    MAX_DG     |
|                  +---------------+---------------+
|                  |            SW_TYPE            |
|                  +-------------------------------+
|                  |           SW_VERSION          |
|                  +-------------------------------+
|                  |         SW_INCARNATION        |
|                  |                               |
|                  +-------------------------------+
|                  |            HW_TYPE            |
|                  +-------------------------------+
|                  |                               |
|                  =           HW_VERSION          =
|                  |                               |
|                  +-------------------------------+
|                  |           NODE_NAME           |
|                  |                               |
|                  +-------------------------------+
|                  |            CUR_TIME           |
|                  |                               |
|                  +-------------------------------+
|  

   where:

       SEND_SYS        the system address of the system sending the start
                       data.
   CI START DATA FORMAT                                          Page F-2


|      PRTVRS           protocol version (MBZ at this time).

       MAX_DG          the maximum datagram size (in bytes) supported  by
                       the system.

       MAX_MSG         the maximum message size (in bytes)  supported  by
                       the system.

       SW_TYPE         the type of the software in the system.  Currently
                       defined are 'VMS ','T-10', and 'T-20'.

       SW_VERSION      the version number of the software in the system.

       SW_INCARNATION  (8 bytes) the incarnation number of  the  software
                       in the system.

       HW_TYPE         the type of system hardware.
|  
|      HW_VERSION      (12  bytes)  the  version  number  of  the  system
|                      hardware.

       NODE_NAME       (8 bytes)  the  ASCII  node  name  of  the  system
                       sending the message.

       CUR_TIME        (8 bytes) the 64-bit current system  time  on  the
                       system sending the message.











                                 APPENDIX G

                             EXAMPLE CI MESSAGE



   The following figure shows  a  SYSAP  message  and  its  encapsulation
   inside of SCS, PPD, and CI Port layer headers.  This figure represents
   the send message command as presented to the CI  port  command  queue.
   The double lines indicate layer boundaries.


                    3       2       1
                    1       3       5       7     0
                   +-------------------------------+
                   |             FLINK             |    
                   +-------------------------------+
                   |             BLINK             |
                   +-------+-------+---------------+  CI PORT HEADER
                   |SWFLAG | TYPE  |    SIZE       |
                   +-------+-------+-------+-------+
                   | FLAGS | OPC   | STATUS|  PORT |
                   +=======+=======+=======+=======+
                   |   PPD MTYPE   |    LENGTH     |  PPD HEADER
                   +===============+===============+
                   |     CREDIT    |   SCS MTYPE   |
                   +---------------+---------------+
                   |    DESTINATION CONNECT ID     |  SCS HEADER
                   +-------------------------------+
                   |      SOURCE  CONNECT ID       |
                   +===============================+
                   |                               |
                   .                               .
                   .        APPLICATION MESSAGE    .  SYSAP MESSAGE
                   .                               .
                   |                               |
                   +-------------------------------+

   where:

       FLINK           command queue forward link.

       BLINK           command queue backward link.
   EXAMPLE CI MESSAGE                                            Page G-2


       SIZE            size in bytes of structure containing  the  entire
                       message (used by software only).

       TYPE            software data structure  type  (used  by  software
                       only).

       SWFLAG          software flags (used by software only).

       PORT            destination CI port number.

       STATUS          packet status on response.

       OPC             CI port opcode, e.g., SNDMSG in this case.

       FLAGS           CI command flags.

       LENGTH          number of bytes from PPD MTYPE  field  to  end  of
                       SYSAP message (this field is shared by the PPD and
                       SCS layers).

       PPD MTYPE       command type code for PPD layer, e.g., SCS_SEND in
                       this case.

       SCS MTYPE       message type for SCS layer, e.g., APPL_MSG in this
                       case.

       DESTINATION CONNECT ID connect ID of the target SYSAP process.

       SOURCE CONNECT ID connect ID of the sending SYSAP process.

       APPLICATION MESSAGE the data  to  be  transmitted  to  the  target
                       SYSAP.











                                 APPENDIX H

                              MINIMAL SUPPORT



   Subsetting of the SCS features is  allowed.   For  example,  some  SCS
   systems  may  not  implement  block transfer operations.  However, all
   systems implementing SCS must be able to:

        1.  Process the PPD start sequence.

        2.  Interpret all SCS messages.

        3.  Process all SCS control messages and provide proper response.











                                 APPENDIX I

                               CHANGE HISTORY



   Rev.  2 to Rev.  3 change history.  (All changes within change bars.)

        1.  Change data structures to  allow  for  multiple  interconnect
            paths  between systems.  Each system block now has a chain of
            path blocks, one for each intersystem path.  The system block
            and  connection  block  data structures are modified, and the
            path block data structure is added.  The SCS  message  buffer
            is now queued to the path block, and the path block is queued
            to the SCS work queue for  control  message  processing.   In
            addition,   the   following   procedures  required  interface
            modifications:

            1.  CONFIGURATION (changed to two procedures:  CONFIG_SYS and
                CONFIG_PATH)

            2.  INSERT_SCS_Q

            3.  REMOVE_SCS_Q

            4.  SNDDG

            5.  SNDMSG

            6.  SNDDAT

            7.  REQDAT

            8.  REQID

            9.  RSP_POLL

           10.  START_VC

           11.  STATE_POLL

           12.  REQ_ID

            The following required minor code changes (due  to  calls  to
            changed interfaces listed above).
   CHANGE HISTORY                                                Page I-2


            1.  ACCEPT

            2.  REJECT

            3.  CONNECT

            4.  DISCONNECT

            5.  SEND_DG

            6.  SEND_MSG

            7.  REC_MSG

            8.  CANCEL_REC_MSG

            9.  READ

           10.  WRITE

           11.  SCS_REC


        2.  Two optional parameters  are  added  to  CONNECT.   The  PATH
            parameter  allows  a  SYSAP  to  request  connection  over  a
            specific  path.   The  ERROR  parameter  provides  a  calling
            address  for  SCS  to  notify  the SYSAP on the receipt of an
            erroneous packet.

        3.  A DISCONNECT request by one side now causes the connection to
            be  closed  by  both  local  and  remote  SCSs.  A new state,
            DISCONNECT_CNF, is added to the state  diagram.   A  new  SCS
            disconnect  confirmed  control  message  and  response  pair,
            DISCNF_REQ and DISCNF_RSP, are added.   This  second  set  of
            disconnect   messages   ensure   that  all  pending  transfer
            operations  terminate   before   connection   resources   are
            released.  The following changes are made:

            1.  A new function, CB_CLOSED, is added to check  for  closed
                state of a connection.

            2.  Procedures SEND_DG, REC_DG, and REC_MSG  are  changed  to
                functions.

            3.  Functions SEND_DG, REC_DG, SEND_MSG, REC_MSG,  READ,  and
                WRITE  now  check  to verify that the connection is open.
                If the connection has been  closed,  status  NOT_OPEN  is
                returned.


        4.  All PPD and SCS maintenance commands, messages, and responses
            are removed.
   CHANGE HISTORY                                                Page I-3


        5.  The position of the  reserved  word  in  Start  Data  Format,
            Appendix G, is changed to follow the system address.

        6.  The HW_VERSION field is changed to 16 bytes.

        7.  A new appendix is added showing the format  of  a  sample  CI
            message  transmission,  including  application  message,  SCS
            header, PPD header, and CI port header.

        8.  A new appendix is added describing minimal support.

        9.  Former appendix D, Multi CI Port Support, is removed.

       10.  New connection state CLOSED_NR  is  added  to  indicate  that
            destination  had  no resources to process CONNECT, e.g., busy
            processing another connect request.   This  is  indicated  by
            NO_RESOURCES response.

       11.  Substantial style changes are made to  the  Pascal  code  and
            specification.


   Rev.  3 to Rev.  4 change history.  (included in Rev.  3 change bars)

        1.  Change disconnect protocol to require both  SYSAPs  to  issue
            DISCONNECT  requests  before the connection is shutdown.  The
            new protocol  uses  only  two  messages,  DISCONNECT_REQ  and
            DISCONNECT_RSP,  but  introduces  states DISCONNECT_MATCH and
            DISCONNECT_ACK.  The following sections required changes:

            1.  Section 6.1, Type Definitions, was modified  to  add  the
                new states to the C_STATE definition.

            2.  Section 6.3, Connection Management Services, was modified
                to add the new states and a description of the disconnect
                protocol.

            3.  Section  6.3.5,  Disconnect   call   in   the   SYSAP-SCS
                interface, was changed to note that only the calling side
                is prohibited from transmitting further messages.

            4.  Former Sections 8.2.9 and 8.2.10 of Version 3, describing
                the Disconnect Confirmation messages, were removed.

            5.  Section 9.6.2, Connection States in  SCS  Operation,  was
                modified.   The  connection  state  table  was changed to
                reflect the new protocol, and the  description  following
                that   table   was   modified   to  note  the  disconnect
                requirements for multi-priority ports.

            6.  Section 9.6.7, Disconnect procedure  code,  was  modified
                because disconnect can be called in one of two states.
   CHANGE HISTORY                                                Page I-4


            7.  Section 9.10, the SCS Send procedure code, was  modified.
                The  DISCONNECT_PEND code was changed (only the comments)
                to note the possible current states.

            8.  Section 9.11, SCS Receive procedure code,  was  modified.
                The  DISCNF_REQ  and  DISCNF_RSP  code  from Rev.  3 were
                removed.  The DISCON_REQ and DISCON_RSP code was modified
                to show the path for various connection states.


        2.  The Start/Stack Data Format, Appendix F, is  changed  to  add
            two  new  fields.   The  CUR_TIME  field  is added to provide
            system time for initializing nodes that do not have a  clock.
            The  NODE_NAME  field  specifies  the  ASCII node name of the
            sender.

        3.  The System Block  data  structure  is  modified  to  add  the
            NODE_NAME field.

        4.  The CONFIG_SYS function, Section 6.2.1, is changed to add the
            NODE_NAME return parameter.

|  
|  Rev.  4 to Rev.  5 change history.  (change bars include only Rev.   5
|  changes)
|  
|       1.  Contrasting of architecture and functional specifications  in
|           Introduction.
|  
|       2.  Remove reference to requirements for supporting clusters with
|           multiple CI's.
|  
|       3.  Describe SW_INCARNATION in system block.
|  
|       4.  Remove CLOSED_NM, _NR,  _REJ  and  _VC  states  leaving  only
|           CLOSED.    Add   CONNECT_ACK,  ACCEPT_SENT,  and  REJECT_SENT
|           states.   Update  description  in  section   6.3   Connection
|           management  services  and  pascal code to reflect these state
|           changes.
|  
|       5.  Rename PTR to CREDITS in CONNECT and ACCEPT calls.
|  
|       6.  Remove THRSH from LISTEN and put it in ACCEPT.
|  
|       7.  Remove ERROR from CONNECT call.
|  
|       8.  State that datagrams  are  queued  and  accounted  for  on  a
|           connection  by  connection  basis  in  section  6.4  Datagram
|           service.
|  
|       9.  State that an implementation "MUST" provide a  provision  for
|           canceling   block   data  transfers,  but  that  there  is  a
|           restriction due to design of CI port hardware.   Section  6.6
|           block data service.
   CHANGE HISTORY                                                Page I-5


|      10.  Describe need for MPTR1 and MPTR2 and DPTR in START_VC  call.
|           Section 7.3.1 Start Virtual Circuit.
|  
|      11.  Remove REQ_ID and REQID functions from PPD interface.
|  
|      12.  Rewrite section 9.6.2 Connection States to reflect reality.
|  
|      13.  Define PPD message type codes with sign bit set  as  reserved
|           for an implementation to use internally.
|  
|      14.  Change definitions of reject and disconnect reason  codes  to
|           include more codes and severity encoding.
|  
|      15.  Change definition of Start Data format  to  include  protocol
|           version field and remove 4 bytes from the HW_VERSION.
|  
|      16.  Define the credit management variables a little better.
|  
|      17.  Explain START/STACK  operation  with  protocol  mismatch  for
|           later use.
|  
|      18.  Fix the pascal  program  to  store  something  in  REQ_CREDIT
|           before using the value stored there.
|  
|      19.  Minor updates.
|  
|  
|  Rev.  5 to Rev.  6 changes (included in Rev.  5 change bars)
|  
|       1.  Describe rules for verifying minimum message size  for  SYSAP
|           protocol.  Section 6.3.
|  
|       2.  Define BY_NAME and BY_ENTRY in section B.3.1.
|  
|       3.  Make statement about REJECT and DISCONNECT  reason  codes  in
|           appendix E.  Reserve code 34.
|  


















                          Functional description of the
                       Systems Communications Architecture

                                    21-Nov-83

                              Version 1, Revision 5
   SCA Functional specification                                         Page 2


     1.0  Revision history

     Revision 1:

     1.  Change user interface for packet sends to reflect data  being  copyed
         rather than mapped into monitor space.

     2.  Add set port counters function (.SSSPC)

     3.  Add configuration change PSI channel to .SSAIC JSYS function.


          Note: There are no change bars for this revision. Change bars
             will begin with the next revision of the specification.



     Revision 2:

     Update path specification handling in  .SSSDG  and  .SSSMG  functions  of
     SCS%.



     Revision 3:

     Make maintainance data send and receive work correctly.



     Revision 4:

     Fix additional problems with maintainance data send and receive.



     Revision 5:

     Add user level maintainance functions for reset/start  a  remote  system.
     Also add "monotonic counter" to set/read port counter calls.
   SCA Functional specification                                         Page 3


     2.0  Table of Contents

           1.0     Revision history . . . . . . . . . . . . . . . . . . 2
           2.0     Table of Contents  . . . . . . . . . . . . . . . . . 3
           3.0     Definitions  . . . . . . . . . . . . . . . . . . . . 5
           4.0     Introduction . . . . . . . . . . . . . . . . . . . . 6
           4.1       Related documents  . . . . . . . . . . . . . . . . 6
           4.2       Scope  . . . . . . . . . . . . . . . . . . . . . . 6
           4.3       Module interactions  . . . . . . . . . . . . . . . 7
           4.4       SCA overview . . . . . . . . . . . . . . . . . . . 9
           4.5       General differences  . . . . . . . . . . . . . . . 9
           4.5.1       TOPS-20 only functionality . . . . . . . . . . . 9
           4.6       Service required of PHYKLP . . . . . . . . . . .  11
           4.7       PHYKLP interface . . . . . . . . . . . . . . . .  12
           4.8       Data structures  . . . . . . . . . . . . . . . .  17
           4.8.1       System block . . . . . . . . . . . . . . . . .  17
           4.8.2       Connect block  . . . . . . . . . . . . . . . .  20
           4.8.3       Connect ID . . . . . . . . . . . . . . . . . .  23
           5.0     Writing a monitor SYSAP  . . . . . . . . . . . . .  24
           5.1       General rules  . . . . . . . . . . . . . . . . .  24
           5.1.1       Buffer allocation and management . . . . . . .  24
           5.1.2       Starting a connection  . . . . . . . . . . . .  26
           5.1.3       Global interlocks  . . . . . . . . . . . . . .  28
           5.2       Messages . . . . . . . . . . . . . . . . . . . .  29
           5.2.1       Receiving messages . . . . . . . . . . . . . .  29
           5.2.2       Sending messages . . . . . . . . . . . . . . .  29
           5.3       Datagrams  . . . . . . . . . . . . . . . . . . .  29
           5.3.1       Receiving datagrams  . . . . . . . . . . . . .  29
           5.3.2       Sending datagrams  . . . . . . . . . . . . . .  30
           5.4       Named buffers  . . . . . . . . . . . . . . . . .  30
           5.5       Monitor SYSAP interface  . . . . . . . . . . . .  31
           5.5.1       SYSAP to SCA interface . . . . . . . . . . . .  31
           5.5.1.1       Connect (SC.CON) . . . . . . . . . . . . . .  31
           5.5.1.2       Listen (SC.LIS)  . . . . . . . . . . . . . .  32
           5.5.1.3       Accept (SC.ACC)  . . . . . . . . . . . . . .  35
           5.5.1.4       Reject (SC.REJ)  . . . . . . . . . . . . . .  36
           5.5.1.5       Disconnect (SC.DIS)  . . . . . . . . . . . .  37
           5.5.1.6       Abort (SC.ABT) . . . . . . . . . . . . . . .  38
           5.5.1.7       Send datagram (SC.SDG) . . . . . . . . . . .  38
           5.5.1.8       Queue datagram receive buffers (SC.RDG)  . .  40
           5.5.1.9       Send a message (SC.SMG)  . . . . . . . . . .  41
           5.5.1.10      Queue message receive buffers (SC.RMG) . . .  42
           5.5.1.11      Cancel datagram receive buffer (SC.CRD)  . .  43
           5.5.1.12      Cancel message receive buffers (SC.CRM)  . .  43
           5.5.1.13      Map a named buffer (SC.MAP)  . . . . . . . .  44
           5.5.1.14      Unmap a buffer (SC.UMP)  . . . . . . . . . .  46
           5.5.1.15      Send named buffer data (SC.SND)  . . . . . .  47
           5.5.1.16      Request remote named buffer transfer (SC.REQ) 48
           5.5.1.17      Connect state poll (SC.CSP)  . . . . . . . .  49
           5.5.1.18      Return destination connect ID (SC.DCI) . . .  50
           5.5.1.19      Return system configuration data (SC.RCD)  .  51
           5.5.1.20      Reset a remote system (SC.RST) . . . . . . .  52
           5.5.1.21      Start a node (SC.STA)  . . . . . . . . . . .  53
           5.5.1.22      Set port counters (SC.SPC) . . . . . . . . .  54
           5.5.1.23      Read port counters (SC.RPC)  . . . . . . . .  55
   SCA Functional specification                                    Page 4


           5.5.1.24      Maintainance data send (SC.MDS)  . . . . . .  56
           5.5.1.25      Maintainance data read (SC.MDR)  . . . . . .  57
           5.5.1.26      Set online address (SC.SOA)  . . . . . . . .  58
           5.5.1.27      Swap bytes from 11 to 10 format (SC.ISW) . .  59
           5.5.1.28      SC.OSW (Swap word from 10 to 11 forma  . . .  60
           5.5.1.29      Return node number given CID (SC.SBI)  . . .  61
           5.5.1.30      Return credit info (SC.RAC)  . . . . . . . .  62
           5.5.1.31      Return local port number (SC.PRT)  . . . . .  63
           5.5.1.32      Allocate a datagram buffer (SC.ALD)  . . . .  64
           5.5.1.33      Allocate a message buffer (SC.ABF) . . . . .  65
           5.5.1.34      Return a message buffer (SC.RBF) . . . . . .  66
           5.5.1.35      Return a datagram buffer (SC.RLD)  . . . . .  66
           5.5.2       SCA to SYSAP interface . . . . . . . . . . . .  67
           6.0     Writing a JSYS SYSAP . . . . . . . . . . . . . . .  72
           6.1       General rules  . . . . . . . . . . . . . . . . .  72
           6.1.1       Communicating with SCA . . . . . . . . . . . .  72
           6.1.1.1       Using the SCS% with the PSI system . . . . .  72
           6.1.2       Buffer management  . . . . . . . . . . . . . .  72
           6.1.2.1       Incoming buffers . . . . . . . . . . . . . .  72
           6.1.2.2       Outgoing buffers . . . . . . . . . . . . . .  73
           6.1.3       The race condition . . . . . . . . . . . . . .  73
           6.2       JSYS SYSAP interface . . . . . . . . . . . . . .  74
           6.2.1       Connect (.SSCON) . . . . . . . . . . . . . . .  75
           6.2.2       Listen (.SSLIS)  . . . . . . . . . . . . . . .  77
           6.2.3       Accept (.SSACC)  . . . . . . . . . . . . . . .  78
           6.2.4       Reject (.SSREJ)  . . . . . . . . . . . . . . .  79
           6.2.5       Disconnect (.SSDIS)  . . . . . . . . . . . . .  80
           6.2.6       Send a DG (.SSSDG) . . . . . . . . . . . . . .  81
           6.2.7       Queue a DG buffer (.SSQRD) . . . . . . . . . .  82
           6.2.8       Send message (.SSSMG)  . . . . . . . . . . . .  83
           6.2.9       Queue message receive buffers (.SSQRM) . . . .  84
           6.2.10      Cancel DG receive (.SSCRD) . . . . . . . . . .  85
           6.2.11      Cancel receive message (.SSCRM)  . . . . . . .  86
           6.2.12      Connect state poll (.SSCSP)  . . . . . . . . .  87
           6.2.13      Return local node number (.SSGLN)  . . . . . .  88
           6.2.14      Return configuration data (.SSRCD) . . . . . .  89
           6.2.15      Return buffer sizes (.SSRBS) . . . . . . . . .  91
           6.2.16      Return status information (.SSSTS) . . . . . .  92
           6.2.17      Get a queue entry  . . . . . . . . . . . . . .  93
           6.2.17.1      Receive a message (.SSRMG) . . . . . . . . .  93
           6.2.17.2      Receive a datagram (.SSRDG)  . . . . . . . .  94
           6.2.17.3      Get entry from data queue (.SSGDE) . . . . .  95
           6.2.17.4      Get an entry off the event queue (.SSEVT)  .  96
           6.2.18      Named buffer overview  . . . . . . . . . . . .  98
           6.2.19      Map a buffer (.SSMAP)  . . . . . . . . . . . .  99
           6.2.20      Unmap a buffer (.SSUMP)  . . . . . . . . . . . 101
           6.2.21      Send data (.SSSND) . . . . . . . . . . . . . . 102
           6.2.22      Request data (.SSREQ)  . . . . . . . . . . . . 103
           6.2.23      Maintainance data send (.SSMDS)  . . . . . . . 104
           6.2.24      Maintainace data read (.SSMDR) . . . . . . . . 105
           6.2.25      Start a remote system (.SSSRS) . . . . . . . . 106
           6.2.26      Reset a remote system (.SSRRS) . . . . . . . . 107
           6.2.27      Set port counters (.SSSPC) . . . . . . . . . . 108
           6.2.28      Read port counters (.SSRPC)  . . . . . . . . . 109
           6.2.29      Add interrupt channels (.SSAIC)  . . . . . . . 110
   SCA Functional specification                                    Page 5


     3.0  Definitions

          There are a number of terms and concepts vital to  an  understanding
     of SCA.  They are:

     1.  Credit - Credit refers to buffers queued for message (only  messages,
         there  is  no credit system for datagrams) reception or transmission.
         Receive credit is the number  of  buffers  you  have  queued  to  get
         messages  from  a  remote node.  Send credit is the number of buffers
         the remote has queued to receive messages from you.

     2.  Callback - The callback is the mechanism through which SCA interrupts
         a  SYSAP.   For  example,  when a message or datagram has arrived for
         your connection, SCA will PUSHJ to the address given in the  CONNECT,
         LISTEN,  or set online notification address call, with T1-T4 setup to
         point to the new packet.

     3.  Port queues - This refers to the set of queues used by the monitor to
         communicate  with  the  KLIPA.   These queues include the message and
         datagram free queues, into which all inbound packets are placed.

     4.  Packet - Term used to denote any CI packet,  I.E.   a  message  or  a
         datagram.

     5.  Circuit - Virtual communications path layered on top of the  CI  wire
         (I.E.  hardware path) maintained by the port driver.

     6.  Connection - Virtual communications path layered on top  of  circuits
         and maintained by SCA.
   SCA Functional specification                                    Page 6
   Introduction


     4.0  Introduction

     4.1  Related documents

          The reader should at least be familiar with the following  documents
     before  proceeding  with  this  specification.  The corporate SCA spec is
     particularly important as all terminology used in this  document  follows
     standards set in the corporate spec.

     1.  Systems Communications Architecture, Rev 4, 20-July-82 (Strecker)

     2.  LCG CI Port Architecture Specification, 11-July-83 (Dossa/Keenan)

     3.  TOPS-20   KLIPA   Driver    Functional    Specification,    19-Aug-83
         (Grant/Miller)

     4.  TOPS-20 Coding Standard, 23-Mar-83 (Murphy)




     4.2  Scope

          This document will describe the interfaces in and out of the Systems
     Communications  Architecture  (SCA).   This  includes  the user interface
     through the SCS% JSYS.  Some of the functions invisible to  the  rest  of
     the  monitor,  yet important to the overall scheme of the CI software are
     also  covered.   Implementation  details   are   left   to   the   design
     specification however.
   SCA Functional specification                                    Page 7
   Introduction


     4.3  Module interactions

          The following diagram illustrates the layout of the CI software  and
     hardware.



                               --------              ---------
                               ! SCS% !              ! DIAG% !
                               --------              ---------      User mode
                                   !                     /
     -       -       -       -     ! -       -       -  /   -        -       -
                    --------   --------  -------       /             
                    ! MSCP !   !SCSJSY!  ! CFS !      /             Monitor mode
                    --------   --------  -------     /
                         \         !        /       /
                          \        !       /       /
                           \       !      /       /
                           -----------------     /
                           !      SCA      !-----
                           -----------------     
                                   !             
                            ---------------     
                            ! Port driver !
                            ---------------     
                                   !
                                   !                                Software
                                   !
     -       -       -       -       -       -       -       -       -       -
                                   !
                                   !                                Hardware
                            ---------------
                            !    KLIPA    !
                            ---------------
                                   !
                 CI                !             
              ==========================================


          Briefly, these are the functions performed by each of  the  software
     modules listed above.

     The  port  driver  is  the  hardware  controller  for  the   KLIPA.    It
     communicates  with  the  device  through  a queued protocol using KL main
     memory.

     SCA is the CI gateway for the rest of the monitor.  The only exception is
     the  DIAG  JSYS which has the capability of disabling the port driver and
     taking direct control of the hardware.  In general  however  all  monitor
     components access the CI through SCA.

     System applications (SYSAP) are the  end  users  of  the  CI.   The  Mass
     Storage  Control  Protocol  (MSCP)  is a CI disk controller.  Common File
     System (CFS) is the global file lock manager for implementing distributed
   SCA Functional specification                                    Page 8
   Introduction


     access to CI disks and dual ported massbus disks.
   SCA Functional specification                                    Page 9
   Introduction


     4.4  SCA overview

          The overall function of  SCA  can  best  be  described  as  software
     multiplexer,  demultiplexer  for  the CI.  SCA is the module that creates
     the illusion of virtual connections over the circuits established by  the
     port  driver.   A  detailed description of how SCA performs this function
     can be found in [1].  What needs to be detailed here is exactly what  has
     been  done  that is specific to TOPS-20 and hence could never be outlined
     in the corporate specification.



     4.5  General differences

          In general, the corporate specification is considered to be a  model
     in which the seeds of the TOPS-20 implementation may be found.  There are
     a number of global differences that need to be outlined.

     1.  The corporate specification uses polling to determine the  completion
         of a request.  The TOPS-20 implementation is interrupt driven.

     2.  TOPS-20 does not use the suggested format for connection  and  system
         blocks.  Additional words were required and all support locations for
         path blocks were removed.

     3.  The most important difference is the lack of the  "path"  concept  in
         TOPS-20.   The  corporate specification calls for the use of multiple
         paths to a single node.   (Note  that  this  is  not  the  dual  rail
         concept,  I.E.   Path  A  and  Path B) The entire concept of multiple
         paths to a single node is dissallowed  in  TOPS-20.   All  nodes  are
         directly connected to all other nodes by exactly one logical path.  A
         logical path is a port onto a CI, even though the port may have  more
         than one cable on it.

         TOPS-20 does not  support  paths  because  the  KL-10  processor  can
         currently support only one KLIPA.  Since there is one KLIPA there can
         by definition only be one path to a node.  When more than  one  KLIPA
         is supported the issue of paths will be addressed.




     4.5.1  TOPS-20 only functionality

          At present, there is only one function of SCA that is  seen  by  the
     outside  world  and  not  covered  by  the corporate specification.  This
     function is the periodic polling of nodes  with  open  connections.   The
     need  for  this service arises from the fact that the KLIPA answers REQID
     packets without software intervention.  Since port level pollers for most
     machines  use  REQID  packets to test the rails to the other nodes on the
     net, a system could suffer a complete software failure and no  one  would
     detect  it  until the port were reset during the BOOT process.  There are
     SYSAPs that need to see remote software failures much sooner  than  this.
     Hence  SCA  will  send credit requests for zero credit to nodes that have
   SCA Functional specification                                   Page 10
   Introduction


     not sent the local node a message for a  certain  time  period.   If  the
     response  comes  back  within  a certain time then the node is up and SCA
     simply marks the fact the the credit request received a response.  If the
     response  does  not come back within the defined time period, the node is
     declared offline, SCA requests that the port to port virtual  circuit  be
     broken, and all SYSAP's are notified of the remote node failure.
   SCA Functional specification                                   Page 11
   Introduction


     4.6  Service required of PHYKLP

          Since PHYKLP maintains direct control over the hardware,  there  are
     services required of PHYKLP by SCA.  These services are:

     1.  ULNKDG -- Remove a buffer from the datagram free queue.

     2.  ULNKMG -- Remove a buffer from the message free queue.

     3.  SNDDG -- Send a datagram

     4.  SNDMSG -- Send a message

     5.  LNKMFQ -- Link a buffer chain onto the message free queue

     6.  LNKDFQ -- Link a buffer chain onto the datagram free queue

     7.  CLOSVC -- Close a virtual circuit

     8.  MAPBUF -- Map a named buffer

     9.  UMAP -- Unmap a named buffer

    10.  SNDDAT -- Start a named buffer data send

    11.  REQDAT -- Start a named buffer data receive

    12.  LOCPRT -- Return the local node number

    13.  KLPOPN -- Open a circuit

    14.  PPDSRS -- Send a reset or start maintainance packet

    15.  PPDSMD -- Do a maintainance data send

    16.  PPDRMD -- Do a maintainace data read

    17.  PPDRPT -- Read port counters

    18.  PPDSPT -- Set port counters

    19.  STRPOL -- Start the poller

    20.  STPPOL -- Stop the poller

    21.  STRKLP -- Start the KLIPA

    22.  STPKLP -- Stop the KLIPA
   SCA Functional specification                                   Page 12
   Introduction


     4.7  PHYKLP interface

          Direct control over the CI is done  by  the  port  driver  (PHYKLP).
     Hence SCA must interface to the port driver to perform its function.  The
     following is the set of SCA entry points understood by the port driver.

                                 - SC.INT -

          This routine is called when the port driver has  received  a  packet
     bound for SCA.


             Call

             BLCAL. (SC.INT,<SS.PKA,SS.SBA,SS.FLG,SS.LEN>)

             Where:
             SS.PKA - Address of message/datagram/SCA buffer
             SS.SBA - Address system block

             SS.FLG - Flags
                      F.SPM - Packet data mode       0 - Industry compatable mode
                                                     1 - High density mode

                      F.RSP - Local or remote packet 0 - Remote packet
                                                     1 - Localy generated packet

             SS.LEN - Length of packet in bytes (for industry compatible packets)
                    - Length in words for high density packets

             Return (+1)
             T1/     Error code

             Return (+2)
             No data returned, all went well
   SCA Functional specification                                   Page 13
   Introduction


                                 - SC.MDC -

          This routine is called by the port driver when a  maintainance  data
     transfer has completed.

             Call
             BLCAL. (SC.MDC,<SS.ADR,SS.NAM>)

             Where:
             SS.ADR -- Address passed to PHYKLP on SC.MDS/SC.MDR call
             SS.NAM -- Local name for transfer which has completed


             Return (+1)
             T1/     Error code

             Return (+2)
             No data returned
   SCA Functional specification                                   Page 14
   Introduction


                                 - SC.DMA -

          This routine handles the completion of a named buffer transfer.

             Call
             BLCAL. (SC.DMA,<SS.CID,SS.SBA,SS.NAM>)

             Where:
             SS.CID -- CID of connection we did this for
             SS.SBA -- Address of system block
             SS.NAM -- Buffer name for transfer that completed


             Return (+1)
             T1/     Error code

             Return (+2)
             No data returned
   SCA Functional specification                                   Page 15
   Introduction


                                 - SC.ERR -

          This routine is called to notify SCA of a virtual  circuit  closure.
     This includes closures requested by SCA.

             Call

             BLCAL. (SC.ERR,<SS.NOD>)

             Where:
             SS.NOD --> Node number of the system who's VC just went away.

             Return (+1)
             T1/     Error code

             Return (+2)
             No data returned


                                 - SC.ONL -

          This routine is called when a node has come online.

             Call
             BLCAL. (SC.ONL,<SS.NOD>)

             Where:
             SS.NOD -- Node number of system that has come online

             Return (+1)
             T1/     Error code

             Return (+2)
             No data returned


                                 - SC.OFL -

          This routine is called when a system has gone  offline.   Note  that
     SCA  assumes  the  data for this node has not been cleaned up by the port
     driver.

             Call
             BLCAL. (SC.OFL,<SS.NOD>)

             Where:
             SS.NOD -- Node number of the system that has gone offline

             Return (+1)
             T1/     Error code

             Return (+2)
             No data returned
   SCA Functional specification                                   Page 16
   Introduction


                                 - SC.PRC -

          This  routine   is   called   when   the   port   detects   that   a
     READ-PORT-COUNTERS command has completed.

             Call

             BLCAL. (SC.PRC,<SS.CID,SS.ADR>)

             Where:
             SS.CID -- CID for whom the register read was done
             SS.ADR -- Address of counter data packet

             Return (+1)
             T1/     Error code

             Return (+2)
             No data returned
   SCA Functional specification                                   Page 17
   Introduction


     4.8  Data structures

          To perform its function as multiplexer/demultiplexer SCA maintains a
     set  of  connections  over  the  virtual  circuits maintained by the port
     driver.   There  are  two  blocks  basic  to  the  maintenance  of  these
     connections, the system block and the connect block.



     4.8.1  System block

          The system block is a data structure shared with  the  port  driver.
     In fact the port driver owns most of the block.


             !=======================================================!
      .SBANB !             Address of next system block              !
             !-------------------------------------------------------!
      .SBAPB !       Address of associated port control block        !
             !-------------------------------------------------------!
      .SBACD !       Address of associated channel data block        !
             !-------------------------------------------------------!
      .SBVCS !    Path validity info     !    Dest vir cir state     !
             !-------------------------------------------------------!
      .SBDSP !                   Destination port                    !
             !-------------------------------------------------------!
      .SBDRQ !             Datagram return queue header              !
             !-------------------------------------------------------!
      .SBLMB !              Local message buffer header              !  *
             !-------------------------------------------------------!
      .SBFCB !           Pointer to first connection block           !  *
             !-------------------------------------------------------!
      .SBLCB !            Pointer to last connection block           !  *
             !-------------------------------------------------------!
      .SBTWQ !                FLINK for SCA work queue               !  *
             !-------------------------------------------------------!
      .SQBWQ !                BLINK for SCA work queue               !  *
             !-------------------------------------------------------!
      .SBQOR !      Pointer to queue of outstanding requests         !
             !-------------------------------------------------------!
      .SBDSS \                                                       \
             \                  Destination system                   \
             \                                                       \
             !-------------------------------------------------------!
      .SBMMS !   Max mess size (bytes)   !    Max DG size (Bytes)    !
             !-------------------------------------------------------!
      .SBDST !               Destination software type               !
             !-------------------------------------------------------!
      .SBDSV !             Destination software version              !
             !-------------------------------------------------------!
      .SBDSE !           Destination software edit level             !
             !-------------------------------------------------------!
   SCA Functional specification                                   Page 18
   Introduction


             !-------------------------------------------------------!
      .SBDHT !               Destination hardware type               !
             !-------------------------------------------------------!
      .SBDHV !              Destination hardware version             !
             !-------------------------------------------------------!
      .SBDPC \                                                       \
             \           Destination port characteristics            \
             \                                                       \
             !-------------------------------------------------------!
      .SBTIM !        TODCLK at last message from this remote        !  *
             !-------------------------------------------------------!
      .SBFLG !                       Flags                           !  *
             !-------------------------------------------------------!
      .SBTBQ !     Address of first buffer on buffer defer queue     !  *
             !-------------------------------------------------------!
      .SBBBQ !     Address of last buffer on buffer defer queue      !  *
             !=======================================================!


          Most of the cells in this  structure  are  maintained  by  the  port
     driver.   There  are  a few however that are the exclusive domain of SCA.
     These are described below.

     .SBLMB
     The local message buffer header is an interlock location for this remote.
     Since  all SCA messages are flow controled, some method had to be arrived
     at for flow control of SCA overhead messages.  This  is  done  by  always
     having  just one receive credit available for each remote node.  Hence we
     cannot send more than one overhead message at  a  time  to  a  particular
     node.   Hence  this  location is used to flag the fact that a request has
     been sent to the host.  Note that when non-zero, this  location  contains
     the  message  type that is expected in response to the request we believe
     is outstanding.

     .SBFCB/.SBLCB
     The pointer to the first and last connect blocks are the FLINK and  BLINK
     for  one  set  of threads to the connect blocks.  Each connect block is a
     member of two doubly linked lists.  One is the list of connections  to  a
     system,  the  other  is  the list of connects owned by a fork.  Note that
     unless the fork has done an SCS% JSYS, this second list is empty.

     .SBTWQ/.SBBWQ
     Something must be done with the requests that need to be sent to a system
     which  already  has  a request outstanding.  These requests are placed on
     the work queue for that system.  The  work  queue  FLINK  and  BLINK  are
     stored in the system block.

     .SBTIM
     A function performed by SCA is the polling of remote  systems  that  have
     connections  open  to  them.   This  polling  is  done to detect a remote
     software stoppage.  .SBTIM is TODCLK the last time the node talked to us.
     For further details on this process, see the section on SC.CLK.

     .SBFLG
   SCA Functional specification                                   Page 19
   Introduction


     Currently, the only defined flags are the timed  message  flag,  and  the
     circuit  requires  opening  flag.   When the timed message flag is lit in
     .SBFLG, a timed message is outstanding for this node.  SCA uses this flag
     to  help  determine  if  a  node  should  be  declared dead.  The circuit
     requires opening flag indicates that the circuit has been closed and just
     as  soon  as  databases  have  been  cleaned up, SCA should call the port
     driver to open the circuit again.

     .SBTBQ/.SBBBQ
     These words are the head and tail pointers for the queue of buffer  defer
     requests.   This  queue  is  used by SCA to handle the allocation of more
     buffers than it has on hand.
   SCA Functional specification                                   Page 20
   Introduction


     4.8.2  Connect block

          The other data structure used by SCA is the connect block.   As  the
     name  implies  this  block  is the complete set of information maintained
     about an SCA connection.


              !=======================================================!
       .CBANB !     Address of next connection block for this SB      !
              !-------------------------------------------------------!
       .CBAPB !   Address of previous connection block for this SB    !
              !-------------------------------------------------------!
       .CBJNB !     Address of next connection block for this fork    !
              !-------------------------------------------------------!
       .CBJPB !   Address of previous connection block for this fork  !
              !-------------------------------------------------------!
       .CBSTS !        Block state        !       Connect state       !
              !-------------------------------------------------------!
       .CBFLG !                        Flags                          !
              !-------------------------------------------------------!
       .CBSCI !                   Source connect ID                   !
              !-------------------------------------------------------!
       .CBDCI !                Destination connect ID                 !
              !-------------------------------------------------------!
       .CBSPN \                                                       \
              \                  Source process name                  \
              \                                                       \
              !-------------------------------------------------------!
       .CBDPN \                                                       \
              \               Destination process name                \
              \                                                       \
              !-------------------------------------------------------!
       .CBDTA \                                                       \
              \              User supplied connect data               \
              \                                                       \
              !-------------------------------------------------------!
       .CBREA !        Dest reason        !       Source reason       !
              !-------------------------------------------------------!
       .CBMCD !      Min send Credit      !    Min Receive credit     !
              !-------------------------------------------------------!
       .CBRCD !                    Receive Credit                     !
              !-------------------------------------------------------!
       .CBSCD !                     Send credit                       !
              !-------------------------------------------------------!
       .CBNPO !       Number of packets still on port command Q       !
              !-------------------------------------------------------!
       .CBRQC !                   Requeue credit                      !    
              !-------------------------------------------------------!
       .CBPRC !                 Pending rec credit                    !
              !-------------------------------------------------------!
       .CBSBA !      Pointer to system block for this connection      !
              !-------------------------------------------------------!
       .CBADR !      Address to call SYSAP on certain conditions      !
              !-------------------------------------------------------!
   SCA Functional specification                                   Page 21
   Introduction


              !-------------------------------------------------------!
       .CBCDD !             Number of dropped datagrams               !
              !-------------------------------------------------------!
       .CBDGR !           Number of real DG buffers queued            !
              !-------------------------------------------------------!
       .CBDGJ !           Number of JSYS DG buffers queued            !
              !-------------------------------------------------------!
       .CBSBI !               Destination node number                 !
              !-------------------------------------------------------!
       .CBFRK !  Job number of owner job  ! Fork number of owner fork !
              !-------------------------------------------------------!
       .CBTMQ !  Pointer to top of message available queue (for JSYS) !
              !-------------------------------------------------------!
       .CBBMQ !  Pointer to bot of message available queue (for JSYS) !
              !-------------------------------------------------------!
       .CBTDQ !  Pointer to top of datagram available queue (for JSYS)!
              !-------------------------------------------------------!
       .CBBDQ !  Pointer to bot of datagram available queue (for JSYS)!
              !-------------------------------------------------------!
       .CBTXQ !     Pointer to top of the DMA xfer complete queue     !
              !-------------------------------------------------------!
       .CBBXQ !     Pointer to bot of the DMA xfer complete queue     !
              !-------------------------------------------------------!
       .CBTEQ !          Pointer to top of the event queue            !
              !-------------------------------------------------------!
       .CBBEQ !          Pointer to bot of the event queue            !
              !-------------------------------------------------------!
       .CBTBQ !       Pointer to first buffer descriptor block        !
              !-------------------------------------------------------!
       .CBBBQ !       Pointer to  last buffer descriptor block        !
              !-------------------------------------------------------!
       .CBPS0 !  PSI channel for messages ! PSI channel for datagrams !
              !-------------------------------------------------------!
       .CBPS1 !    PSI channel for DMA    !  PSI channel for events   !
              !=======================================================!


          Of the above cells, a few are returned by  SCA  on  certain  routine
     calls.   The  following  is  a  description  of  the  cells  that  are of
     importance to a SYSAP.

     .CBSTS
     If non-zero, the block state indicates the connection is  waiting  for  a
     response  to a request.  The block state also indicates what the response
     will be.  These are the currently defined block states:

             .BSCNP --> Connect pending
             .BSACP --> Accept pending
             .BSCRP --> Credit pending
             .BSRPN --> Reject pending
             .BSDPN --> Disconnect pending

     As the name may indicate, the  connection  state  indicates  the  current
     state of the connect.  The following are the currently defined connection
   SCA Functional specification                                   Page 22
   Introduction


     states.
             .CSDRE --> Disconnect received
             .CSDSE --> Disconnect sent
             .CSDAK --> Disconnect acknowledge
             .CSDMC --> Disconnect match

             .CSCLO --> Closed - by command
             .CSCNM --> Closed - no match
             .CSCRJ --> Closed - rejection
             .CSCNR --> Closed - no resources
             .CSCVC --> Closed - Port virtual circuit error

             .CSLIS --> Listening

             .CSCSE --> Connect sent
             .CSCAK --> Connect acknowledge
             .CSCRE --> Connect received

             .CSOPN --> Connection open


     .CBFLG
     The flags word supports flags for both SCA and the SCS% JSYS.  These  are
     the currently defined flags:

             CBFNNC --> Credit has come available since ntofication of credit low
             CBFJSY --> This is a JSYS initiated connect block
             CBFABT --> CB has been aborted
             CBFRAP --> CB is to be reaped
             CBFDCL --> This was don't care listener
             CBFKIL --> Owning fork has gone away (JSYS connect only)

     .CBSCI
     This is the  source  connect  ID.   This  is  the  local  name  for  this
     connection.

     .CBDCI
     This is the remote connect ID.  This name is what the  remote  calls  the
     connection.

     .CBSPN/.CBDPN
     These are the local and remote process names in 8 bit ASCII.

     .CBDTA
     This is the initial connection data sent during the handshake for opening
     the connection.  It is always the data sent to us by the remote.

     .CBREA
     These are the remote and local disconnect reasons.  When a disconnect  is
     started,  the  local code is transmitted as the cause for the disconnect.
     When the disconnected is initiated remotely, the  destination  reason  is
     stored from the disconnect request packet.

     .CBRCD/.CBSCD
   SCA Functional specification                                   Page 23
   Introduction


     These cells contain the current credit levels for this  connection.   The
     receive  credit  reflects  the number of buffer queued on this system for
     the reception of message from the remote.  The send credit is the  number
     of buffers the remote has queued for receiving localy generated messages.



     4.8.3  Connect ID

          The connect ID is the one word unique identifier for any connection.
     It  is mentioned here because the SYSAP needs to understand the fprmat of
     the connect ID.  The ID is made up of two fields, the SYSAP field and the
     SCA field.  The SYSAP field contains bits defined by the SYSAP and passed
     to SCA when connection blocks area being created (the connect and  listen
     calls).  The SCA field is broken down into fields for use by SCA, but the
     SYSAP only needs to know that the entire field is for  the  use  of  SCA.
     The following is the format of the connect ID:

               0         5 6                                     35
              !====================================================!
              !SYSAP bits !              SCA bits                  !
              !====================================================!

          When the SYSAP field is passed to SCA it is passed  in  bits  thirty
     (30) through thirty-five (35) of the BLCAL.  argument.  SCA will move the
     bits into the correct position for placement into the connect ID.
   SCA Functional specification                                   Page 24
   Writing a monitor SYSAP


     5.0  Writing a monitor SYSAP

     5.1  General rules

          To talk  to  other  processes  on  remote  systems,  SYSAPs  request
     services  of  SCA.   There  are  some  rules that must be followed if the
     conversation is to go smoothly.



     5.1.1  Buffer allocation and management

          There are four buffer types that monitor SYSAPs  may  have  to  deal
     with, messages and datagrams, both of which can be inbound or outbound.
          Rule one, ALL inbound buffers are allocated and controlled  by  SCA.
     When  a SYSAP desires to queue buffers for message or datagram reception,
     call SCA (see calling sequence for SC.RMG and SC.RDG)  and  indicate  how
     many  you desire, or specify the address of a buffer already allocated by
     SCA.  In the normal case, start up by asking for a number of buffers, and
     after  they  have  been returned with text in them, return them to SCA as
     fresh buffers for the port queues.  SYSAPs MUST NOT specify a buffer  not
     allocated by SCA when queueing inbound buffers.
          Rule two deals with outbound buffers.  SYSAPs  may  ask  SCA  for  a
     packet  buffer (see calling sequence for SC.ABF and SC.ALD), fill it with
     data, and ask SCA to send it (see SC.SMG and SC.SDG).  If the SYSAP  uses
     SCA  buffers  for sending packets, the SYSAP may request the buffer go on
     the port free queue on packet send completion.  Hence the SYSAP may do  a
     packet  send and queue a buffer for reception all at the same time.  Note
     that only SCA buffers may end up on the port free queues.   Hence  SYSAPs
     may  not  allocate their own space and ask for these buffers to end up on
     the port free queue.
          If the SYSAP desires to allocate its own send buffers, it may do  so
     but  the  space  allocated  must meet rigid standards.  First, the buffer
     must be contiguous in physical  memory.   Hence  if  a  page  boundry  is
     crossed,  the  two  virtual pages must be physically contiguous.  Second,
     the start of the SYSAP text must be at least .MHUDA words into the  page.
     This  is  used  by  SCA for header space.  Third, when the packet send is
     done the SYSAP must ask for the buffer back.  It MUST NOT end up  on  the
     port free queues.
   SCA Functional specification                                   Page 25
   Writing a monitor SYSAP


          SYSAPs must understand the format of SCA buffers if they are  to  be
     used correctly.  The following is the general format of an SCA buffer:

              !=====================================! 
      .MHISH  \                                     \ \
              \       Invisible SYSAP header        \  \  SYSAP header area
              \                                     \  / --------------------
              \                                     \ /
              !-------------------------------------! 
      0 --->  \                                     \ \
              \             SCA header              \  \
              \                                     \   \ 
              \                                     \   / SCA header area 
              !-------------------------------------!  / --------------------
      .MHPKL  !            Packet length            ! /
              !-------------------------------------! 
      .MHUDA  \                                     \ \
              \             SYSAP text              \  \  SYSAP text area
              \                                     \  / --------------------
              \                                     \ / 
              !=====================================!


     .MHISH - This symbol defines the offset to  the  base  of  the  invisible
     SYSAP header.  It is important to note that this is a negative offset.
          This header is for the exclusive use of the SYSAP.  SCA will zero it
     when the SYSAP requests the buffer but otherwise will not touch it.  This
     means the SYSAP can write data to this area and have  it  survive  across
     port packet transmission.

     0 - This is word zero of the buffer.  It is the  base  address  which  is
     passed  between  SCA  and  te  SYSAP when talking about this buffer.  All
     offsets within the buffer are defined as offsets from this word.

     .MHPKL - This word is used by SCA to describe the length of  an  incoming
     packet.   It  is  always  filled  in by SCA when it is called by the port
     driver for an incoming packet.  This word is not filled in by  the  SYSAP
     on a message send.
          This word is always the length of the SYSAP  text,  I.E.   it  never
     includes  the length of any overhead data.  If the packet was transmitted
     in high density mode, then the length is in words.  If  the  transmission
     mode was industry compatable, then the length is in bytes.

     .MHUDA - This offset defines the first word of the SYSAP text area.   SCA
     will never touch this area except to zero it on buffer allocation.
   SCA Functional specification                                   Page 26
   Writing a monitor SYSAP


     5.1.2  Starting a connection

          Before application packets can be exchanged between processes on two
     systems,  SCA must mediate the opening of a connection.  The following is
     a graphic description of this process.
   SCA Functional specification                                   Page 27
   Writing a monitor SYSAP


                     System A        !         System B
                                     !
                     Active side     !       Passive side
     _____________________________________________________________________________
                                     !                   _____________________
                                     !                   | SYSAP does LISTEN |
                                     !                   ---------------------
                                     !                       \
                                     !             ___________\______
                                     !             | SCA creates CB |
                                     !             ------------------
                                     !
     ______________________          !
     | SYSAP does CONNECT |          !
     ----------------------          !
                 \                   !
           _______\______________    !             ________________________________
           | SCA sends CONN_REQ | ---------------->| SCA gets CONN_REQ and finds  |
           ----------------------    !             |  listener. SCA sends CONN_RSP|
                                     !             |  and gives .SSCTL callback   |
            _____________________ <--------------- |  to listening SYSAP          |
            | SCA gets CONN_RSP |    !             --------------------------------
            ---------------------    !                           /
                                     !                   _______/___________
                                     !                   |SYSAP gets .SSCTL|
                                     !                   -------------------
                                     !                         |
                                     !                         |
                                     !                   ___________________
                                     !                   |SYSAP does ACCEPT|
                                     !                   -------------------
                                     !                               /
        _________________________    !              ________________/__
        |SCA gets ACCP_REQ,sends| <---------------- |SCA sends ACCP_REQ|
        | ACCP_RSP, and issues  |    !              --------------------
        | .SSCRA callback.      |    !
        | Connect is now open,  |    !              ________________________________
        | packets may be sent   | ----------------> |SCA receives ACCP_RSP, issues |
        -------------------------    !              | .SSOSD callback. Connect is  |
                     /               !              | now open, packets may be sent|
                    /                !              --------------------------------
        -------------------          !                                 \
        |SYSAP gets .SSCRA|          !                    --------------------------
        | callback, SYSAP |          !                    |SYSAP gets .SSOSD call  |
        | knows connect is|          !                    | back, SYSAP knowns     |
        | open            |          !                    | connect is open        |
        -------------------          !                    --------------------------


          The diagram above is a typical  connection  opening  sequence.   The
     important  thing to watch is the set of callbacks from SCA.  They are the
     direct indicator of what state the connect is in.  Note  that  there  are
     other  options  than  the  set  indicated  by  the diagram.  The detailed
     SCA/SYSAP interface details these options.
   SCA Functional specification                                   Page 28
   Writing a monitor SYSAP


     5.1.3  Global interlocks

          There are times when a SYSAP desires to insure that  no  further  CI
     traffic  will  be  processed  until  it has completed some piece of code.
     Using PIOFF to accomplish this is undesirable since it does not allow for
     nesting  and  it  turns off more channels than are necessary.  Instead of
     PIOFF/PION, CIOFF/CION should be used.  These  macros  call  routines  in
     SCAMPI  which  will  do  nesting and interrupt level checks.  At present,
     there are 36  bits  of  nesting  counter,  and  code  executed  at  KLIPA
     interrupt  level  will  not  turn  off  the channel.  Since these nesting
     checks are done, the SYSAP is guaranteed that the channel will  stay  off
     until  it does a CION.  Note that one side effect of going CIOFF is being
     NOSKED as well.
   SCA Functional specification                                   Page 29
   Writing a monitor SYSAP


     5.2  Messages

     5.2.1  Receiving messages

          To receive  messages  from  a  remote  node  a  SYSAP  must  do  the
     following:

     1.  Open a connection to the desired remote.

     2.  Queue message buffers.


          The SYSAP will now receive a .SSMGR callback for each  message  that
     arrives for it.



     5.2.2  Sending messages

          To send messages the SYSAP must have the following:

     1.  An open connection with the desired remote.

     2.  Send credit.

     3.  A buffer which meets the  requirements  for  placement  on  the  port
         command queues.


          If the connection has no send credits the remote node has not queued
     any  buffers  for receiving messages from you.  Hence you cannot send any
     and will get the fail return from SC.SMG until  the  remote  queues  some
     buffers.



     5.3  Datagrams

     5.3.1  Receiving datagrams

          Much like messages, datagrams require  an  open  connection  to  the
     remote  and  buffers queued for datagram reception.  The major difference
     is that when the remote does a send, if it fails  because  there  are  no
     buffers  available for your connection, you will get the .SSDDG callback.
     This is mearly an indication that the software  has  detected  a  dropped
     datagram  for  your  connection and you should queue some buffers for it.
     If the hardware drops the datagram because there are no  buffers  on  the
     entire  hardware  queue,  you  will never hear about it.  Hence the SYSAP
     cannot count on being told about dropped datagrams.  Note that SCA  never
     notifies the sender that the datagram was dropped.
   SCA Functional specification                                   Page 30
   Writing a monitor SYSAP


     5.3.2  Sending datagrams

          Sending datagrams requires an open connection to the  remote  and  a
     packet  buffer  that  meets  the  requirements  for placement on the port
     command queues.  (See the section on buffers for more details)



     5.4  Named buffers

          The general procedure for the transfer of data with named buffers is
     as follows:

     1.  Both sides of an open connection do a map call to set up a buffer.

     2.  SYSAP A gives its name for the buffer to SYSAP B.

     3.  The SYSAP B does a request or send data  function  which  starts  the
         data in the desired direction.

     4.  The SYSAP B gets a callback indicating the completion  of  the  named
         buffer transfer.

     5.  Lastly, and optionally, SYSAP B tells the SYSAP A that  the  transfer
         is complete.


          This method implies that each SYSAP has message buffers queued.  The
     data  transfer  functions  require  a buffer from the message free queue.
     The exchange of names should be done with messages or datagrams.
   SCA Functional specification                                   Page 31
   Writing a monitor SYSAP


     5.5  Monitor SYSAP interface

     5.5.1  SYSAP to SCA interface

          SCA provides many services to the SYSAP  though  the  use  of  these
     calling sequences:




     5.5.1.1  Connect (SC.CON)

                            - Connect (SC.CON) -

          This routine requests a connect with a remote process.

             Call
     BLCAL. (SC.CON,<SS.SPN,SS.DPN,SS.NOD,SS.MSC,SS.MRC,SS.ADR,^_
                     SS.SID,SS.DTA,SS.BFR,SS.DGB>)

      Where:
             SS.SPN -- Byte pointer to source process name
             SS.DPN -- Byte pointer to destination process name
             SS.NOD -- Node number of destination system
             SS.MSC -- Minimum send credit (Min for remote receive 
                             credit)
             SS.MRC -- Minimum receive credit, point at which 
                             destination must give more
             SS.ADR -- Address to call on condition changes for 
                             this connection
             SS.SID -- Value to be placed in SYSAP field in CID (right justified)
             SS.DTA -- Address of SYSAP connection data or zero
             SS.BFR -- Number of buffers to queue for message reception
             SS.DGB -- Number of datagram buffers to queue

             Return (+1)
             T1/     Error code

             Return (+2)
             T1/     Connect ID

          The  returned  connect  ID  is  the  unique  identifier   for   this
     connection.   All  further interaction with SCA will include this connect
     ID (CID).
   SCA Functional specification                                   Page 32
   Writing a monitor SYSAP


     5.5.1.2  Listen (SC.LIS)

                            - Listen (SC.LIS) -

          This routine enables the process  to  listen  for  connections  from
     remote processes.

             Call

     BLCAL. (SC.LIS,<SS.SPN,SS.DPN,SS.NOD,SS.ADR,SS.SID,SS.DTA,^_
                     SS.MSC,SS.MRC>)

      Where:
             SS.SPN -- Byte pointer to source process name
             SS.DPN -- Byte pointer to destination process name or 0
             SS.NOD -- Node number or -1
             SS.ADR -- Address to call on connection condition changes
             SS.SID -- Value to be placed in SYSAP field of CID (Right justified)
             SS.MSC -- Minimum send credit 
             SS.MRC -- Minimum receive credit

             Return (+1)
             T1/     Error code

             Return (+2)
             T1/     Connect ID

          When SCA  receives  a  connect  request  from  a  remote  node,  the
     following   algorithm  is  used  when  doing  name  matching  with  local
     listeners:
   SCA Functional specification                                   Page 33
   Writing a monitor SYSAP



























                                  Figure 1
   SCA Functional specification                                   Page 34
   Writing a monitor SYSAP


          A successful return from this call means SCA has a held a connection
     for  you  waiting for connects from remote nodes.  If a remote requests a
     connection with a process, that process will receive the .SSCTL callback.
   SCA Functional specification                                   Page 35
   Writing a monitor SYSAP


     5.5.1.3  Accept (SC.ACC)

                            - Accept (SC.ACC) -

          This routine is used to accept a connect request from a remote node.

             Call

             BLCAL.  (SC.ACC,<SS.CID,SS.DTA,SS.BFR,SS.DGB>)

      Where:
             SS.CID -- Connect ID
             SS.DTA -- Address of initial connection data or zero
             SS.BFR -- Number of buffers to be queued for message reception
             SS.DGB -- Number of buffers to queue for datagram reception

             Return (+1)
             T1/     Failure code

             Return (+2)
             T1/     Address of initial connect data

          The returned address of connect data is a pointer to the  connection
     data sent by the remote on the connect request.  Note that the connection
     is not open until the .SSOSD callback is given.
   SCA Functional specification                                   Page 36
   Writing a monitor SYSAP


     5.5.1.4  Reject (SC.REJ)

                            - Reject (SC.REJ) -

          This routine rejects the connect request of a remote process.

             Call

             BLCAL. (SC.REJ,<SS.CID,SS.RJR>)

      Where:
             SS.CID -- Connect ID
             SS.RJR -- Reject reason code

             Return (+1)
             T1/     Failure code

             Return (+2)
             No data is returned by this routine

          The reject reason may be any  value  the  caller  desires  with  the
     exception  of  those  reserved  to SCA (in the range /TBD/).  The idea is
     that the SYSAP protocol should invent and use  its  own  reject  reasons.
     After  the reject call has been issued, the connection goes back into the
     listen state.
   SCA Functional specification                                   Page 37
   Writing a monitor SYSAP


     5.5.1.5  Disconnect (SC.DIS)

                          - Disconnect (SC.DIS) -

          This routine closes an open connection.  Note that it  may  only  be
     called  if  the connection is open.  No other connection state is allowed
     for a connection that is to be disconnected.

             Call

             BLCAL.  (SC.DIS,<SS.CID,SS.DIR>)

      Where:
             SS.CID -- Connect ID
             SS.DIR -- Disconnect reason

             Return (+1)
             T1/     Failure code

             Return (+2)
             No data is returned by this routine

          The disconnect reason may be any value the caller desires  with  the
     exception  of  those  reserved  to SCA (in the range /TBD/).  The idea is
     that the SYSAP protocol should invent and use its own disconnect reasons.
   SCA Functional specification                                   Page 38
   Writing a monitor SYSAP


     5.5.1.6  Abort (SC.ABT)

                             - Abort (SC.ABT) -

          This routine is called  to  abort,  or  cancel,  a  connection.   It
     differs  from disconnect in that it may be issued for a connection in any
     state.  Whereas disconnect may only be issued for an open connection.

             Call

             BLCAL. (SC.ABT,<SS.CID>)

             Where:
             SS.CID -- Connect ID of the connection to be aborted

             Return (+1)
             T1/     Error code

             Return (+2)
             No data returned, CID is no longer valid, and the connection has been
               aborted.






     5.5.1.7  Send datagram (SC.SDG)

                         - Send datagram (SC.SDG) -

          This routine is called to send a datagram over an open connection.

             Call

             BLCAL.  (SC.SDG,<SS.CID,SS.FLG,SS.LDG,SS.ADG>)

      Where:
             SS.CID -- Connect ID
             SS.FLG -- Flag word
             SS.LDG -- Len of datagram (in bytes)
             SS.ADG -- Address of datagram buffer

             Return (+1)
             T1/     Failure code

             Return (+2)
             No data is returned by this routine, datagram
                      placed on port queue

          The flags word is used to indicate  the  transmission  mode  of  the
     packet,  and  hence the units on the packet size.  It also indicates what
     should be done with the buffer after the message send is  complete.   See
     the section on buffer management for more details.  These are the defined
   SCA Functional specification                                   Page 39
   Writing a monitor SYSAP


     flags for this word:
             F.RTB -- 1 - return message send buffer to SCA
                      0 - return message send buffer to free Q

             F.SPM -- 1 - Send mess/datagram in high den mode
                      0 - Send mess/datagram in industry compat mode
   SCA Functional specification                                   Page 40
   Writing a monitor SYSAP


     5.5.1.8  Queue datagram receive buffers (SC.RDG)

                - Queue datagram receive buffers (SC.RDG) -

          This routine puts buffers onto the port datagram free queue for you.

             Call

             BLCAL.  (SC.RDG,<SS.CID,SS.NUM,SS.ADR>)

      Where:
             SS.CID -- Connect ID

             If SS.ADR is zero then:
             SS.NUM -- Number of buffers to queue

             If SS.ADR is non-zero, then:
             SS.NUM is ignored, and
             SS.ADR -- Address of the buffer to queue. Note that this
                     buffer must be a buffer procured from SCA. This means it has
                     been used as a datagram buffer before. This is handy for those
                     time you are done with an SCA datagram buffer and wish to
                     requeue it. It eliminated the need for two calls to SCA.

             Return (+1)
             T1/     Error code

             Return (+2)
             Buffer(s) have been queued to receive datagrams.
   SCA Functional specification                                   Page 41
   Writing a monitor SYSAP


     5.5.1.9  Send a message (SC.SMG)

                        - Send a message (SC.SMG) -

          This routine sends a message if there are  sends  credits  available
     and the circuit is open.

             Call

             BLCAL.  (SC.SMG,<SS.CID,SS.FLG,SS.LMG,SS.AMG,SS.PRI,SS.TSH>)

      Where:
             SS.CID -- Connect ID
             SS.FLG -- Flag word, see SC.SDG for a definition
             SS.LMG -- Length of message in bytes
             SS.AMG -- Address of message buffer
             SS.PRI -- Priority to give message
             SS.TSH -- Allow send only if more than this many send credits exist

             Return (+1)
             T1/     Error code

             Return (+2)
             No data returned
   SCA Functional specification                                   Page 42
   Writing a monitor SYSAP


     5.5.1.10  Queue message receive buffers (SC.RMG)

                 - Queue message receive buffers (SC.RMG) -

          This routine places buffers onto the port  message  free  queue  and
     reflects these buffers as receive credit for the given connection.

             Call

             BLCAL.  (SC.RMG,<SS.CID,SS.NRB,SS.AMB>)

      Where:
             SS.CID -- Connect ID

             SS.NRB -- If SS.AMB is zero then this is the number of buffers 
                             to be queued for message reception.

             SS.AMB -- Address of message buffer
                       If SS.AMB is zero then a buffer is taken from the SCA
                     message buffer free queue. If it is non-zero, then it
                     is assumed that no problems will arise if the buffer
                     is returned to the SCA pool. Since it may end up in
                     the SCA pool it must be the length of all other buffers
                     in the pool, must have come from the general free
                     pool,and must be resident.

             Return (+1)
             T1/     Error code

             Return (+2)
             Buffer has been queued.
   SCA Functional specification                                   Page 43
   Writing a monitor SYSAP


     5.5.1.11  Cancel datagram receive buffer (SC.CRD)

                - Cancel datagram receive buffer (SC.CRD) -

          This routine will take buffers off the port datagram free queue.  It
     will  not  allow the caller to take more buffers than were queued for the
     given connection.  The buffers are returned to the SCA free pool and  not
     to the caller.

             Call

             BLCAL.  (SC.CRD,<SS.CID,SS.NBF>)

      Where:
             SS.CID -- Connect ID
             SS.NBF -- Number of buffers to dequeue

             Return (+1)
             T1/     Error code

             Return (+2)
             No data returned, buffer dequeued.






     5.5.1.12  Cancel message receive buffers (SC.CRM)

                - Cancel message receive buffers (SC.CRM) -

          This routine will dequeue buffers from the message free queue.  Note
     that  it  will  not  allow  the  caller to dequeue more buffers than were
     queued for the given connection.  The buffers are  returned  to  the  SCA
     free pool and not to the caller.

             Call

             BLCAL. (SC.CRM,<SS.CID>)

             Where:
             SS.CID - The connection ID of connection who's buffer we are canceling
             SS.NBD - The number of buffers to dequeue

             Return (+1)
             T1/     Error code

             Return (+2)
             No data returned, buffer(s) have been returned to the free pool
   SCA Functional specification                                   Page 44
   Writing a monitor SYSAP


     5.5.1.13  Map a named buffer (SC.MAP)

                      - Map a named buffer (SC.MAP) -

          This routine associates memory with  a  named  buffer.   Provided  a
     descriptor  block  (shown  below) it will get the port driver to give the
     buffer to the port.

             Call

             BLCAL. (SC.MAP,<SS.BLK>)

      Where:
             SS.BLK -- Address of the first entry in a chain of buffer
                             descriptor blocks.

             Return (+1)
             T1/     Error code

             Return (+2)
             T1/     Buffer name

             Buffer descriptor blocks have the following format:

              !=======================================================!
     .MDNXT   !    Address of next buffer descriptor (zero if none)   !
              !-------------------------------------------------------!
     .MDFLG   !                         Flags                         !
              !-------------------------------------------------------!
     .MDLEN   !                  Length of segment #0                 !
              !-------------------------------------------------------!
     .MDADR   !                Address of the segment #0              !
              !-------------------------------------------------------!
              \                                                       \
              \                                                       \
              \              segment descriptor pairs                 \
              \                                                       \
              \                                                       \
              !-------------------------------------------------------!
              !               Length of buffer segment #n             !
              !-------------------------------------------------------!
              !                Address of the segment #n              !
              !-------------------------------------------------------!
              !                       0                               !
              !=======================================================!

          The flags word has the following set of flags defined:

     1.  MD%DMD -- Two  bit  field  indicating  buffer  mode.   The  following
         settings are defined:
         MD%DIC -- Industry compatable
         MD%DCD -- Core dump
         MD%DHD -- High density
   SCA Functional specification                                   Page 45
   Writing a monitor SYSAP


     All other values are illegal.

          Note that .MDNXT and .MDFLG are offsets from the start of the  block
     to  the address of the next entry in the chain, but .MDLEN and .MDADR are
     offsets within the words describing a single buffer segment.
   SCA Functional specification                                   Page 46
   Writing a monitor SYSAP


     5.5.1.14  Unmap a buffer (SC.UMP)

                        - Unmap a buffer (SC.UMP) -

          This routine is called to unmap a buffer.  Note  that  this  routine
     must  be  called before the buffer will go away.  Hence if the routine is
     not called after all named buffer transfers are completed the buffer will
     stay  around  forever.   This enables the SYSAP to do multiple operations
     with the same buffer, without having to map the buffer every time.

             Call

             BLCAL. (SS.UMP,<SS.NAM>)

      Where:
             SS.NAM -- Name of buffer to be unmapped

             Return (+1)
             T1/     Error code

             Return (+2)
             No data, buffer name is no longer valid
   SCA Functional specification                                   Page 47
   Writing a monitor SYSAP


     5.5.1.15  Send named buffer data (SC.SND)

                    - Send named buffer data (SC.SND) -

          This routine sends block data from a named buffer.

     Note:
          One receive credit is required to do any named buffer transfer.

             Call
             BLCAL. (SC.SND,<SS.CID,SS.SNM,SS.RNM,SS.SOF,SS.ROF>)

      Where:
             SS.CID -- Connection on which this transfer is being done
             SS.SNM -- Name of the buffer to get data from
             SS.RNM -- Name of buffer to put data into
             SS.SOF -- Byte offset into transmission buffer
             SS.ROF -- Byte offset into reception buffer

             Return (+1)
             T1/     Error code

             Return (+2)
             No data returned.
   SCA Functional specification                                   Page 48
   Writing a monitor SYSAP


     5.5.1.16  Request remote named buffer transfer (SC.REQ)

             - Request remote named buffer transfer (SC.REQ) -

          This routine requests the transfer of data from a remote data buffer
     to  a  local one.  Note that do perform this function the SYSAP must have
     at least one receive credit.  This is due to the ports use of  a  message
     buffer from the message free queue on a named buffer operation.

             Call

             BLCAL. (SS.REQ,<SS.CID,SS.NOD,SS.SNM,SS.RNM,SS.SOF,SS.ROF>)

      Where:
             SS.CID -- Connection on which this transfer is being done
             SS.NOD -- Node number of remote host
             SS.SNM -- Name of remote buffer to get data from
             SS.RNM -- Name of local buffer to put data into
             SS.SOF -- Byte offset into transmission buffer
             SS.ROF -- Byte offset into reception buffer

             Return (+1)
             T1/     Error code

             Return (+2)
             No data returned.
   SCA Functional specification                                   Page 49
   Writing a monitor SYSAP


     5.5.1.17  Connect state poll (SC.CSP)

                      - Connect state poll (SC.CSP) -

          This routine returns information about the state of a connection.

             Call
             BLCAL.  (SC.CSP,<SS.CID,SS.FRE>)

             Where:
             SS.CID -- Connect ID of target connect
             SS.FRE -- Address of a free space block for returned info

             Return (+1)
             T1/     Failure code

             Return (+2)
             T1/     Address of returned data

          Note that it is the SYSAP that  provides  the  free  space  for  the
     return  of  data.   This  free  space  may be from an extended section or
     section zero.  The format of the retutned data is as follows:

              !=======================================================!
       .CDCST !                   Connection state                    !
              !-------------------------------------------------------!
       .CDDCI !                Destination Connect ID                 !
              !-------------------------------------------------------!
       .CDDPN !        Byte pointer to destination process name       !
              !-------------------------------------------------------!
       .CDSBI !                      Node number                      !
              !-------------------------------------------------------!
       .CDACB !              Address of connection block              !
              !-------------------------------------------------------!
       .CDREA ! Source disconnect reasons !  Dest disconnect reasons  !
              !=======================================================!

          The byte pointer to destination process name points to a  string  in
     an  SCA  database.  This is important to realize since the SYSAP must not
     change the indicated string.
   SCA Functional specification                                   Page 50
   Writing a monitor SYSAP


     5.5.1.18  Return destination connect ID (SC.DCI)

                 - Return destination connect ID (SC.DCI) -

          This  routine  returns  the  remotes  identifier   for   the   given
     connection.

             Call
             BLCAL. (SC.DCI,<SS.CID,SS.FRE>)

             Where:
             SS.CID -- Connect ID for target connection
             SS.FRE -- Address of free space into which data is to be returned

             Return (+1)
             T1/     Error code

             Return (+2)
             T1/     Destination connect ID for given connection
   SCA Functional specification                                   Page 51
   Writing a monitor SYSAP


     5.5.1.19  Return system configuration data (SC.RCD)

               - Return system configuration data (SC.RCD) -

          This routine returns information about a system.  To discover who is
     available  on  the  net  simply  call this routine for each possible node
     number.  Node numbers are guarenteed to start at zero and and at

             Call
             BLCAL.  (SC.RCD,<SS.NOD>)

      Where:
             SS.NOD -- Target node number

             Return (+1)
             T1/     Failure code

             Return (+2)
             T1/     Address of configuration data block


          The free space into which data is retuedn  may  be  in  an  extended
     section or section zero, and has the following format:


             !=======================================================!
      .RDSTS !   Virtual circuit state   !        Port number        !
             !-------------------------------------------------------!
      .RDSYS \                                                       \
             \      System address (6 8-bit bytes, word aligned)     \
             \                                                       \
             !-------------------------------------------------------!
      .RDMDG !           Maximum destination datagram size           !
             !-------------------------------------------------------!
      .RDMMS !           Maximum destination message size            !
             !-------------------------------------------------------!
      .RDDST !               Destination software type               !
             !-------------------------------------------------------!
      .RDDSV !             Destination software version              !
             !-------------------------------------------------------!
      .RDDSI !           Destination software incarnation            !
             !-------------------------------------------------------!
      .RDDHT !               Destination hardware type               !
             !-------------------------------------------------------!
      .RDDHV !             Destination hardware version              !
             !-------------------------------------------------------!
      .RDPRT \                                                       \
             \   Port characteristics (6 8-bit bytes, word aligned)  \
             \                                                       \
             !=======================================================!

          The format of the system name and port  characteristics  fields  are
     /TBD/.
   SCA Functional specification                                   Page 52
   Writing a monitor SYSAP


     5.5.1.20  Reset a remote system (SC.RST)

                     - Reset a remote system (SC.RST) -

          This routine sends  a  maintenance  reset  to  a  remote  node.   No
     checking  is done as to the node type.  If the remote does not honor such
     packets then the remote will simply  ignore  the  packet.   There  is  no
     direct  indication  to the local SYSAP as to whether the packet was taken
     or ignored.

             Call

             BLCAL. (SC.RST,<SS.NOD,SS.FRB>)

      Where:
             SS.NOD -- Node number of node to be reset
             SS.FRB -- Force reset bit, if one, reset is forced, if zero,
                          reset will only be done if we are the last node to do
                          a reset for this remote

             Return (+1)
             T1/     Error code

             Return (+2)
             No data returned, reset packet sent
   SCA Functional specification                                   Page 53
   Writing a monitor SYSAP


     5.5.1.21  Start a node (SC.STA)

                         - Start a node (SC.STA) -

          This routine sends a maintainance start a remote node.  No check  of
     remote  node type is done.  If the remote node does not honor this packet
     type then the remote will simply ignore the packet.  No direct indication
     of success or failure of the packet at the remote is provided.

             Call

             BLCAL. (SC.STA,<SS.NOD,SS.DSA,SS.STA>)

      Where:
             SS.NOD -- Node number of target remote
             SS.DSA -- Flag for use of SS.STA, if zero, SS.STA is ignored and
                             the default start address is used. If non-zero, SS.STA
                             is used as the start address of the remote.
             SS.STA -- Start address for the remote node. Only used if SS.DSA is
                             non-zero.

             Return (+1)
             T1/     Error code

             Return (+2)
             No data returned
   SCA Functional specification                                   Page 54
   Writing a monitor SYSAP


     5.5.1.22  Set port counters (SC.SPC)

                       - Set port counters (SC.SPC) -

          This function sets the port counters for a desired function.

             Call
             BLCAL. (SC.SPC,<SS.NOD,SS.CTL>)

             Where:
             SS.NOD -- Node number or 377 for all nodes
             SS.CTL -- Control word for port counters, bits as follows:

                           B0   If on, count ACKs received on Path A.
                           B1   If on, clear the counter.
                           B2   If on, count NAKs received on Path A.
                           B3   If on, clear the counter.
                           B4   If on, count NO_RSPs received on Path A.
                           B5   If on, clear the counter.
                           B6   If on, count ACKs received on Path B.
                           B7   If on, clear the counter.
                           B8   If on, count NAKs received on Path B.
                           B9   If on, clear the counter.
                           B10  If on, count NO_RSPs received on Path B.
                           B11  If on, clear the counter.
                           B12  The count of discarded datagrams because
                                of no DGFree Queue entries.
                           B13  If on, clear the counter.
                           B14  Count  the  packets  transmitted to  the
                                designated port.
                           B15  If on, clear the counter.
                           B16  Count  the  packets  received  from  the
                                designated port.
                           B17  If on, clear the counter.

             Return (+1)
             T1/     Error code

             Return (+2)
             No data retutned, port counters set
   SCA Functional specification                                   Page 55
   Writing a monitor SYSAP


     5.5.1.23  Read port counters (SC.RPC)

                      - Read port counters (SC.RPC) -

          This routine returns the values of the  port  counters.   It  is  an
     asynchronous  event.   The  routine will return immediatly but the answer
     will occur as the .SSRPC callback.


             Call
             BLCAL. (SC.RPC,<SS.ADR>)

             Where:
             SS.ADR -- Address of SCA allocated buffer into 
                               which data is to be returned

             Return (+1)
             T1/     Error code

             Return (+2)
             No data returned, .SSRPC callback will happen 
                                        when data is ready
   SCA Functional specification                                   Page 56
   Writing a monitor SYSAP


     5.5.1.24  Maintainance data send (SC.MDS)

                    - Maintainance data send (SC.MDS) -

     This routine requests a block tranfser write, in maintainance  mode.   No
     SCA  connection  or  port  circuit  are  required for this function.  The
     buffer must have been mapped with the SC.MAP call however.

             Call
             BLCAL. (SC.MDS,<SS.NOD,SS.SNM,SS.RNM,SS.XOF,SS.ROF,SS.ADR>)

             Where:
             SS.NOD -- Node number of target system
             SS.SNM -- Local buffer name for transfer
             SS.RNM -- Remote buffer name for transfer
             SS.XOF -- Transmit offset (in words)
             SS.ROF -- Receive offset (in words)
             SS.ADR -- Address to call when transfer is compelte

             Return (+1)
             T1/     Error code

             Return (+2)
             No data returned, notification by .SSMNT callback when completed
   SCA Functional specification                                   Page 57
   Writing a monitor SYSAP


     5.5.1.25  Maintainance data read (SC.MDR)

                    - Maintainance data read (SC.MDR) -

          This routine requests a block tranfser read, in  maintainance  mode.
     No  SCA  connection  or port circuit are required for this function.  The
     buffer must have been mapped with the SC.MAP call however.

             Call
             BLCAL. (SC.MDR,<SS.NOD,SS.SNM,SS.RNM,SS.XOF,SS.ROF,SS.ADR>)

             Where:
             SS.NOD -- Node number of target node
             SS.SNM -- Remote buffer name for transfer
             SS.RNM -- Local buffer name for transfer
             SS.XOF -- Transmit offset (in words)
             SS.ROF -- Receiver offset (in words)
             SS.ADR -- Address to call when transfer is complete

             Return (+1)
             T1/     Error code

             Return (+2)
             No data returned, .SSMNT callback when complete
   SCA Functional specification                                   Page 58
   Writing a monitor SYSAP


     5.5.1.26  Set online address (SC.SOA)

                      - Set online address (SC.SOA) -

          Notification of a node coming online happens on a  per  SYSAP  basis
     rather  than  on  a per connection basis.  Hence SCA must have an address
     for each SYSAP that wishes to be called when a new VC  has  been  opened.
     This  routine  sets  the  online  address  for the SYSAP.  Note that this
     routine does not know who calls it and will simply add  this  address  to
     the  list  of  notification  addresses.   It  does  not try to delete old
     entries if called twice by the same SYSAP.
          Note that this call will only allow .SSNCO callbacks to occur.   All
     other  callbacks  are  done  through  the address specified at connect or
     listen time.

             Call

             BLCAL. (SC.SOA,<SS.ADR>)

             Return (+1)
             T1/     Error code

             Return (+2)
             No data, address saved
   SCA Functional specification                                   Page 59
   Writing a monitor SYSAP


     5.5.1.27  Swap bytes from 11 to 10 format (SC.ISW)

                - Swap bytes from 11 to 10 format (SC.ISW) -

          This support routine swaps a single PDP-11 format word into a PDP-10
     format word.  Since this is a popular thing to do when talking to the HSC
     and friends this routine is global for access by the rest of the monitor.

             Call

             T1/     Word to be swapped

             Return (+1) Always
             T1/     Byte swapped word

      Input format:
             2 16 bit half words, left justified

      !=======================================================!
      !  B (lsb)  !  B (msb)  !  A (lsb)   !   A (msb)  ! IGN !
      !=======================================================!
      0          7 8        15 16        23 24        31 32  35

      Where A and B are the half words, and (lsb) are the least significant bits 
     and (msb) are the most significant bits.

     The contents of bits 32 thru 35 are ignored.


      Output format:
      2 18 bit half words,

      !=======================================================!
      !X!    Byte A (msb+lsb)     !X!     Byte B (msb +lsb)   !
      !=======================================================!
      0  2                      17    20                      35

      X denotes the 2 bit field within each halfword that 
      will always be zero.
   SCA Functional specification                                   Page 60
   Writing a monitor SYSAP


     5.5.1.28  SC.OSW (Swap word from 10 to 11 forma

                 - SC.OSW (Swap word from 10 to 11 format)

          This routine swaps a  single  word  from  PDP-10  format  to  PDP-11
     format.   Rather  than  be yet another in the long list of byte swappers,
     this routine is globally  available  to  the  rest  of  the  monitor  (in
     particular SYSAPs).

             Call

             T1/     Word to swap

             Return (+1) Always
             T1/     Byte swapped word

     Input format:
      2 18 bit half words,

      !=======================================================!
      !       Byte A (msb+lsb)     !     Byte B (msb +lsb)    !
      !=======================================================!
      0                          17 18                        35




      Output format:
             2 16 bit half words, left justified

      !=======================================================!
      !  B (lsb)  !  B (msb)  !  A (lsb)   !   A (msb)  ! IGN !
      !=======================================================!
      0          7 8        15 16        23 24        31 32  35

      Where A and B are the half words, and (lsb) are the least significant bits 
     and (msb) are the most significant bits.
   SCA Functional specification                                   Page 61
   Writing a monitor SYSAP


     5.5.1.29  Return node number given CID (SC.SBI)

                 - Return node number given CID (SC.SBI) -

          This routine returns the node number of the remote end of the  given
     CID.

             Call
             BLCAL. (SC.SBI,<SS.CID>)

             Where:
             SS.CID -- Connect ID of target connection

             Return (+1) Always
             T1/     Local connect ID
             T2/     Node number of the remote end of the connection specified
   SCA Functional specification                                   Page 62
   Writing a monitor SYSAP


     5.5.1.30  Return credit info (SC.RAC)

                      - Return credit info (SC.RAC) -

          This routine returns the current  credit  levels  for  a  particular
     connection.  This routine is not interlocked, hence the credit counts may
     be incorrect by the time SCAMPI returns from the PUSHJ.  The  usual  case
     is  SCAMPI  is  interrupted  in  the  middle of this routine by a message
     arriving for this connection.  This means the  receive  credits  will  be
     wrong.   If  the  SYSAP sends a reply at interrupt level the send credits
     will be wrong as well.  Since most connections maintain a large number of
     credits  this routine will at least give a ballpark figure.  If the SYSAP
     knows that it will not be getting  any  messages  or  if  it  calls  this
     routine CIOFF then the counts will be correct.

             Call
             BLCAL. (SC.RAC,<SS.CID>)

             Where:
             SS.CID -- Connect ID of connection whose credits
                             are desired

             Return (+1)
             T1/     Error code

             Return (+2)
             T1/     Send credit
             T2/     Receive credit
             T3/     Number of datagram buffers queued
   SCA Functional specification                                   Page 63
   Writing a monitor SYSAP


     5.5.1.31  Return local port number (SC.PRT)

                   - Return local port number (SC.PRT) -

          This routine returns  the  node  number  of  the  local  node.   The
     assumption is made that this is a KL with only one KLIPA.

             Call
             No arguments

             Return (+1)
             Error code

             Return (+2)
             T1/     Local node number
             T2/     Reserved
             T3/     Reserved
             T4/     Reserved
   SCA Functional specification                                   Page 64
   Writing a monitor SYSAP


     5.5.1.32  Allocate a datagram buffer (SC.ALD)

                  - Allocate a datagram buffer (SC.ALD) -

          This routine will allocate datagram buffers from the SCA free  pool.
     It is from this pool that all buffers on the port free queues originated.
     If desired the  SYSAP  can  use  buffers  from  this  pool  for  outgoing
     datagrams  and  have  the  buffer  placed  on  the  port  free  queue  on
     transmission completion.
          When more than one  buffer  has  been  requested,  the  buffers  are
     chained  together  with  the link in the zeroth word of each buffer.  The
     link word always points to word zero of the next buffer.  The last buffer
     has a link word of zero.

             Call
             T1/     Number of buffers desired

             Return (+1)
             T1/     Error code

             Return (+2)
             T1/     Address of first buffer on chain
             T2/     Number of buffers returned
             T3/     Address of routine to return buffers
   SCA Functional specification                                   Page 65
   Writing a monitor SYSAP


     5.5.1.33  Allocate a message buffer (SC.ABF)

                   - Allocate a message buffer (SC.ABF) -

          This routine allocates message buffers from the SCA free  pool.   If
     desired the SYSAP may use these buffers for message transmission and have
     the buffer placed on the port free queue on send completion.   Also  note
     that  these  buffers  have the invisible area described in the section on
     SCA buffers.
          When more than one  buffer  has  been  requested,  the  buffers  are
     chained  together  with  the link in the zeroth word of each buffer.  The
     link word always points to the zeroth word of the next buffer.  The  last
     buffer has a link word of zero.

             Call
             T1/     Number of buffers desired

             Return (+1)
             T1/     Error code (No buffers returned)

             Return (+2)
             T1/     Address of first buffer on chain
             T2/     Number of buffers returned
             T3/     Address of routine to return buffers
   SCA Functional specification                                   Page 66
   Writing a monitor SYSAP


     5.5.1.34  Return a message buffer (SC.RBF)

                    - Return a message buffer (SC.RBF) -

          This routine is  used  to  return  buffers  to  the  SCA  free  pool
     allocated with SC.ABF.  Although buffers can be allocated in chains, they
     may not be returned that way.  A buffer is returned one at a time.  Hence
     the link word of the buffer is ignored.

             Call
             T1/     Address of buffer to be returned

             Return (+1) Always
             No data returned, buffer returned OK







     5.5.1.35  Return a datagram buffer (SC.RLD)

                   - Return a datagram buffer (SC.RLD) -

          Datagram buffer allocated with SC.ALD must be returned  to  the  SCA
     free  pool  with  this  routine.   Although  buffers  may be allocated in
     chains, they must be returned one at a time.  Hence the link word in each
     buffer is ignored.

             Call
             T1/     Address of buffer to be returned

             Return (+1) Always
             No data returned, buffer has been returned
                     to SCA free pool
   SCA Functional specification                                   Page 67
   Writing a monitor SYSAP


     5.5.2  SCA to SYSAP interface

          The following is the complete set of callbacks that  the  SYSAP  can
     expect to see from SCA.

     General format of returned information:
             T1/     Function code
             T2-T4/  Function code dependant additional data

             Context: List of possible contexts for this callback. I.E.
                             the contexts the SYSAP may see during this callback

     -       -       -       -       -       -       -       -       -       -

     .SSDGR
     Datagram received. SCA is indicating that the CI has filled one of the buffers
     queued for datagram reception with a datagram. 
             T1/     .SSDGR
             T2/     Connect ID
             T3/     Address of datagram buffer
             T4/     <FLAGS>B5 ! <Addr of routine to return buffer>B35
                     (See SC.SDG for flag definitions)

      .MHPKL word of datagram buffer/
                     Length of the packet (Bytes for industry compatable, words
                                             for high density)

             Context: Interrupt

     -       -       -       -       -       -       -       -       -       -

     .SSMGR
     Message received. SCA is indicateing that you have received a message from the
     CI.
             T1/     .SSMGR
             T2/     Connect ID
             T3/     Address of message buffer
             T4/     <FLAGS>B5 ! <Addr of routine to return buffer>B35
                     (See SC.SDG for flag definitions)

      .MHPKL word of msg buffer/
                     Length of the packet (Bytes for industry compatable, words
                                             for high density)

             Context: Interrupt
     -       -       -       -       -       -       -       -       -       -

     .SSPBC
     Port broke connection. The port hardware detected a fatal error for the
     port virtual circuit on which you had a connection. Thus it broke your
     connection.
             T1/     .SSPBC
             T2/     Connect ID
             T3/     Unused
   SCA Functional specification                                   Page 68
   Writing a monitor SYSAP


             T4/     Unused

             Context: Interrupt, scheduler

     -       -       -       -       -       -       -       -       -       -

     .SSCTL
     Connection to listen. The listen done for you has been matched to a remote 
     connect request.
             T1/     .SSCTL
             T2/     Connect ID
             T3/     Address to connection data from remote system
             T4/     Unsued

             Context: Interrupt
     -       -       -       -       -       -       -       -       -       -

     .SSCRA
     Connection response available. The system to which you sent a connect message 
     has responded.
             T1/     .SSCRA
             T2/     Connect ID
             T3/     -1 for accepted, 0 for rejected connection
             T4/     Reject code (If rejected), pointer to connect data if accepted

             Context: Interrupt

     -       -       -       -       -       -       -       -       -       -

     .SSMSC
     Message/datagram Send complete. The message/datagram which you requested be 
     sent, has been. The "buffer address" is the address of the buffer you gave 
     SCA to send.
             T1/     .SSMSC
             T2/     Connect ID
             T3/     Address of buffer
             T4/     Length of buffer in bytes for ind. compat/words for high den
                             This is the length of the text portion, and does not
                             include SCA headers.

             Context :Interrupt

     -       -       -       -       -       -       -       -       -       -

     .SSLCL
     Little credit left. You have just received a message that put you under
     receive credit threshold. It is suggested that you queue at least some buffers
     if you expect to get more messages. Note that you will receive one of these
     calls every time you receive a message after which you are under threshold.
             T1/     .SSLCL
             T2/     Connect ID
             T3/     Number of credits needed to get you over threshold
             T4/     Unused
   SCA Functional specification                                   Page 69
   Writing a monitor SYSAP


             Context: Interrupt

     -       -       -       -       -       -       -       -       -       -

     .SSNCO
     Node came online. You requested to be told of nodes coming online.
     It happened and now you're being told.

             T1/     .SSNCO
             T2/     Node number of system that has come online
             T3/     Unused
             T4/     Unused

             Context: Interrupt, scheduler

     -       -       -       -       -       -       -       -       -       -

     .SSOSD
     OK to send data. The connection has been completed to a remote system and is
     now in the OPEN state. Messages and datagram may be sent.

             T1/     .SSOSD
             T2/     Connect ID
             T3/     Unused
             T4/     Unused

             Context: Interrupt

     -       -       -       -       -       -       -       -       -       -

     .SSRID
      Remote initiated disconnect. The host at the other end of your connection
     doesn't want to talk to you anymore and has completed an orderly shutdown of
     your connection.

             T1/     .SSRID
             T2/     Connect ID
             T3/     Unused
             T4/     Unused

             Context: Interrupt

     -       -       -       -       -       -       -       -       -       -

     .SSCIA
     Credit is available. Your message send failed for lack of credit. There is
     now more credit available for your send.

             T1/     .SSCIA
             T2/     Connect ID
             T3/     Current send credit
             T4/     Current receive credit

             Context: Interrupt
   SCA Functional specification                                   Page 70
   Writing a monitor SYSAP



     -       -       -       -       -       -       -       -       -       -

     .SSNWO
      Node went offline. The remote end of your connection has just dropped 
     offline. After this callback, all data about the connection will be deleted.

             T1/     .SSNWO
             T2/     CID for connect you had on offline node
             T3/     Unused
             T4/     Unused

             Context: Interrupt, scheduler

     -       -       -       -       -       -       -       -       -       -

     .SSDMA
      Named buffer operation complete. The named buffer operation you requested 
     has been completed. Note that you will NOT be told about the completion of 
     passive requests. I.E. you will not be notified when a request/send data 
     done by a remote completes.

             T1/     .SSDMA
             T2/     Connect ID of connection tranfers was done for
             T3/     Buffer name of named buffer
             T4/     Unused

             Context: Interrupt

     -       -       -       -       -       -       -       -       -       -

     .SSDDG
      Dropped datagram. SCA received a datagram for this connection and dropped it
     since you had no buffers left. The buffer was returned to the port free queue.
     Note that this is a software detected datagram drop. If the port drops the
     datagram because there are no buffers on the port queue, this call back will
     not happen.

             T1/     .SSDDG
             T2/     Connect ID
             T3/     Unused
             T4/     Unused

             Context: Interrupt

     -       -       -       -       -       -       -       -       -       -

     .SSMNT
     Maintainance data send/receive complete.

             T1/     .SSMNT
             T2/     Buffer name of completed transfer
             T3/     Unused
             T4/     Unused
   SCA Functional specification                                   Page 71
   Writing a monitor SYSAP



             Context: Interrupt

     -       -       -       -       -       -       -       -       -       -

     .SSRPC
     Read port counters response. The request for reading the port counters has
     completed and here is your answer.

             T1/     .SSRPC
             T2/     Connect ID of requesting connect
             T3/     Address of packet containing counter data
             T4/     Unused

             The following is the format of the counter data:

             !=======================================================!
             \                                                       \
             \                      Port header                      \
             \                                                       \
             !-------------------------------------------------------!
     .PCMCV  !                   Microcode version                   !
             !-------------------------------------------------------!
     .PCAAC  !                   Path A ACK count                    !
             !-------------------------------------------------------!
     .PCANC  !                   Path A NAK count                    !
             !-------------------------------------------------------!
     .PCANR  !               Path A no response count                !
             !-------------------------------------------------------!
     .PCBAC  !                   Path B ACK count                    !
             !-------------------------------------------------------!
     .PCBNC  !                   Path B NAK count                    !
             !-------------------------------------------------------!
     .PCBNR  !               Path B no response count                !
             !-------------------------------------------------------!
     .PCDGD  !                  Datagrams discarded                  !
             !-------------------------------------------------------!
     .PCPTX  !                  Packets transmitted                  !
             !-------------------------------------------------------!
     .PCPRX  !                   Packets received                    !
             !-------------------------------------------------------!
     .PCDPT  !                    Designated port                    !
             !-------------------------------------------------------!
             \                                                       \
             \                 Reserved for software                 \
             \                                                       \
             !=======================================================!
   SCA Functional specification                                   Page 72
   Writing a JSYS SYSAP


     6.0  Writing a JSYS SYSAP

          This section is a detailed review of the differences between writing
     monitor  level  SYSAPs and user level SYSAPs.  The concepts are identical
     for the  two  SYSAP  types,  but  the  implementation  details  are  very
     different.   In  the reading of the following sections it is assumed that
     the sections on monitor level SYSAPs has been read.



     6.1  General rules

     6.1.1  Communicating with SCA

          When writing monitor level code SYSAPs communicate with SCA  through
     subroutine  calls.   The  SYSAP  obtains  services  from  SCA  by calling
     routines in SCA, and SCA returns event  information  by  calling  routine
     addresses  specified  by the SYSAP.  When writing JSYS code, services are
     obtained by executing the JSYS, and SCA  communicates  event  information
     through a series of PSIs.  In all there are four PSIs that the JSYS level
     SYSAP may have to handle.  One each  for  incoming  messages,  datagrams,
     named  buffer  completions  and  all other events.  If the SYSAP does not
     require some of these services then the PSI need not be enabled.



     6.1.1.1  Using the SCS% with the PSI system

          When using the PSI system with SCA keep in mind that the  SCS%  call
     to  add  channel must be done in addition to the usual set of JSYS calls.
     The SCS% call simply lets SCA know which channels  are  to  be  used  for
     which  event  types.   The  SIR%,  AIC%,  EIR%  (and their extended third
     cousins) etc.  must still be used to specify and enable the PSI system.



     6.1.2  Buffer management

          Buffer management for the JSYS SYSAP is  very  different  than  that
     done  for  monitor  SYSAPs.   There  are  still  four basic buffer types,
     messages and datagrams, both of which can be incoming or outgoing.



     6.1.2.1  Incoming buffers

          Buffers queued for reception of messages and datagrams must be large
     enough  to  handle  the largest packet possible.  The correct buffer size
     for messages is thirty eight (38) words, for datagrams this size  is  one
     hundred  fifty  two (152) words.  These buffers are queued in chains much
     the way they are in the monitor.  These buffers are  not  placed  on  the
     port  queues  however.   Monitor  internal buffers are placed on the port
     queues and data is BLTed to user space when it  arrives.   When  data  is
     moved  the  length to be BLTed is obtained from the packet.  Hence if the
   SCA Functional specification                                   Page 73
   Writing a JSYS SYSAP


     buffer is to short the end of the buffer will be BLTed over.  This is why
     the buffer must be at least as long as the longest packet possible.



     6.1.2.2  Outgoing buffers

          Buffers used for packets transmission need only be as  long  as  the
     packet text.  There are no other restrictions on these buffers.



     6.1.3  The race condition

          Something which comes  up  when  coding  a  monitor  SYSAP  is  that
     interlocking  further CI traffic is easy.  JSYS SYSAPs do not have things
     quite so simple.  In particular  there  is  a  race  that  a  JSYS  SYSAP
     designer should be aware of.  When a JSYS SYSAP does a listen, he is told
     about a connection to that listen with a PSI.  As soon as the  connection
     comes  in  and  the  match is found, the monitor changes the state of the
     connect to connectreceived rather than listen.  Hence if another  connect
     request  comes  in for that SYSAP before it has been told about the first
     connect request, then the second one will fail at the SCA level since  no
     match  can  be  found even though the SYSAP would likely want to see that
     connect.
          One reasonable solution to this problem is based on an understanding
     of  the  problem  by  both  the  active  and passive sides of the connect
     mechanism.  The listener should open more than  one  listen  (keeping  in
     mind  that  they do use system resources), and the connector should retry
     connect attempts if they fail.
   SCA Functional specification                                   Page 74
   Writing a JSYS SYSAP


     6.2  JSYS SYSAP interface

          The following is the general format of a call to the SCS% JSYS.


             Call
             T1/     Function code
             T2/     Address of arg block


             Return (+1) Always
             T1/     Function code
             T2/     Address of arg block
             
             An error generates an illegal instruction trap.

     General format of the argument block:

              !=======================================================!
     .SQLEN   !      Words processed      !     Length of block       !
              !-------------------------------------------------------!
              \                                                       \
              \             Function dependent arguments              \
              \                                                       \
              !=======================================================!

          Where the "words processed" is the number of words in  the  argument
     block  that the monitor actually looked at and used.  Hence this field is
     returned by the monitor, not supplied by the user.  The "length of block"
     is the total length of the supplied block including the header word.
          Note that this JSYS  requires  one  or  any  combination  of  wheel,
     maintenance, or network wizard.
   SCA Functional specification                                   Page 75
   Writing a JSYS SYSAP


     6.2.1  Connect (.SSCON)

                              Connect (.SSCON)



          This function requests a connection with another process on the  CI.
     The  JSYS  will  return  as soon as the connection request has been sent.
     You are notified that your connection request was granted or failed via a
     PSI interrupt.

     The argument block has the following format:

              !=======================================================!
     .SQLEN   !      Words processed      !     Length of block       !
              !-------------------------------------------------------!
     .SQSPN   !          Byte pointer to source process name          !
              !-------------------------------------------------------!
     .SQDPN   !       Byte pointer to destination process name        !
              !-------------------------------------------------------!
     .SQSYS   !   Node # of destination   !    SYSAP field for CID    !
              !-------------------------------------------------------!
     .SQCDT   !               Pointer to connection data              !
              !-------------------------------------------------------!
     .SQAMC   !    Address of first buffer on message buffer chain    !
              !-------------------------------------------------------!
     .SQADC   !    Address of first buffer on datagram buffer chain   !
              !-------------------------------------------------------!
     .SQRCI   !                  Returned connect ID                  !
              !=======================================================!



     The byte pointer to the source process name is  a  byte  pointer  to  the
     ASCII  string  which  is the name of your process.  Note that this string
     must end on a null byte and may be  a  maximum  of  16  bytes  long,  not
     including the null byte.

     The byte pointer to destination process name is the byte pointer  to  the
     name of the process you wish to connect to.  This name must also end in a
     null byte and may be a maximum of 16 bytes, not including the null byte.

     The node number is the unique  identifier  of  the  system  you  wish  to
     connect to.

     Note that the specified strings may be any valid ASCII  byte  size  (I.E.
     any byte size equal to or larger than 7 bits).  These strings may also be
     generic byte pointers (-1,,STRNG).  If generic byte pointers are given, 7
     bit ASCII terminated by a null byte is assumed.

     The "SYSAP field for CID" is the right justified value to be placed  into
     the SYSAP field of the connect ID created for the connection.  These bits
     are generally used for connection management by the user program.
   SCA Functional specification                                   Page 76
   Writing a JSYS SYSAP


     The pointer to connection data is the address of a block of  data  SQ%CDT
     words  long  to  be  sent as connection data.  Note that the monitor will
     copy SQ%CDT words of data from the users address  space.   Hence  a  full
     block SQ%CDT words long should be allocated for the data.


                              - Error codes -
     SCSNEP,SCSBTS,SCSISB,SCSNSN,SCSENB,SCSIAB,SCSIBP,SCSNBA
   SCA Functional specification                                   Page 77
   Writing a JSYS SYSAP


     6.2.2  Listen (.SSLIS)

                              Listen (.SSLIS)



          This function listens for a connection.  Note that the JSYS does not
     block.   You  will  be  notified  of  a  connect to your listen via a PSI
     interrupt.
          There are a number of options that may be used when doing  a  listen
     for  a  connection.   You  may  listen  for a particular process from any
     system by making the node number -1.  You may listen for any process from
     a particular system by making the byte pointer to the destination process
     name -1.  If the node number and the  byte  pointer  to  the  destination
     process  name  are  both  -1,  then any connect request that is not for a
     particular process name  will  match  your  listen.   Naturally  you  may
     specify  both a node number and a process name and then only that process
     from the named system will be allowed to connect to your listen.



              !=======================================================!
     .SQLEN   !      Processed words     !       Length of block      !
              !-------------------------------------------------------!
     .SQSPN   !          Byte pointer to source process name          !
              !-------------------------------------------------------!
     .SQDPN   !       Byte pointer to destination process name        !
              !-------------------------------------------------------!
     .SQSYS   !  Node # of destination   !    SYSAP field for CID     !
              !-------------------------------------------------------!
     .SQLCI   !                Returned connect ID                    !
              !=======================================================!



          The fields defined here are identical to those used by  the  connect
     call.   The  only difference is the absence of some of the fields used in
     the connect call.


                              - Error codes -
     SCSNBA,SCSNEP,SCSBTS,SCSISB,SCSNSN,SCSENB
   SCA Functional specification                                   Page 78
   Writing a JSYS SYSAP


     6.2.3  Accept (.SSACC)

                        Accept a connection (.SSACC)



          This function tells a remote  process  that  you  are  granting  his
     request for a connection.



             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !                      Connect ID                       !
             !-------------------------------------------------------!
      .SQCDA !              Pointer to connection data               !
             !=======================================================!



          The pointer to connection data  is  the  address  of  the  block  of
     connection  data  to be sent to the remote system.  The monitor will copy
     SQ%CDT words of data from the users address space  as  data.   Note  that
     this  data will be sent directly over the CI and hence the low order four
     bits are not sent.


                              - Error codes -
     SCSNEP,SCSBTS,SCSIID,SCSCWS,SCSNBA
   SCA Functional specification                                   Page 79
   Writing a JSYS SYSAP


     6.2.4  Reject (.SSREJ)

                        Reject a connection (.SSREJ)



          This function code tells a remote process that you are not  allowing
     a connection to your process.

     The argument block for this function has this format:

             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !                      Connect ID                       !
             !-------------------------------------------------------!
      .SQREJ !                   Rejection reason                    !
             !=======================================================!



          The rejection reason is a code, invented by the SYSAP, (outside  the
     revserved  range  /TBD/  codes)  which  indicates  why the connection was
     rejected.


                              - Error codes -
     SCSBTS,SCSIID,SCSNBA,SCSCWS,SCSNEP
   SCA Functional specification                                   Page 80
   Writing a JSYS SYSAP


     6.2.5  Disconnect (.SSDIS)

                            Disconnect (.SSDIS)



          This function closes a connection.  Note that the connection must be
     open  to  use  disconnect.   The  disconnect  function  code requires the
     following arguments:



             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !                      Connect ID                       !
             !-------------------------------------------------------!
      .SQDIS !                   Disconnect reason                   !
             !=======================================================!



          The disconnect reason is a SYSAP invented code (outside the reserved
     range /TBD/) which indicates why the connection was disconnected.


                              - Error codes -
     SCSNEP,SCSBTS,SCSIID,SCSCWS,SCSNBA
   SCA Functional specification                                   Page 81
   Writing a JSYS SYSAP


     6.2.6  Send a DG (.SSSDG)

                          Send a datagram (.SSSDG)



          This function code sends a datagram.

     The following arguments are required:


             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !                      Connect ID                       !
             !-------------------------------------------------------!
      .SQAPT !               Address of datagram text                !
             !-------------------------------------------------------!
      .SQLPT ! Len of message,high density (words), industry (bytes) !
             !-------------------------------------------------------!
      .SQFLG !                        Flags                  !  OPS  !
             !=======================================================!


          OPS is the path selection field.  OPS allows the JSYS user to select
     the  path over which the packet is to be sent.  The following setting are
     allowed for OPS:
             0 --> Automatic path selection
             1 --> Use path A
             2 --> Use path B
          If automatic path selection is chosen, the port hardware selects the
     path to use.

     The currently defined flags are:

             SC%MOD --> Packet transmission mode: 0 = industry compatable
                                                  1 = high density

                            *** Restrictions ***

     1.  If the datagram is to be sent in industry compatable mode,  the  text
         must be packed in left justified, word aligned, eight bit bytes.

     2.  The datagram text may not be  longer  than  152  (decimal)  words/608
         bytes  long.   The  byte count is for industry compatable packets and
         the word count for high density packets.



                              - Error codes -
     SCSNEP,SCSBTS,SCSIID,SCSDCB,SCSIAA,SCSNBA,SCSCWS,SCAMTL
   SCA Functional specification                                   Page 82
   Writing a JSYS SYSAP


     6.2.7  Queue a DG buffer (.SSQRD)

               Queue a buffer for datagram reception (.SSQRD)



          This function code queues buffers for datagram reception.
          Note that in each buffer the first word is the address of  the  next
     buffer.   The  last  buffer  has  zero as the address of the next buffer.
     This function requires these arguments:


             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !                      Connect ID                       !
             !-------------------------------------------------------!
      .SQAFB !        Address of first buffer on buffer chain        !
             !=======================================================!


                            *** Restrictions ***


     1.  Datagram buffers must be 152 words in length.



                              - Error codes -
     SCSNEP,SCSIID,SCSNBA,SCSBTS
   SCA Functional specification                                   Page 83
   Writing a JSYS SYSAP


     6.2.8  Send message (.SSSMG)

                          Send a message (.SSSMG)



          This function code sends a message to a remote node.

             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !                      Connect ID                       !
             !-------------------------------------------------------!
      .SQAPT !                Address of message text                !
             !-------------------------------------------------------!
      .SQLPT !  Len of message,high density (words), industry (bytes)!
             !-------------------------------------------------------!
      .SQFLG !                        Flags                  !  OPS  !
             !=======================================================!


          OPS is the path selection field.  OPS allows the JSYS user to select
     the  path over which the packet is to be sent.  The following setting are
     allowed for OPS:
             0 --> Automatic path selection
             1 --> Use path A
             2 --> Use path B
          If automatic path selection is chosen, the port hardware selects the
     path to use.
          The flags definitions may be found in the section for .SSSDG.


                            *** Restrictions ***

     1.  If this is an industry compatable  message  then  the  text  must  be
         packed in left justified 8 bit bytes.

     2.  Message text may not be longer than 38 36 bit words (152 bytes).



                              - Error codes -
     SCSIID,SCSNEP,SCSNBA,SCSBTS,SCSNSH,SCSDCB,SCSIAA
   SCA Functional specification                                   Page 84
   Writing a JSYS SYSAP


     6.2.9  Queue message receive buffers (.SSQRM)

                   Queue message receive buffers (.SSQRM)



          This function code queues buffers to receive  messages.   Note  that
     the  buffer size is fixed at 38, 36 bit words.  It requires the following
     arguments:


             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !                      Connect ID                       !
             !-------------------------------------------------------!
      .SQAFB !            Address of buffer chain to queue           !
             !=======================================================!


                              - Error codes -
     SCSNEP,SCSIID,SCSNBA,SCSBTS
   SCA Functional specification                                   Page 85
   Writing a JSYS SYSAP


     6.2.10  Cancel DG receive (.SSCRD)

                      Cancel datagram receive (.SSCRD)



          This function code removes a buffer queued for  datagram  reception.
     The  address  that  you  specify must be the address of a buffer that was
     previously queued for receiving datagrams (with .SSQRD).  If this address
     is  not  found  by the monitor when it goes to take the buffer out of its
     queue, the JSYS fails with an illegal instruction  trap.   This  function
     requires these arguments:


             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !                      Connect ID                       !
             !-------------------------------------------------------!
      .SQADB !             Address of buffer to dequeue              !
             !=======================================================!


                              - Error codes -
     SCSNSC,SCSNEP,SCSBTS,SCSNSB,SCSNEB
   SCA Functional specification                                   Page 86
   Writing a JSYS SYSAP


     6.2.11  Cancel receive message (.SSCRM)

                      Cancel receive message (.SSCRM)



          The  function  dequeues  a  buffer  that  was  queued  for   message
     reception.  The buffer address that is specified must be of a buffer that
     you asked to be queued for  message  reception  (with  .SSQRM).   If  the
     monitor does not find the address specified in the argument block amongst
     the buffers you queued, the JSYS will fail.  This function  requires  the
     following arguments:


             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !                      Connect ID                       !
             !-------------------------------------------------------!
      .SQADB !             Address of buffer to dequeue              !
             !=======================================================!



                              - Error codes -
     SCSNSC,SCSNEP,SCSBTS,SCSNSB,SCSNEB
   SCA Functional specification                                   Page 87
   Writing a JSYS SYSAP


     6.2.12  Connect state poll (.SSCSP)

                        Connect state poll (.SSCSP)



          This function returns information about the state of  a  connection.
     The argument block to this function includes space for the returned data.
     The following is the format or the argument block:



             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !                      Connect ID                       !
             !-------------------------------------------------------! ------------
      .SQCST !                   Connection state                    !      ^
             !-------------------------------------------------------!      !
      .SQDCI !                Destination connect ID                 !      !
             !-------------------------------------------------------!   Returned
      .SQBDN !       Byte pointer to destination process name        !     data
             !-------------------------------------------------------!      !
      .SQSBI !               Node number of destination              !      !
             !-------------------------------------------------------!      !
      .SQREA ! Source disconnect reasons !  Dest disconnect reasons  !      v
             !=======================================================! ------------


          Note that the byte pointer  to  destination  process  name  must  be
     provided by the caller and may be either a real byte pointer or minus one
     in the left half and the base address of the string in  the  right  half.
     If  the  generic byte pointer is used the monitor assumes the string is 7
     bit ASCII terminted with a null byte, or the  16th  chatacter,  whichever
     comes first.


                              - Error codes -
     SCSNEP,SCSBTS,SCSIID
   SCA Functional specification                                   Page 88
   Writing a JSYS SYSAP


     6.2.13  Return local node number (.SSGLN)

                     Return local node number (.SSGLN)



          This function returns the local node number.  If  the  machine  does
     not  have  a  KLIPA,  then  an  illegal  instruction  is  generated.  The
     following is the argument block format:


             !=======================================================!
      .SQLEN !      Processed words      !      Length of block      !
             !-------------------------------------------------------!
      .SQLNN !                 Local CI node number                  ! Returned data
             !=======================================================!




                              - Error codes -
     SCSBTS,SCSNKP
   SCA Functional specification                                   Page 89
   Writing a JSYS SYSAP


     6.2.14  Return configuration data (.SSRCD)

                     Return configuration data (.SSRCD)



          This function returns data about another  system.   Given  the  node
     number  the  monitor  will  return  data  about that system.  The data is
     returned in the block pointed to by T1 which looks like this:


             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !                  Optional connect ID                  !
             !-------------------------------------------------------!
      .SQOSB !                 Optional  node number                 !
             !-------------------------------------------------------!  -----------
      .SQVCS !   Virtual circuit state   !        Port number        !       ^
             !-------------------------------------------------------!       !
      .SQSAD \                                                       \       !
             \     System address (6 8-bit bytes, word aligned)      \       !
             \                                                       \       !
             !-------------------------------------------------------!       !
      .SQMDD !           Maximum destination datagram size           !       !
             !-------------------------------------------------------!       !
      .SQMDM !           Maximum destination message size            !    Returned
             !-------------------------------------------------------!      data
      .SQDST !               Destination software type               !       !
             !-------------------------------------------------------!       !
      .SQDSV !             Destination software version              !       !
             !-------------------------------------------------------!       !
      .SQDSE !            Destination software edit level            !       !
             !-------------------------------------------------------!       !
      .SQDHT !               Destination hardware type               !       !
             !-------------------------------------------------------!       !
      .SQDHV !             Destination hardware version              !       !
             !-------------------------------------------------------!       !
      .SQPCW \               Port characteristics bytes              \       !
             \    6, 8 bit bytes, word aligned in leftmost 32 bits   \       !
             !-------------------------------------------------------!       !
      .SQLPN !                  Local port number                    !       v
             !=======================================================!  ------------


          The connect ID and node number are optional in that one or the other
     must  be  specified,  but  not both.  If the connect ID field is non-zero
     then the node number is ignored and the information returned is  for  the
     system  implied  by the connect ID.  If the connect ID field is zero then
     the node number is used.  Note that this allows the use of node zero.

          If the local port number is not available, -1 will  be  returned  to
     the user in offset .SQLPN.
   SCA Functional specification                                   Page 90
   Writing a JSYS SYSAP


                              - Error codes -
     SCSNEP,SCSBTS,SCSIID,SCSISB
   SCA Functional specification                                   Page 91
   Writing a JSYS SYSAP


     6.2.15  Return buffer sizes (.SSRBS)

                        Return buffer sizes (.SSRBS)



          This function returns the sizes of the various buffers  SCA  expects
     to  see.   In  particular  it  returns  the  size of message and datagram
     buffers.  It requires the following arguments:

             !=======================================================!
     .SQLEN  !       Process words       !       Block length        !
             !-------------------------------------------------------! -------------
     .SQLMG  !          Length in words of message buffers           !       ^
             !-------------------------------------------------------!       !
     .SQLDG  !          Length in words of datagram buffers          !   Returned
             !-------------------------------------------------------!     data
             !                       Reserved                        !       !
             !-------------------------------------------------------!       !
             !                       Reserved                        !       v
             !=======================================================! -------------
   SCA Functional specification                                   Page 92
   Writing a JSYS SYSAP


     6.2.16  Return status information (.SSSTS)

                     Return status information (.SSSTS)



          This function returns status information about a connection.  It  is
     intended  as  a  fast  form  of  the  .SSCSP  function code which returns
     detailed information about a  connection.   This  function  requires  the
     following arguments:

             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !                      Connect ID                       !
             !-------------------------------------------------------!
      .SQFST !           Flags          !       Connect state        ! -------------
             !-------------------------------------------------------!    Returned
      .SQSBR !         Reserved         !     Node # of remote       !      data
             !=======================================================! -------------


          The flags which appear in the flags field are:

     1.  Message available (SQ%MGA)- There is at least one  message  available
         for this connection.

     2.  Datagram  available  (SQ%DGA)  -  There  is  at  least  one  datagram
         available for this connection.

     3.  Named buffer transfer complete (SQ%DMA) - At least one  named  buffer
         transfer  has  completed  since  the  last  time  the  SCS%  JSYS was
         performed with this function code.  The bit is cleared in the monitor
         data base when this function code is performed.



                              - Error codes -
     SCSBTS,SCSNEP,SCSIID
   SCA Functional specification                                   Page 93
   Writing a JSYS SYSAP


     6.2.17  Get a queue entry

          There are four functions for removing things from queues.  One  each
     for messages, datagrams, named buffer transfer competions, and "all other
     events".  In each case the monitor will issure a PSI for the  appropriate
     fork  when  when  of  these  queues goes non-empty.  The monitor will not
     issue a PSI for each entry.  It is the responsibility  of  the  SYSAP  to
     empty the queue once it has seen the PSI.



     6.2.17.1  Receive a message (.SSRMG)

                         Receive a message (.SSRMG)



          This function code returns message text for either the calling  fork
     or  the  specified  connection.   If the connect ID field in the argument
     block is minus one, then the first message found for the calling fork  is
     returned.   If the connect ID is anything but minus one (-1), the monitor
     will use this as a connect ID and return the first message found for that
     connection.   Note  that  if  there  is  no  message available an illegal
     instruction is generated.  The following argument block is  required  for
     this function code.


             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------! -----------
      .SQCID !                  Connect ID or -1                     !      ^
             !-------------------------------------------------------!      !
      .SQARB !              Address of returned buffer               !      !
             !-------------------------------------------------------! Returned data
      .SQDFL !          Flags           !       Node # of remote     !      !
             !-------------------------------------------------------!      !
      .SQLRP !               Length of returned packet               !      v
             !=======================================================! -----------


          The address of returned buffer is the address at which  the  monitor
     has  placed  your  data.  This address is one of the addresses previously
     specifed by a .SSQRM call.   If  no  .SSQRM  call  was  done,  then  this
     function code will fail with an illegal instruction trap.  If the address
     is not writable you will also get an illegal instruction trap.
          The flag definitions may be found in the section on SC.SDG.
          The length of the returned  packet  is  in  bytes  for  an  industry
     compatible mode message, and words for a high density mode packet.  It is
     always the length of the packet  text,  and  does  not  include  the  SCA
     headers.


                              - Error codes -
     SCSNEP,SCSBTS,SCSIID,SCSQIE,SCSNUB
   SCA Functional specification                                   Page 94
   Writing a JSYS SYSAP


     6.2.17.2  Receive a datagram (.SSRDG)

                        Receive a datagram (.SSRDG)



     This function code returns datagram text for either the calling  fork  or
     the  specified connection.  If the connect ID field in the argument block
     is minus one, then the first datagram  found  for  the  calling  fork  is
     returned.   If the connect ID is anything but minus one (-1), the monitor
     will use this as a connect ID and return the  first  datagram  found  for
     that connection.  This is the argument block for this function code:


             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------! -----------
      .SQCID !                  Connect ID or -1                     !      ^
             !-------------------------------------------------------!      !
      .SQARB !              Address of returned buffer               !      !
             !-------------------------------------------------------! Returned data
      .SQDFL !          Flags           !      Node # of remote      !      !
             !-------------------------------------------------------!      !
      .SQLRP !              Length of returned packet                !      v
             !=======================================================! -----------


     The address of returned data is one of  the  addresses  provided  to  the
     monitor on a .SSQRD call.  If no .SSQRD was done or if the address is not
     writable, the JSYS will fail with an illegal instruction trap.  If  there
     are no datagrams available, an illegal instruction is generated.
          The flags are returned by the monitor and  currently  only  indicate
     the data packing mode.
          The length of the returned packet is in words  if  this  is  a  high
     density datagram, and bytes if an industry compatible datagram.


                              - Error codes -
     SCSNEP,SCSBTS,SCSIID,SCSQIE,SCSNDQ,SCSNBA
   SCA Functional specification                                   Page 95
   Writing a JSYS SYSAP


     6.2.17.3  Get entry from data queue (.SSGDE)

                     Get entry from data queue (.SSGDE)



          This function code returns the first entry  from  the  data  request
     complete queue.  The argument block follows:

              !=======================================================!
      .SQLEN  !      Words processed      !      Length of block      !
              !-------------------------------------------------------!
      .SQCID  !                    Connect ID or -1                   !
              !-------------------------------------------------------!
      .SQBID  !          Name of buffer whos transfer completed       !
              !=======================================================!

          The buffer name indicates which transfer has completed.


                              - Error codes -
     SCSNEP,SCSIID,SCSBTS,SCSIAB
   SCA Functional specification                                   Page 96
   Writing a JSYS SYSAP


     6.2.17.4  Get an entry off the event queue (.SSEVT)

                 Get an entry off the event queue (.SSEVT)



          This function code retrieves the first entry off  the  event  queue.
     This  queue  is  a  record of events that the JSYS user is to be notified
     about.  The user receives an interrupt on the first  event.   After  this
     events  will  be added to the end of the queue with no further interrupts
     generated.  It is the responsibility of the user to empty this queue upon
     receiving an event interrupt.

          If a  connect  ID  is  specified,  then  the  next  event  for  that
     connection  will  be  returned.  If however the connect ID field is minus
     one, then the next event for the fork is returned.

              !=======================================================!
      .SQLEN  !      Words processed      !      Length of block      !
              !-------------------------------------------------------! -----------
      .SQCID  !                  Connect ID or -1                     !      ^
              !-------------------------------------------------------!      !
      .SQESB  !         Reserved          !      Node # of remote     !      !
              !-------------------------------------------------------!   Returned
      .SQEVT  !                 Returned event code                   !     data
              !-------------------------------------------------------!      !
      .SQDTA  \                                                       \      !
              \                 Returned event data                   \      !
              \                                                       \      v
              !=======================================================! -----------

          The event code describes what event has  occured.   It  is  a  small
     integer  ranging  from  zero  to a maximum value.  Hence it can easily be
     used as an index into an event dispatch table.  The connect ID tells  you
     what  connection this event is relevant to.  The event data is a block of
     data returned for each event type.

          The general format of the event code descriptions is as follows:
     .SExxx -- Text

     The .SExxx is the event code and text desribes the code

     .SQDTA -- Text
     This second line describes the format of the data provided for this event
     code, starting at word .SQDTA of the argument block.


     .SEVCC -- Virtual circuit closure
     .SQDTA -- Contains the pertinant node number

     .SECTL -- Connect to listen
     .SQDTA -- Four words of initial connection data from the remote.

     .SECRA -- Connection was accepted
   SCA Functional specification                                   Page 97
   Writing a JSYS SYSAP


     .SQDTA -- Four words of initial connection data from the remote.

     .SECRR -- Connection was rejected
     .SQDTA -- The reason code

     .SEMSC -- Message/datagram send complete
     .SQDTA -- address of sent buffer

     .SELCL -- Little credit left
     .SQDTA -- number of credits required to get you back over threshold

     .SENWO -- Node went offline
     .SQDTA -- Node number of system which went offline

     .SENCO -- Node came online
     .SQDTA -- Node number of system which came online

     .SEOSD -- OK to send data
     .SQDTA -- not used here

     .SERID -- Remote initiated disconnect
     .SQDTA -- not used here

     .SEPBC -- Port broke connection
     .SQDTA -- not used here

     .SECIA -- Credit is available
     .SQDTA -- unsed here


     .SEMAX is defined to be equal to the largest event code possible.


                              - Error codes -
     SCSNEP,SCSIID,SCSBTS,SCSIAB
   SCA Functional specification                                   Page 98
   Writing a JSYS SYSAP


     6.2.18  Named buffer overview

                           Named buffer overview



          To send data to a remote system, the SYSAP must first declare memory
     to be part of a buffer.  A buffer is made of segments.  Each segment is a
     contiguous set of 36 bit words that DO NOT CROSS A PAGE BOUNDARY and  are
     not  more  than one page long.  Once the buffer has been established, the
     SYSAP must give the remote system the buffer name  obtained.   N.B.   SCA
     does not give the remote the buffer name, it is the responsibility of the
     SYSAP to transmit this information.
   SCA Functional specification                                   Page 99
   Writing a JSYS SYSAP


     6.2.19  Map a buffer (.SSMAP)

                           Map a buffer (.SSMAP)



          This function code associates a portion of memory with an SCA buffer
     name  to  be  used  in  named  buffer transfers.  This function takes the
     following arguments:

             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQXFL !                        Flags                          !
             !-------------------------------------------------------!
      .SQBNA !                 Returned buffer name                  ! (Returned)
             !-------------------------------------------------------!
             /                                                       /
             /           Buffer length and address pairs             /
             /                                                       /
             !=======================================================!

          The current set of flags are as follows:

     1.  SQ%DMD -- Named buffer  mode.   This  two  bit  field  indicates  the
         desired  setting  of  the  mode  bits  for the buffer.  The following
         settings are defined:
         SQ%DIC -- Industry compatable mode
         SQ%DCD -- Core dump
         SQ%DHD -- High density
         Any other value is illegal.



          Buffer length and address pairs have the following format:


             !=======================================================!
     .SQBLN  !               Length of memory block                  !
             !-------------------------------------------------------!
     .SQBAD  !         Address of memory for data transfer           !
             !=======================================================!

          The length word in this block has one of two possible  values  based
     on  the  setting  of  the  mode bits.  If the buffer mode is core dump or
     industry compatable the length is in 8 bit bytes.  If the  mode  is  high
     density, the length is in 36 bit words.
          The address for data transfer is the address where you  expect  data
     from a data transfer to be placed by the CI port microcode.

          The buffer name is the descriptor by which all other  references  to
     this memory is made.
   SCA Functional specification                                  Page 100
   Writing a JSYS SYSAP


                            *** Restrictions ***

     1.  No buffer segment may cross  a  page  boundary.   Hence  the  longest
         possible buffer segment is one page.



                              - Error codes -
     SCSNEP,SCSBTS,SCSNBA,SCSIAB
   SCA Functional specification                                  Page 101
   Writing a JSYS SYSAP


     6.2.20  Unmap a buffer (.SSUMP)

                          Unmap a buffer (.SSUMP)



          This function will remove from  the  monitor  data  base  (unmap)  a
     memory  block  assigned  for  named  buffer transfers.  It requires these
     arguments:

             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQNAM !                     Buffer name                       !
             !=======================================================!


                              - Error codes -
     SCSNEP,SCSBTS
   SCA Functional specification                                  Page 102
   Writing a JSYS SYSAP


     6.2.21  Send data (.SSSND)

                             Send data (.SSSND)



          This  function  transfers  data  to  a  remote  host.   It  is   the
     responsibility  of a higher level protocol to arrange the setup of buffer
     names.  The call requires the following arguments:

             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !       Connect ID for which transfer is to be done     !
             !-------------------------------------------------------!
      .SQSNM !               Buffer name of send buffer              !
             !-------------------------------------------------------!
      .SQRNM !              Buffer name of receive buffer            !
             !-------------------------------------------------------!
      .SQOFS !        Xmit offset       !       Receive offset       !
             !=======================================================!


                              - Error codes -
     SCSNEP,SCSBTS,SCSIID
   SCA Functional specification                                  Page 103
   Writing a JSYS SYSAP


     6.2.22  Request data (.SSREQ)

                           Request data (.SSREQ)



          This function tells SCA and the port  to  get  data  for  the  given
     buffer name.  The following arguments are required:

             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !       Connect ID for which transfer is to be done     !
             !-------------------------------------------------------!
      .SQSNM !              Buffer name of send buffer               !
             !-------------------------------------------------------!
      .SQRNM !             Buffer name of receive buffer             !
             !-------------------------------------------------------!
      .SQOFS !        Xmit offset       !       Receive offset       !
             !=======================================================!

          The "xmit offset" is the number  of  bytes/words  the  sending  port
     should  skip  before  sending  data.  This count is in bytes for industry
     compatable/core dump mode sends and words for high density sends
          The "receive offset" is the number of bytes/words that the  receiver
     should skip before writing data from the wire.  The count is in bytes for
     industry comapatable/core dump and words for high density mode.


                              - Error codes -
     SCSNEP,SCSIID,SCSBTS
   SCA Functional specification                                  Page 104
   Writing a JSYS SYSAP


     6.2.23  Maintainance data send (.SSMDS)

                      Maintainance data read (.SSMDS)



          This function requests a maintainance data send.  It works much  the
     way  named buffer transfers do in that the .SSMAP call must be done first
     to set up a buffer.  The buffer name returned by .SSMAP is used  in  this
     call.  Note that the remote must provide the buffer name it has allocated
     for sending the data as well.


             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQMSS !               Buffer name of send buffer              !
             !-------------------------------------------------------!
      .SQMSR !              Buffer name of receive buffer            !
             !-------------------------------------------------------!
      .SQMOF !        Xmit offset       !       Receive offset       !
             !-------------------------------------------------------!
      .SQMDT !          Unused          !     Target node number     !
             !=======================================================!



          The xmit offset and receive offset are identical to those  used  for
     named buffer transfers.
   SCA Functional specification                                  Page 105
   Writing a JSYS SYSAP


     6.2.24  Maintainace data read (.SSMDR)

                      Maintainance data read (.SSMDR)



          This function requests a maintainance data read.  It works much  the
     way  named buffer transfers do in that the .SSMAP call must be done first
     to set up a buffer.  The buffer name returned by .SSMAP is used  in  this
     call.  Note that the remote must provide the buffer name it has allocated
     for sending the data as well.

             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQMSS !               Buffer name of send buffer              !
             !-------------------------------------------------------!
      .SQMSR !              Buffer name of receive buffer            !
             !-------------------------------------------------------!
      .SQMOF !        Xmit offset       !       Receive offset       !
             !-------------------------------------------------------!
      .SQMDT !          Unused          !     Target node number     !
             !=======================================================!


          The xmit offset and receive offset are identical to those  used  for
     named buffer transfers.
   SCA Functional specification                                  Page 106
   Writing a JSYS SYSAP


|    6.2.25  Start a remote system (.SSSRS)
|  
|                      Start a remote system (.SSSRS)
|  
|  
|  
|         This function will start a remote node.   A  start  address  may  be
|    specified or the default can be used.
|  
|             !=======================================================!
|     .SQLEN  !      Words processed      !      Length of block      !
|             !-------------------------------------------------------!
|     .SQSTN  !              Node number of target node               !
|             !-------------------------------------------------------!
|     .SQSFL  !                         Flags                         !
|             !-------------------------------------------------------!
|     .SQAST  !          Address for starting remote system           !
|             !=======================================================!
|  
|    The currently defined flags are:
|  
|    1.  SQ%DSA -- Use the default start address.  If this  bit  is  lit,  the
|        default address is used to start the target node.  If the bit is off,
|        the the address specified in word .SQAST of the argument block.
|  
   SCA Functional specification                                  Page 107
   Writing a JSYS SYSAP


|    6.2.26  Reset a remote system (.SSRRS)
|  
|                      Reset a remote system (.SSRRS)
|  
|  
|  
|         This function resets a remote node.
|             !=======================================================!
|     .SQLEN  !      Words processed      !      Length of block      !
|             !-------------------------------------------------------!
|     .SQNTN  !              Node number of target node               !
|             !-------------------------------------------------------!
|     .SQRFL  !                         Flags                         !
|             !=======================================================!
|  
|    The currently defined flags are:
|        SQ%FRB -- Force reset.  If this bit is not set,  the  reset  is  only
|        done  if  the  local  host  was  the last host to send a reset to the
|        target node.  If the bit is on, the reset is done no matter who  last
|        reset the target node.
|  
   SCA Functional specification                                  Page 108
   Writing a JSYS SYSAP


     6.2.27  Set port counters (.SSSPC)

                         Set port counters (.SSSPC)



     This function  sets  the  port's  performance  counters.   The  following
     arguments are required:


|             !=======================================================!
|     .SQLEN  ! Number of words processed !      Length of block      !
|             !-------------------------------------------------------!
|     .SQNOD  !                      Node number                      !
|             !-------------------------------------------------------!
|     .SQPCW  !               Port counter control word               !
|             !-------------------------------------------------------!
|     .SQCPC  !   Number of times the counters have been set/cleared  ! (Returned)
|             !=======================================================!
|  
|     Node number:  Node number or 377 for all nodes
|  
|     Port counter control word, bits as follows:
|  
|                       B0   If on, count ACKs received on Path A.
|                       B1   If on, clear the counter.
|                       B2   If on, count NAKs received on Path A.
|                       B3   If on, clear the counter.
|                       B4   If on, count NO_RSPs received on Path A.
|                       B5   If on, clear the counter.
|                       B6   If on, count ACKs received on Path B.
|                       B7   If on, clear the counter.
|                       B8   If on, count NAKs received on Path B.
|                       B9   If on, clear the counter.
|                       B10  If on, count NO_RSPs received on Path B.
|                       B11  If on, clear the counter.
|                       B12  The count of discarded datagrams because
|                            of no DGFree Queue entries.
|                       B13  If on, clear the counter.
|                       B14  Count  the  packets  transmitted to  the
|                            designated port.
|                       B15  If on, clear the counter.
|                       B16  Count  the  packets  received  from  the
|                            designated port.
|                       B17  If on, clear the counter.
|  
|         The count of times the counters have been set/cleared  reflects  the
|    number  of  SCS% JSYS that have been done to set/clear the port counters,
|    not including the current one.  I.E.   the  call  just  executed  is  not
|    included in the returned count.
   SCA Functional specification                                  Page 109
   Writing a JSYS SYSAP


|    6.2.28  Read port counters (.SSRPC)
|  
|                        Read port counter (.SSRPC)
|  
|  
|  
|         This function  reads  the  maintenance  counters  out  of  the  port
|    hardware.  The following argument block is used:
|  
|  
|            !=======================================================!
|     .SQLEN !      Processed words     !       Length of block      !
|            !-------------------------------------------------------!  -----------
|     .SQMCV !                  Microcode version                    !       ^
|            !-------------------------------------------------------!       !
|     .SQPAA !                   Path A ACK count                    !       !
|            !-------------------------------------------------------!       !
|     .SQPAN !                   Path A NAK count                    !       !
|            !-------------------------------------------------------!       !
|     .SQPAR !               Path A no response count                !       !
|            !-------------------------------------------------------!       !
|     .SQPBA !                   Path B ACK count                    !       !
|            !-------------------------------------------------------!    Returned
|     .SQPBN !                   Path B NAK count                    !      data  
|            !-------------------------------------------------------!       !
|     .SQPBR !               Path B no response count                !       !
|            !-------------------------------------------------------!       !
|     .SQNDD !              Number of dropped datagrams              !       !
|            !-------------------------------------------------------!       !
|     .SQNPT !             Number of packets transmitted             !       !
|            !-------------------------------------------------------!       !
|     .SQNPR !              Number of packets received               !       !
|            !-------------------------------------------------------!       !
|     .SQPOR !                    Designated port                    !       !
|            !-------------------------------------------------------!       !
|     .SQNCC !      Number of times counters have been set/cleared   !       v
|            !=======================================================!  -----------


          Only the function code is passed to the monitor.  The rest  of  this
     block is information returned by the monitor.


                              - Error codes -
     SCSNEP,SCSBTS,SCSNBA
   SCA Functional specification                                  Page 110
   Writing a JSYS SYSAP


     6.2.29  Add interrupt channels (.SSAIC)

                      Add interrupt channels (.SSAIC)



          All notifications from SCA  happen  on  five  PSI  channels.   These
     channels  are  set  for:   datagram  available,  message available, named
     buffer transfer complete, events, and configuration change.   The  events
     are  detailed  in  the  section  on  the  .SSEVT  funtion code.  The only
     function performed by the .SSAIC code, is to inform SCA of which channels
     you  wish to use for the variuos interrupts.  It does not activate any of
     the channels, enable the PSI system, or set LEVTAB and CHNTAB for you.
          The argument block used to associate events with  PSI  channels  has
     this format:

             !=======================================================!
      .SQLEN !      Words processed      !      Length of block      !
             !-------------------------------------------------------!
             \                                                       \
             \          Up to four channel descriptor words          \
             \                                                       \
             !=======================================================!

     Where channel descriptor words have the following format:

             !=======================================================!
             !    Interrupt type code    !   Channel for this code   !
             !=======================================================!

     The interrupt type code is a small integer that indicates an event  type.
     The  channel number field allows you to enable and disable interrupts for
     the given event type.  If the channel number is -1  then  interrupts  are
     disabled.   If  it  is an integer between zero and thirty five, then that
     channel will interrupt on the given event  type.   The  next  box  is  an
     example of what the maximum size block would look like.

             !=======================================================!
      .SQLEN !      Words processed      !      Length of block      !
             !-------------------------------------------------------!
             !          .SIDGA           !      Channel number       !
             !-------------------------------------------------------!
             !          .SIMSA           !      Channel number       !
             !-------------------------------------------------------!
             !          .SIDMA           !             -1            !
             !-------------------------------------------------------!
             !          .SIPAN           !      Channel number       !
             !-------------------------------------------------------!
             !          .SICFG           !      Channel number       !
             !=======================================================!

     In this example interrupts for message available, datagram available, and
     all  other events are being enabled.  Interrupts on DMA transfer complete
     are being disabled.  Note that only the first word  of  this  block  need
   SCA Functional specification                                  Page 111
   Writing a JSYS SYSAP


     appear  in this position.  The channel descriptor words may appear in any
     order.  There must be at least one but  not  more  than  four  descriptor
     words in a block.

     To set up the PSI system for use with SCA, the following JSYS's  must  be
     done:

     1.  SIR%/XSIR%

     2.  AIC%

     3.  EIR%

     4.  SCS% with the .SSAIC function code



                              - Error codes -
     SCSBTS,SCSNEP,SCSNSP



















                          Design specification for the
                       Systems Communications Architecture

                                    21-Sep-83
   SCA Design specification                                             Page 1
   Introduction


   1.0  Introduction

   1.1  Scope

        This document is intended as a guide to SCAMPI and SCSJSY, the TOPS-20
   implementation  of  the  Systems Communications Architecture protocol.  Any
   non-obvious code or algorithm used in either the monitor SYSAP support code
   or  JSYS support code is described here.  It is a non-goal to describe each
   routine in detail.  The intent is to provide a map of major highways, not a
   street map.
        The document is broken into two parts, one  for  SCAMPI  and  one  for
   SCSJSY.   Each  could  easily  be  a  stand alone document but are included
   together here for consistency with other SCA documents and convenience.



   1.2  Related documents

   The reader should at least be familiar with the following documents  before
   proceeding with this specification.  The corporate SCA spec is particularly
   important as all terminology used in this document follows standards set in
   the corporate spec.

        1.  SCA Functional Specification, 19-September-83 (CDunn)

        2.  Systems Communications Architecture, 20-July-82 (Strecker)

        3.  LCG CI Port Architecture Specification, 11-July-83 (Dossa/Keenan)

        4.  TOPS-20 Coding Standard, 23-Mar-83 (Murphy)
   SCA Design specification                                             Page 2
   SCAMPI (Monitor SYSAP support)


   2.0  SCAMPI (Monitor SYSAP support)

   2.1  Major data structures

   2.1.1  System block

        The system block is the set of per system data for each  remote  known
   to  the  monitor.   The  set  of  system  blocks  for the local host can be
   accessed through the system block list (SBLIST).  This is the  sparse  list
   of all system block addresses.  Each entry is accessed by indexing into the
   list by node number.  This will yield the address of the system  block  for
   that  node  number.   In addition to SBLIST each system block has a forward
   link to the next block.
        There is a special index into SBLIST.  When -1  is  given  as  a  node
   number  on  a  listen call, the SYSAP is indicating that any remote node is
   acceptable.  Hence -1 is only meaningful when doing a listen call.
        System block data includes the work queue, the  connect  block  queue,
   and  the work queue for this remote.  The system block is mainly maintained
   by the port driver but there are cells maintained by SCA.  These cells  are
   described in [1].



   2.1.2  Connect Block

        The connect block is the  per  connection  database  and  is  entirely
   maintained  by  SCA.   All connect blocks are linked onto two doubly linked
   queues.  One of these lists is the set  of  connections  for  a  particular
   system  block.   The  other  list  is  the  set  of  connections owned by a
   particular fork.  This list and its uses are described in the  second  half
   of  this  document  in  the  section on SCSJSY.  Further description of the
   cells in this block may be found in [1].



   2.1.3  Remote system work queue

        These queues (one per known remote) are used for the stacking  of  SCA
   overhead   messages  to  remotes.   Since  the  protocol  allows  only  one
   outstanding overhead message at any time  for  each  remote,  the  overhead
   messages  which  SCA desires to send while there is one already outstanding
   are placed on this queue.  When the response  to  the  outstanding  message
   comes  in,  the next message on this queue is sent.  Note that the head and
   tail pointers for these queues are stored in  the  system  block  for  each
   node.



   2.2  Overview

        SCAMPI can be broken down into a number of major areas, routines  that
   process   requests  from  SYSAPs,  interrupt  handlers,  periodic  function
   handlers, buffer management routines, and general support routines.
   SCA Design specification                                             Page 3
   SCAMPI (Monitor SYSAP support)


   2.2.1  SYSAP request handlers

        The request handlers are the most simple and straight forward part  of
   SCAMPI.   These  routines  are  most easily understood by reading the code,
   rather than a verbal description here.  There are however some rules  which
   are followed in this set of routines.
        The more important rule is that interrupt level  may  come  along  and
   change connection data out from under the nose of a request handler.  Hence
   an interlock scheme must be arranged for places that cannot tolerate such a
   change.   For  all data except the connect state, the CION/CIOFF macros may
   be used to interlock connection data for periods  of  a  few  instructions.
   Since  the  connection  state needs to be interlocked for very long periods
   (perhaps up to a  millisecond)  another  interlock  scheme  is  used.   The
   SCON/SCOFF  macros  are  used to interlock the connect state.  These macros
   call the routines SC.SOF and SC.SON in SCAMPI which  will  do  nesting  and
   interlock  checking much like that done by CION/CIOFF.  See the sections on
   SC.SON and SC.SOF for more details on these routines.
        There is one other interlock scheme used for single instructions  that
   wish  to  increment  fields  in  the connect block.  In particular when SCA
   wishes to update the credit fields in the connect block, an  ADDM  AC,CBLOC
   is done where AC contains the number of additional credits (or negative for
   returning credit) and CBLOC is the address of the full word credit field in
   the  connect  block.   Since we can be guaranteed that the instruction will
   complete once started we can be sure  that  the  instruction  need  not  be
   interlocked with CION/CIOFF.
        The second rule is that  the  SYSAP  is  trustworthy.   Hence  minimal
   checks  are  done  for SYSAP argument validity.  Only data items over which
   the SYSAP has no direct access (E.G.  connection state) are checked.



   2.2.2  Interrupt handlers

        There are a number of entry points in SCA for the port driver to  call
   at  interrupt  level.   Each  of these entry points makes a few assumptions
   about what has happened and what it can do.
        A common assumption made by all interrupt handling  routines  is  that
   they may change certain data items in the connect block.  In particular the
   the receive credit level may be changed at interrupt level.  The connection
   state on the other hand is a special case.  The problem is that we may very
   well be interrupting a  piece  of  code  that  checked  the  state  of  the
   connection,  saw  that  it  was  open,  and  is  about  to send messages or
   datagrams based on this check.  The connection must  not  be  closed  until
   after  this packet send is complete.  Hence there is an interlock mechanism
   for the connection state.  The SCOFF/SCON macros turn off/on the ability to
   change  the connect state.  When the SCON is done by the sensitive routine,
   a support routine is called to check a connection specific queue for change
   of state request blocks.  A part of this block is the address of a chain of
   packets that needs to be sent along with the change of state.
        A specific case is the sending of a disconnect request.  When a remote
   sends  the  local host a disconnect request, the interrupt handler for this
   message type checks the interlock for the connect block state.   If  it  is
   unlocked  it  proceeds  to send the rest of the handshake.  If it is locked
   however, it puts an entry onto the connection's  block  state  queue  along
   SCA Design specification                                             Page 4
   SCAMPI (Monitor SYSAP support)


   with  the  address  of  the  chain  of  messages to send, (in this case the
   disconnect response followed by the disconnect request) and returns.   When
   the  routine which locked the connection state releases the lock, the queue
   is checked for change of state entries.  From the remotes point of view, an
   application  packet  will  be  received for a connection which has sent the
   first part of the disconnect handshake.  Hence it  must  drop  this  packet
   without closing the VC.



   2.2.2.1  SC.ONL

        At this  entry  point  SCA  assumes  that  a  new  VC  has  just  been
   established.   It may be a reopening of an old VC or the first circuit to a
   new node.  In either case we have the  node  number  of  the  system  newly
   arrived  and  we  may  go  ahead  and  perform  SYSAP notifications.  These
   notifications are different from all others in that it  happens  on  a  per
   SYSAP  basis  rather  than  a per connection basis.  There was no reason to
   notify the same SYSAPs once for each connection it owns about a  new  node.
   Hence  the SYSAP notifies SCA of an address to call when this event occurs.
   Typically  this  address  is  the  same  address  given   for   all   other
   notifications,  but  that is a decision for the SYSAP designer.  Each SYSAP
   notified requires the event code for new circuit and the node number of the
   newly aquired node.



   2.2.2.2  SC.ERR

        This is the entry point for circuit closure.  If a circuit  is  closed
   for any reason, SCA expects the port driver to call this entry point.  This
   includes the case of SCA requesting a circuit closure.  It should be  noted
   here  that  SCA  must  request  the  opening of a circuit after it has been
   closed.  This is accomplished through the use  of  the  SCOFF/SCON  macros.
   Upon  receiving  notification  of  circuit closure, SCA must close all open
   connections on that circuit.  It cannot change the state  of  a  connection
   which  has  the connect state interlocked however.  A circuit wide count of
   interlocked circuit states is maintained.  When a SCON macro is  performed,
   the  count has reached zero and the flag for "VC requires open call" is set
   in the system block, then we may call the port driver to open  the  circuit
   again.   While  SCA is here, we must notify all SYSAPs that the circuit has
   gone away.  This implies that the SYSAP must be able to deal with a circuit
   going away during an SCA call.



   2.2.2.3  SC.OFL

        This entry point is identical to SC.ERR except the code used on  SYSAP
   notification is for node offline rather than circuit closed on error.
   SCA Design specification                                             Page 5
   SCAMPI (Monitor SYSAP support)


   2.2.2.4  SC.DMA

        This entry point is called when a named buffer transfer has completed.
   All  that needs to be done here is notify the connection that requested the
   transfer.



   2.2.2.5  SC.INT

        This is the major interrupt level entry point for  SCA.   It  is  from
   this  point  that  SCA handles all incoming application and SCA packets.  A
   dispatch to the correct routine is done based  on  the  SCA  message  type.
   Other  than  the  general  interrupt level cautions outlined above, nothing
   very special is done here.
   SCA Design specification                                             Page 6
   SCAMPI (Monitor SYSAP support)


   2.3  Periodic function handlers

        Within SCA there are a few functions that are handled on  a  per  time
   basis.   At  present  these  functions  are idle chatter, the management of
   buffer allocation levels, and the deletion of  connection  data.   All  SCA
   time driven activity happens during the one hundred millisecond clock cycle
   of the scheduler.  Hence there  is  a  clock  counter  and  instruction  to
   execute  in STG for the SCA clock.  The instruction is a PUSHJ into SC.CLK.
   This routine then does simple checks to see if  it  is  time  for  any  SCA
   events  to happen, and dispatches to the correct handling routines when the
   events are due.



   2.3.1  Idle chatter

        Idle  chatter  is  defined  as  the  polling  of  remote  nodes   with
   connections   open  to  them.   This  is  done  since  most  port  hardware
   implementations can answer a  request  ID  without  software  intervention.
   Hence the port driver poller will not declare a node offline until it stops
   answering request IDs on both paths.   Since  the  port  can  stay  up  for
   extremely  long  periods afer the software has crashed, detection of remote
   software failure could potentially take a very long time.  Hence  SCA  will
   send  a credit request for zero credit to any remote which has a connection
   open to it.  These credit requests are only sent if the node has  not  sent
   us  a  packet  for  over  five  seconds.   If a credit request is sent, the
   response turn around  is  timed.   If  the  response  arrives  within  five
   seconds,  the node is online and SCA does nothing except turn off the timed
   message flag in the system block.  If the response has  not  arrived  after
   five seconds, the node is declared down and circuit closure is requested.



   2.3.2  Buffer allocation level management

        Buffer levels are handled with a twofold process.  First, a  threshold
   level  is  maintained,  below  which  SYSAPs  may  request  buffers without
   waiting.   If  a  SYSAP  directly  calls  a   buffer   allocation   routine
   (SC.ABF/SC.ALD)  with  a request for more than what is on hand, the failure
   return is taken and no further action is taken by SCA.  In  general  it  is
   assumed  that  for cases other than connection startup and packet reception
   buffers SYSAPs will only make  small  buffer  requests  (between  1  and  3
   buffers).   These  requests  will  generally  present  no  problem,  as the
   threshold level should be well above this.
        Second, if a connect  request,  listen  request,  accept  request,  or
   receive  buffer  request is made with a large numbers of buffers specified,
   SCA will try to fill the request immediately.  If this request would put us
   under  threshold,  then the request is defered until job 0 can allocate the
   buffers.  All of this is transparent to the SYSAP  however.   The  returned
   information (if any) is the same whether the buffers were available or not.
   If the buffers were not available, then whatever the SYSAP  requested  will
   take  longer  to  finish.   Since no SYSAP should time these requests, this
   does not present a problem.
        Internally, SCA notices that the request for buffers will put us under
   SCA Design specification                                             Page 7
   SCAMPI (Monitor SYSAP support)


   threshold  and  hence  this  request  must  be  defered.  Hence the connect
   request message is placed on a queue, hung off the system block.  Note that
   at  this  point  the  connect  request has been completely assembled and is
   ready for transmission.  In addition to the normal connect request data,  a
   short  block  of  data  used  for  creating  the  required buffers has been
   appended to the connect request.  After the entry  has  been  made  to  the
   queue,  job  zero is poked to run and check for this type of request.  Once
   job zero has created the required buffers, it will either  call  SC.SCA  to
   send  a  request,  or will simply return the buffer to the SCA free pool if
   this is a buffer queue request.
        The following is the format of the data block  used  to  describe  the
   allocation of additional buffers:

            !=======================================================!
            \                                                       \
            \        Space for largest SCA overhead message         \
            \                                                       \
            !-------------------------------------------------------!
   .BZNUM   !   # of message buffers    !   # of datagram buffers   !
            !=======================================================!

   .BZNUM
   This word defines the number of buffers to be allocated.


        Note that if there are message  buffers  being  created,  the  message
   being  sent  here  is a credit request.  Hence the count of message buffers
   plus the current pending receive credit must be placed in the credit  field
   of  the  packet.   If  there are datagram buffers being added here then the
   count of datagram buffers in the connect block must be updated  to  include
   these new buffers.



   2.3.3  Connection data deletion (SC.RAP)

        This periodic function is responsible  for  the  return  of  resources
   associated  with  aborted  or disconnected connections.  Once the abort bit
   has been set by some other part of SCA, the next pass of this function will
   light the reap bit.  On the following cycle, SC.RAP will check the count of
   packets outstanding on the KLIPA command queue and delete the connect block
   if the count is zero.  It should be noted that this count of packets on the
   queue only accounts for packets that the software gets  back.   I.E.   only
   those  packets  which  do  not end up on a free queue are counted.  Packets
   which end up on a free queue are not seen by the software  after  the  send
   has  completed  and  hence cannot be counted.  There is a substantial delay
   however (minimum of 15 seconds) between the abort of the connection and the
   deletion  of the data.  This should allow enough time for those packets not
   counted to make it off the KLIPA command queue.
   SCA Design specification                                             Page 8
   SCAMPI (Monitor SYSAP support)


   2.4  Buffer management routines

        These routines handle the allocation  and  return  of  SCA  free  pool
   buffers.   The  SCA  free  pool  is  a  singly  linked  list of the buffers
   available.  There are two  such  pools,  one  for  datagrams  and  one  for
   messages.  The return of buffers to these pools is a simple operation where
   the buffer is placed at the end of the  list  and  the  buffer  pool  count
   incremented  as  necessary.   The  allocation of these buffer is a bit more
   complex however.
        When SCA is called upon to allocate a number of buffers (N)  from  one
   of  the  free  pools,  there  are  a number of checks that need to be done.
   First, if there are not enough buffers to fill the request  (as  determined
   from  the  buffer  count)  the  request is rejected outright.  If there are
   enough buffers but the number of buffers remaining in the pool is less than
   a  threshold value, then the request is granted and flags are lit for job 0
   to add more buffers to the free pool.  The number of buffers added is based
   on  the  number of nodes seen the in network plus a few additional buffers.
   If during the process of allocating the buffers, it is determined that  the
   buffer  count is wrong and there are in fact not enough buffers to fill the
   request, the partial allocation is  returned  to  the  free  pool  and  the
   request  is  rejected.   After  this process the free pool count is correct
   since the allocation kept track of how many buffers  were  in  the  partial
   allocation.



   2.5  General support routines

        These routine perform the common functions required  to  support  SCA.
   In  general  these are very simple routines that need no explanation.  Only
   those which make assumptions that  are  not  obvious,  or  those  that  use
   non-obvious algorithms shall be called out.



   2.5.1  Connection data deletion

        When an open connection has been disconnected or  any  connection  has
   been  aborted, the database for that connect must be deleted.  This is done
   by a number of routines whos' function may not be completely  obvious.   In
   general  the  idea  is  to wait for all outbound traffic to complete before
   deleting connection data.  This can be done since the handling  of  inbound
   packets  is  identical whether the data is around or not.  Outgoing traffic
   is easily handled since there is a count of  outstanding  messages  on  the
   port  queues  in  the  connect  block.   When  this  count goes to zero all
   outgoing traffic has completed.  We are guaranteed that there  will  be  no
   further  traffic  since SCA will not try to send packets on a connection in
   any state but open.  Once this count has gone to  zero,  the  data  may  be
   deleted.
        To insure that the KLIPA has had time to complete transmission of  any
   packets outstanding for this connect, SCA waits a while before checking the
   counts.  The periodic function to check reap and abort bits will then clean
   up  the  connect  data  and all resources associated with the connect.  For
   more detail on this process, see the section on periodic functions.
   SCA Design specification                                             Page 9
   SCAMPI (Monitor SYSAP support)


   2.5.2  SC.SON/SC.SOF

        These routines interlock the connect state of each connection.   There
   is  an  interlock  word  in  the  connection block that when positive is an
   indication that the lock is locked and someone wishes  to  lock  it.   When
   zero  the  lock is locked but there are no other requests to lock it.  When
   -1 the lock is available.  When interrupt level  discovers  that  it  would
   like  to  change the state of the connection but the lock is not available,
   an entry is made to a system wide queue, indicating the  new  state  and  a
   chain  of packets that need to be sent as a result of this new state.  When
   the unlock is done this queue is checked for entries for  this  connection.
   If entries are found they are processed immediately.



   2.5.3  SC.PON/SC.POF

        These two routines are responsible for the turning off and  on  of  CI
   interrupts.   This  is  accomplished  through  the turning off/on of the PI
   channel for the KLIPA.   The  following  algorithm  is  used  to  determine
   whether the channel state should be changed.
   SCA Design specification                                            Page 10
   SCAMPI (Monitor SYSAP support)


                                   - SC.POF -

























                                     Fig. 1
   SCA Design specification                                            Page 11
   SCAMPI (Monitor SYSAP support)


                                   - SC.PON -

























                                     Fig. 2
   SCA Design specification                                            Page 12
   SCSJSY (User mode SYSAP support)


   3.0  SCSJSY (User mode SYSAP support)

   3.1  Overview

        SCSJSY provides a user interface to the CI through SCA.  To do this it
   does  nothing  more  than  translate  user  requests into SCA SYSAP request
   handler calls and turns SCA callbacks into a PSI for a fork.  A major  part
   of  this  job is the careful checking of user arguments.  Since SCA assumes
   that SYSAPs are trustworthy, a bad argument to an  SCA  call  can  cause  a
   system crash or CI failure fatal to a circuit.  Hence SCSJSY must take care
   to insure the integrity of user arguments.
        In  general,  SCSJSY  handles  two  types  of  traffic,  inbound,  and
   outbound.   Inbound  traffic is placed on fork and connection lists and the
   owning fork gets a PSI if the list was empty before  this  packet  arrived.
   Outbound  traffic  is placed on KLIPA command queues through the use of SCA
   calls and blocks until the confirmation of send complete comes up from SCA.
   This  blocking  is  necessitated  by  the  way packet transmission is done.
   Details of this process can be found in the section on  JSYS  level  packet
   transmission.
        The structure of SCSJSY can be broken up into two parts, a  part  that
   handles  service  requests  from  the  user,  and  a  part  to  handle user
   notification of interrupt events.



   3.2  Major data structures

   3.2.1  Connect blocks

        In addition to the data for monitor SYSAP support, the  connect  block
   contains  a  number  of  cells  for JSYS SYSAP support.  These include user
   buffer counts and list head/tail pointers for various per connection lists.
   In  general  these lists are all doublely linked, and each piece of data is
   on two of the lists.  In particular each piece of data is on  a  fork  list
   and  on  a  connection list.  This enables JSYS SYSAPs to request data on a
   fork wide basis or  a  per  connect  basis.   This  is  greatly  simplifies
   management of multiple connections.  It also means that when data items are
   added or removed from its lists, they will very likely be pulled  from  the
   front  of  one  list and the middle of the other.  All support code must be
   prepared to deal with this case.
        A side effect of having data available on a fork wide  basis  is  that
   the  head/tail  pointers  for  the  lists  appear in the PSB.  As a result,
   various places in the code will want to modify the PSB of another fork,  or
   in  the case of interrupt level, modify non-resident memory.  To solve this
   problem a system wide list was created to store data  items  until  process
   level could be summoned to modify non-resident memory.  The details of this
   process can be found in the section on interrupt level processing.
        Connect blocks do not present this kind  of  problem  since  they  are
   always  resident.   They  do  however  appear  on a chain of connect blocks
   available to the fork.  Hence when the first or last connect block  on  the
   list  is  deleted, the PSB of the owning fork will be modified.  Hence this
   process also happens in process context.  The  details  of  the  connection
   block  deletion  process  can  be  found  in  the  section on monitor SYSAP
   support.
   SCA Design specification                                            Page 13
   SCSJSY (User mode SYSAP support)


   3.2.2  SCA data section

        To ease the allocation of memory, SCA has a  virtual  section  all  to
   itself.  This section has two uses, a place to allocate buffer space, and a
   place to map user packets for  transmission.   Buffer  space  is  allocated
   starting  at  the end of the section and grows down into memory a page at a
   time.  User packets being made ready for transmission are mapped  into  the
   begining  of  the  section.   This scheme allows the section to be used for
   both purposes and still have a dense set of pages for each.



   3.3  Service request handlers

        Unless otherwise noted,  service  request  handlers  check  arguments,
   translate  required arguments into format for passing to SCA, call SCA, and
   return.  If any data needs to be passed back to the user  program  that  is
   not  returned  by  the call to SCA, an event is generated and placed on the
   fork/connection event queue.



   3.3.1  Send a packet (SCSSMG/SCSSDG)

        A major consideration in sending packet data was the performance  loss
   caused   by   copying  data  from  user  space  to  monitor  space.   Hence
   SCSSMG/SCSSDG maps the packet into the low end of the SCA section.  This is
   the  why  the  set  of  restrictions  (detailed in [1]) is placed on packet
   sends.  Since the SCA header must be contiguous with the packet text, there
   must  be  room for the header between the page boundry and the start of the
   SYSAP text.  This is why the SYSAP specifies the base address  of  the  SCA
   header  and  not the base of the SYSAP text when talking about buffers.  It
   insures the SYSAP understands that room for the header must be available.



   3.3.2  Read port counters

        To read the port counters the port driver must place a  command  on  a
   KLIPA  command  queue  and  notify  SCA when the response comes back on the
   KLIPA response queue.  Hence the SCA call will not return directly with the
   requested information.  In this case however the JSYS call will block until
   the information has been  returned.   This  alleviates  the  need  for  yet
   another event type, and since this is not really an event but a request for
   information, it returns the data immediately just as the other  information
   calls  do.   It  just  has to wait a while to return the information.  Care
   must be taken however to not be NOINT wile doing this.  This will allow the
   user  to  get  out  of  a hung call to SCS%.  This implies that the routine
   which returns this information must be able to handle the connection  going
   away  when the data actually comes back.  It also means no resources can be
   owned when the dismiss is done.
   SCA Design specification                                            Page 14
   SCSJSY (User mode SYSAP support)


   3.4  Interrupt event handlers

        The operation of the interrupt handlers  is  actually  rather  simple.
   Each  mearly  records  a  small  amount of data into a block and places the
   block onto a system wide list.  It is the handling of this  list  which  is
   rather circuitous:

        1.  Interrupt level places  entry  on  system  wide  queue  and  zeros
            location  SCSTIM.   This location is the clock counter for a 100ms
            scheduler clock.  SCHED will notice that the count is zero and XCT
            a CALL SCSCLK on the next 100ms cycle.

        2.  Upon arrival at SCSCLK the entire system  wide  list  is  scanned.
            The  target  fork number is retrieved from each entry and a bit is
            lit in FKSTAT for this fork.

        3.  The main scheduler loop notices that FKPS1 is  on  in  FKSTAT  and
            will  end up at PIRQ.  PIRQ checks the SCS% bit in FKSTAT and will
            call SCSPSI if the bit is on.  Once we arrived at PIRQ we  are  in
            process  context  for  the  target fork.  Hence we have the PSB we
            will modify locked in core.

        4.  SCSPSI will now scan the system wide queue for entries  bound  for
            the current fork.  The entries it finds are placed on the fork and
            connection queues of the target fork.  If the list in question was
            empty  before  the new entries were added, then a PSI is generated
            on the appropriate channel for the target fork.

        When a user receives a PSI, SCS% functions to retrieve data  are  done
   to  return  information  about  events  or  to  retrieve  data from packets
   received.
SCA-DESIGN-NOTES.TXT

SCAMPI will be changed to conform to the corporate spec as much as
possible. This includes updating the states and following the model of
the spec for sending SCS control messages. The current spec is version
6, and is available on R60SPC:.

See comments in the edit history of SCAMPI for specifics of edits already
made. See also SCA-TABLES.TXT for the tables that represent the state machine.

No attempt will be made in the near future to update the SCA design spec.
Any necessary changes to the functional spec will be reviewed with sysap
writers. No change will be visible to ordinary users.

The following areas must be investigated before the design can be done:

	1. Interlocks

	2. Buffer management

	3. Disconnection

	4. Deletion of connection blocks

	5. When can we safely open a v.c.?

	6. Inconsistencies in the corporate spec regarding states
			SCA Design Notes
			  Judy Hall
			  Dave Lomartire

This is a collection of notes about the changes that have been made to
SCAMPI. It is not intended to be a complete description of the changes,
nor is it in any way a tutorial description of the design. But it does
document the reasons behind some decisions, and may provide some insight
into the assumptions implicit in the code.
		Interactions in SCAMPI
			Judy Hall
			6/14/84

1. System block's list of connection blocks (pointed to by .SBFCB)

NOTE: We assume that the c.b. lock has prevented setting the "reap"
bit until no other code wants to use the c.b. The concern here is only
with keeping the list intact.

Adding - SC.LCB -- CIOFF

Removing -- SC.RCB -- CIOFF

Traversing -- SC.RAP knows it's the only deleter, and uses no
		protection when traversing
	   -- SC.SCM knows it's at interrupt level, uses no protection when
		traversing
	   -- SC.IDL goes NOSKED when traversing to prevent SC.RAP from
		running

Nothing totally eliminates the queue. It may become empty when the
last entry is removed.


2. Don't-care listeners (pointed to by TOPDC)

Adding -- SC.LCB -- CIOFF

Removing -- SC.RCB -- CIOFF
	 -- SC.SCM -- interrupt level

Traversing -- SC.RAP uses CIOFF. WHen it finds an entry to be reaped, it 
		goes CION. When it continues, it returns to the top of
		the list.


3. System block's work queue (pointed to by .SBTWQ)

Adding -- SC.AWQ (from SC.SCA, SC.SNM, SC.DEF) -- CIOFF, checks v.c. before
		returning entry. If closed, doesn't queue the entry
		since SC.ERR has destroyed the queue

Deleting -- SC.RWQ (from SC.SNM, SC.DEF) -- CIOFF

Traversing -- SC.SNM, SC.DEF -- always remove entry while CIOFF, return
		it while CIOFF

Destroying queue -- SC.ERR -- CIOFF when resetting the head and tail

At any time, SC.ERR may destroy the list. Others can't traverse it
CION, or add an entry without verifying that node is still online.
4. System block's address of outbound buffer (pointed to by .SBOBB)

Taking the buffer -- SC.SNM -- uses EXCH with zero; if result is non-zero,
		owns the buffer

Returning buffer to s.b. -- SC.SNM -- while CIOFF, makes sure v.c. is open.
		If open, stores address in s.b.; if closed, returns buffer
		to port queue
			 -- SC.SAR -- knows it's at interrupt level, stores
		address in s.b.

Returning buffer to port or SCA -- 

	SC.ERR -- uses EXCH with zero; if result is non-zero, returns
		 buffer to SCA's pool
	       -- if zero, gets a buffer from the port's queue.

	SC.RIB -- knows that v.c. is already closed,
		returns buffer to port

	SC.SNM -- if PHYKLP refuses to send, returns buffer to port

At any time, SC.ERR may return the buffer to SCA's pool. All code must
test and zero the address in one operation.


5. Connection block

Connection block lock protects against

	A. Reaping

		Makes c.b. address invalid
		Manages buffers according to counts in c.b.
		(Assume reaping can happen as soon as unlock and OKSKED)

	B. Protocol violation

		Disc_req / application message
		Disc_req / disc_req
		Disc_req / credit_req

		(Even if last is not a violation of protocol, we will have
		reaped the block by the time the response arrives. And there
		is no reason to change credit if we are disconnecting.)

	C. Change in connection state or block state

		Protocol is generally synchronous, but

		1. SC.DIS at odd times can be interrupted by incoming
			protocol message. Both change state.

		2. Sysap can do connection management request, interrupt out
			 of it, and do SC.DIS.

		3. Any connection management request can be interrupted by
			node offline.
Events that can't tolerate these changes --anything that believes the
c.b.a. is valid, sets the connection state, sets the block state, or sends
a packet, including

	Calls from the sysap, including
		Connection management requests
		Sending messages and datagrams
		Queueing or canceling buffers for reception
		Sending DMA
	Idle chatter
	Sending connection management requests

These all lock the connection block lock. In the case of sending a packet,
they unlock it only after the packet has been given to PHYKLP.

It is NOT necessary to leave a c.b. locked while it is waiting to send a
connection management request (that is, the buffer is in use). However,
it must be locked while its request is being sent and its state is being
changed.

Some code needs to honor the lock if it's at interrupt level, and lock the
lock if it's not. So there are three kinds of routines:

	A. Lock

		If at interrupt level, do nothing
		If not, AOS the count.

	B. Honor

		Called by code that runs only at interrupt level
		If lock is unlocked, proceed.
		If lock is locked, set a bit to indicate what is deferred,
			and don't proceed.

	C. Lock and honor

		If not at interrupt level, do "lock"
		If at interrupt level, do "honor"

When locking, code goes NOSKED. Therefore, there can be only one locker
at a time.

Events that defer:

	SC.ERR - node offline
	SC.DIS - sysap requests disconnect
	SC.DRQ - remote side initiates disconnect
	SC.SNM - sending a connection management request

Unlock routine processes according to the bits it finds set.
6. Existence of connection block

Only SC.RAP deletes a connection block. Code that sets the "reap"
bit must lock the connection block, which makes it NOSKED. The reaper
won't run until the block has been unlocked.


7. Virtual circuit's state (indicated by SBVCST)

	SC.ERR -- if no c.b. is locked, calls OPENVC
	       -- if a c.b. is locked, increments s.b.'s count of locked c.b.'s

	SC.ULK -- if node offline had been deferred, decrements s.b.'s count
			of locked c.b.'s. If result is zero, calls OPENVC


8. Send credit (indicated by .CBSCD)

Single-instruction AOS or SOS avoids races

Decrement and test -- SC.SMG, SC.SND, SC.REQ -- SOS and load AC

Increase -- SC.DMA increases by 1 -- AOS -- interrupt level
	 -- SC.CRQ and SC.AMG -- ADDM from packet -- interrupt level

Use -- SC.CRQ compares with minimum send credit -- interrupt level

Store initial value -- SC.ORQ and SC.ARQ -- interrupt level


9. Receive credit

CIOFF protects all changes; multiple kinds of credit must be adjusted
without interruption.

Use of return_credit prevents interaction between cancel receive message
and other events. Avoids cases in which the number of buffers queued
differs from receive credit.

Interlock word, .CBPND, prevents conflicts between two contexts that
want to send a credit_request. Prevents an attempt at queueing the c.b.
a second time, and avoids sending a null credit_request. When the
credit_response arrives, we send another credit_request if the need has
arisen since the last one was sent.

SC.CDT (from SC.RMG, SC.CRM, SC.IDL, SC.CRS) -- EXCH of .CBPND with -1.
		If result is 0, send credit_request. If not, return.

SC.CRS -- clear .CBPND and call SC.CDT to send again if necessary.
10. Count of buffers queued for receiving datagrams

Decrement -- SC.CRD -- SOSL once per buffer; AOS if negative

Change -- SC.RDG -- ADDM
       -- SC.ADG -- SOSGE; AOS and drop datagram if negative

Use -- SC.RCB dequeues based on this value; block isn't being used by then
			Why SC.DIS is Special
				6/21/84

SC.DIS uses CIOFF to lock out SC.DRQ, SC.ORQ, SC.ARQ, SC.ARS. If these
were allowed to run, they would have to honor the lock. SC.DRQ already does
honor it, but the other three do not.

The alternative to CIOFF is to make each of these honor the lock. The race
arises only when the sysap has done a disconnect at an unusual time, as
follows:

SC.ORQ - sysap disconnects a listener, and connect_request arrives. SC.DIS
sets new state to closed, but SC.ORQ has already set it to connect_received,
and sent a connect_rsp Match. Its deferred code would have to manufacture
a reject_request if the state had changed to closed. Today it sends
connect_rsp NM if the state is closed.

SC.ARQ - sysap disconnects after initiating a connection, and an accept_request
arrives. SC.DIS sets new state to closed, but SC.ARQ has already set it to
open, and sent an accept_response Match. Its deferred code would have to
manufacture a disconnect_request if the state had changed to closed. Today it
sends an accept_response NM if the state is closed.

SC.ARS - sysap disconnects after accepting a connection for a listener, and
an accept_response Match arrives. SC.DIS sets new state to closed, but SC.ARS
has already set it to open. Its deferred code would have to send a 
disconnect_req, which it does today if the state is closed.

It seems more practical to let SC.DIS be CIOFF until it is ready to send
a message (if that's necessary), and avoid a lot of special-purpose code.
It already needs to be CIOFF for a large fraction of the execution time
anyway. Also, the speed of disconnect doesn't seem terribly critical to the
overall performance of the system.

Since SC.DIS is CIOFF for this purpose, it need not lock the lock. SC.DRQ
and SC.ERR will be held off by CIOFF, so the lock is unnecessary.
		Why Reap in Process Context
			Judy Hall
			6/14/84

1. Allows the return of buffers that the sysap (CFS) has queued for output.
These will be returned at SC.INT, which assumes that the CID is still valid.
That is the only way to identify the sysap to which the buffer is to be
returned.

2. Code that sets the "reap" bit must still unlock the connection block before
the reaper can run. Locking goes NOSKED, which prevents reaping. If we were to
reap immediately, each pass through unlock would have to check for this case.

3. Reaping isn't very urgent, and shouldn't be done at interrupt level.
			Why Stock the Message Free Queue
				Judy Hall
				6/20/84

1. When a node goes offline, the outgoing connection management buffer may be in
use. If so, we try to get a buffer from the port's queue to give back
to SCAMPI. When PHYKLP queues the buffer to the port, the port will return
it with error. PHYKLP will return the buffer to the free queue. Thus there
is a window where the port will be short one buffer.

2. When a node goes offline, the incoming connection management buffer
may be on the response queue. SCAMPI will try to remove a buffer from the
port's queue at SC.ERR. Eventually the connection management buffer will
be given to SCAMPI, which will return it to the free queue. Meanwhile, there
is a window where the port will be short one buffer.

3. When a node goes offline, a sysap may have queued a buffer to go out,
without asking that the buffer be returned. In this case, the sysap's
receive credit includes this buffer. If the reaper runs before the port sees
the buffer, SC.RCB will try to remove a buffer from the port when it hasn't
been queued there yet. As soon as the port rejects the command, PHYKLP will
give the buffer back to the port.
			Incoming Packets on Closed V.C.
				Judy Hall
				6/22/84

An incoming packet may be on the response queue behind a packet that will
cause the v.c. to be closed. SCAMPI will receive a callback at SC.ERR
for the bad packet, followed by a callback at SC.INT for the good one.

SCAMPI used to process this second packet normally, even though the
v.c. was closed. This led to the following problem:

Suppose the second packet is a connect_request. SCAMPI matched the
request with a waiting listener and set the connection state to "connect
received". However, the attempt at sending a connect_response failed
because the v.c. was closed. The sysap was never notified of the change of
state. It believed it had an outstanding listener.

SCAMPI now checks the state of the v.c. for every incoming packet.
Because connect_request isn't associated with a particular connection,
it's not sufficient to check the connection state. Also, handling of
the buffer is different if we know that SC.ERR has already run.
This could be via a separate dispatch table at SC.INT, indexed by op
code and handling only the case of incoming packet on a closed v.c.
Presently, the check on the v.c. is made after the op code is known.

The buffer is handled as follows:

1. Connection management request 

This is the buffer that SCAMPI queued to the port when the node came
online. Normally, the response goes out in this buffer. If the node
is offline, SCAMPI queues the buffer to the port. SC.ERR has already
taken a  buffer from the port and returned it to its pool. THus this
buffer belongs to the port.

2. Connection management response

This is the buffer that is queued to the system block for outgoing
requests. When SC.ERR ran, the pointer was 0, and SCAMPI took a buffer
from the port's queue. Thus SCAMPI now returns this buffer to the port.

3. Application message

SCAMPI gives the buffer to the port. It was included in the sysap's
receive credit, so if the reaper has run, it has already removed an
extra buffer from the port's queue.

4. Application datagram

SCAMPI gives the buffer to the port. It was included in the sysap's
count of queued datagram buffers, so if the reaper has run, it has
already removed an extra buffer from the port's queue.
		The List of Connection Blocks
			Judy Hall
			6/20/84

It's not clear that linking the connection blocks to the system block
is essential. The list is useful for idle chatter, for the reaper,
and for finding the connections when a node goes offline.

Presently, a c.b. remains on the list until the reaper deletes it. This
means that searches through the list will stumble over this block. This
is most likely to be visible after a node goes offline. All its connection
blocks are marked to be reaped, and a whole new set of them is created,
but they are behind the obsolete ones.

One possibility seems to be to remove a c.b. from this list at SC.ERR,
or at SC.PTC, which is reached also when a disconnect sequence completes.
These blocks could be on a special "reap" linked list, which the reaper
would search instead of searching the list for each system block. Since
the reaper runs periodically, and typically searches these lists without
accomplishing anything, this would seem to offer a performance gain.

Other possibilities:

	Set a bit in CIDTAB to indicate that the connection block needs
reaping, and have the reaper scan CIDTAB.

	Set a global flag when the reap bit is set in any c.b., and don't
call the reaper unless this flag is set.
		Opening a V.C.
		   Judy Hall
		   6/20/84

SC.SNM may try to queue a packet after SC.ERR has run. Between getting the
buffer (.SBOBB) and sending, it doesn't check the v.c. We need to be sure
that 1) PHYKLP won't accept the packet if the v.c. is closed, and 2) the
v.c. doesn't get reopened before we queue the packet.

Sequence in PHYKLP should always be:

	1. Mark the state as closed
	2. Tell the port to close the v.c.
	3. Tell SCAMPI the v.c. is closed

SCAMPI should never allow the v.c. to be opened as long as any connection
block is locked. The locker may try to send a packet (SC.SNM, SC.SMG, etc.),
and we want that to fail.
	Closing and Opening V.C.'s (SCAMPI and PHYKLP)
		Judy Hall
		6/10/84

1. SCA makes the decision to close

	SCA calls PHYKLP, which
	  a. marks the state as "closed"
	  b. tells the port to close the v.c.
	  c. calls SC.ERR

2. PHYKLP makes the decision to close

	It follows the same sequence as in #1 above.

3. The port informs PHYKLP of an error

	PHYKLP either does all of #1 above, or leaves out telling the
		port to close the v.c.

If PHYKLP is unable to get a buffer for the SETCKT, it sets a bit in 
RIDSTS (or elsewhere) indicating that the v.c. still needs to be closed.
At this point, the system block has the state as closed, and SENDVC is
refusing to queue packets to the node.

The poller checks this bit, and sends the SETCKT whenever it can.
			- - - - -

SCA decides it can open a v.c. (PHYKLP never decides that if the v.c. has
ever been open before).

SCA calls PHYKLP, which sends a start unless the "need to close" bit is
still on. In that case, or if no buffer is available, it sets a bit in
RIDSTS called "need to open".

The poller always checks "need to close" before it checks "need to open".
When it wants to open, it sends a start.
			- - - - -

Neither routine returns failure. The purpose of SCA's "open" call is to
say "you can open whenever you want to". PHYKLP will notify SCA when the
v.c. has been opened, and SCA is not concerned with the events that prevent
this.

Similarly, when SCA says "close the v.c.", it means "don't queue any more
of my packets". So PHYKLP should mark its data base and act as if the v.c.
is closed, even if it hasn't found a way to tell the port yet.

Multiple attempts at closing, either by SCA or because of the arrival of
bad packets, should be filtered. SCAMPI checks for multiple calls to SC.ERR
for the same system block, but there seems to be no reason to perform
the close function more than once.

			- - - - -

When queueing a START for "open v.c.", PHYKLP should use the lowest possible
priority. THus, if any message has been queued to the port, the port will reject
it before sending the START. Otherwise, stale data might go out on the newly-
opened v.c.
		Handling of Buffers on Error
			Judy Hall
			6/17/84

I believe that PHYKLP should return both message buffers and datagram
buffers to the port's queues when these buffers are locally-generated,
the "response" bit is not on, and an error has occurred. Here is my
reasoning:

1. Message buffers

A. Those sent by a sysap.

	If the sysap doesn't want the buffer back, SCAMPI increments
its receive credit on the assumption that the buffer will be put on
the free queue when the port has finished with it.

	Indeed, if there is no error, the port puts the buffer on the
free queue, where it is available for an incoming message. If there is
an error, the count has still been incremented, so the buffer should
ultimately wind up on the free queue.

	If the node goes offline after the sysap has sent a message,
in theory the reaper could run before the port decides to refuse to send
the message. In this case, SCAMPI would remove "n" buffers from the port's
queue, where "n" includes the 1 that was added to it when the message was
sent. The buffer, then, belongs to the port.

B. Those sent by SCAMPI

	SCAMPI sends its requests in a buffer that has been allocated
especially for the purpose (one buffer per remote node). It assumes that
the remote system will send a response, for which the port will acquire
a buffer from the free queue. Thus it does not set the "response" bit
when it sends a request.

	If the node goes offline, and a request is outstanding, the port
will return the packet with error. Meanwhile, SCAMPI will have been called
at SC.ERR, where it will determine that the buffer is in use, and move
a buffer from the free queue to SCA's pool. When the original buffer is
finally available, it should replenish the free queue.

2. Datagrams

As with messages, the sysap may queue a datagram buffer without asking
for a response. In that case, SCAMPI counts it as being queued to the port
for an incoming datagram. (This accounting is similar to receive credit for
messages, but it is not communicated to the other host.) 

If no error occurs, the port returns this datagram buffer to the port's
free queue. Therefore, if there is an error, PHYKLP should return
such a buffer to the port's queue.
                             SCA Buffer Management
                                David Lomartire
                                   14-Sep-84



o  SC.ALC - Allocate message and datagram buffers for SCA pool

	Called by:	SC.ALM via job 0 when DDCFSF is non-zero

	Calls:		SC.CMG to create message buffers
			SC.CDG to create datagram buffers

   This  routine  is  responsible  for  keeping  the  SCA pool of datagrams and
messages up to the minimum thresholds. Whenever a buffer request is made  which
causes  the buffer count (FQCNT or DFQCNT) to fall below the minimum, DDCFSF is
set. This will make job 0 call SC.ALM which will call SC.ALC.

	For messages - 
	     The  number  of  buffers  in  FQCNT is checked against the minimum
threshold (MINMSG). If it is below, a call to SC.CMG is  made  to  create  more
message buffers to bring us up to the minimum threshold. Upon successful return
from  SC.CMG,  the  buffers  are  linked to BOTFQ, FQCNT is updated, and TOTMGB
(total number of buffers created so far) is updated.

	For datagrams - 
	     The  number  of  buffers  in DFQCNT is checked against the minimum
threshold (MINDG). If it is below, a call to SC.CDG  is  made  to  create  more
datagram  buffers  to  bring  us  up  to the minimum threshold. Upon successful
return from SC.CDG, the buffers are linked to BOTDFQ, DFQCNT  is  updated,  and
TOTDGB (total number of buffers created so far) is updated.


o  SC.DEF - Handle buffer deferral

	Called by:	SC.ALM via job 0 when DDCFSF is non-zero

	Calls:		SC.BF2 to get (and create if necessary) buffers

   This  routine  handles  buffer  deferral.  When  a connect block is stuck on
buffers, the bit corresponding to the node number of its system block is set in
SBSTUK and DDCFSF is set. The connect block is queued to the system block  work
queue.  When  job  0 runs, SC.DEF will run and call SC.BF2 in an attempt to get
the buffers it needs to send the connect_request or accept_request.

   When  run,  SC.DEF  "scans"  SBSTUK  to find the first system block with any
connect blocks which are stuck on buffers. The stuck bit for this system  block
is  cleared in SBSTUK and all the connect blocks which are stuck are processed.
Any connect block that became unstuck are placed on the end of the work  queue.
Once  all  connect  blocks  are done, a call is made to SC.SNM in an attempt to
send out the queued connection management requests for that system block.

   All  system  blocks  which  are  stuck  are  processed  until SBSTUK is zero
(indicating that there are no longer any stuck connect blocks).
o  SC.BUF (SC.BF1 - Allocate buffers from pool; cannot create buffers)
	  (SC.BF2 - Allocate buffers from pool; can create buffers)

	SC.BF1 called:	SC.SNM to get initial buffers for c.b.
	SC.BF2 called: 	SC.DEF when processing stuck connect blocks

	Calls:		SC.ABF to allocate message buffers
			SC.ALD to allocate datagram buffers
			SC.CMG to create message buffers 
			SC.CDG to create datagram buffers
			LNKMFQ to link message buffers to port
			LNKDFQ to link datagram buffers to port
			SC.RBF to return extra message buffers from SC.CMG
			SC.RLD to return extra datagram buffers from SC.CDG

   These routines are called by SC.SNM (SC.BF1) and SC.DEF (SC.BF2) to allocate
buffers for a connect_request or accept_request from the SCA pool.

	For messages - 
	   The  number  of buffers needed in CBIMB is checked to see if any are
required. If so, a call to SC.ABF is made to obtain them.

	   If  this  fails,  (and  if  buffers  cannot  be  created)  DMRCNT is
incremented to indicate this and a failure return results. If  buffers  can  be
created  a  call is made to SC.CMG to create the needed buffers. A failure here
results in a failure return from  SC.BUF.  On  success,  the  total  number  of
buffers created is added to TOTMGB. A check is made to see if more were created
than  were  required  and,  if  so, the extras are returned to the SCA pool via
a call to SCM.RM (which calls SC.RBF once for each extra buffer).

	   Once  the  buffers  have  been obtained, a call is made to SCL.MC to
link each message buffer onto the port message free queue (via call to LNKMFQ).
Pending receive credit (.CBPRC) is updated to reflect these  buffers.  Finally,
the number of buffers to queue (CBIMB) is set to zero.

	For datagrams -
	   The  number  of buffers needed in CBIDB is checked to see if any are
required. If so, a call to SC.ALD is made to obtain them.

	   If  this  fails,  (and  if  buffers  cannot  be  created)  DDRCNT is
incremented to indicate this and a failure return results. If  buffers  can  be
created  a  call is made to SC.CDG to create the needed buffers. A failure here
results in a failure return from  SC.BUF.  On  success,  the  total  number  of
buffers created is added to TOTDGB. A check is made to see if more were created
than  were  required  and,  if  so, the extras are returned to the SCA pool via
a call to SCM.RD (which calls SC.RLD once for each extra buffer).

	   Once  the  buffers  have  been obtained, a call is made to SCL.DC to
link each datagram buffer onto the  port  datagram  free  queue  (via  call  to
LNKDFQ).  The  count  of datagram buffers queued (.CBDGR) is changed to reflect
these buffers. Finally, the number of buffers to queue (CBIDB) is set to zero.
o  SC.SBT - Set buffer thresholds

	Called by:	SCA upon initialization to establish starting levels
			SC.ONL to update levels when node comes online
			SC.ERR to update levels when node goes offline

  This  routine  is  used  to  set  the  value for the minimum level of message
(MINMSG) and datagram buffers (MINDG) to be maintained by SCA.  This  count  is
based on the number of systems currently online (SBCNT). Whenever a request for
a  buffer  forces the count of buffers to fall below the minimum, DDCFSF is set
to signal job 0 to run SC.ALC and allocate more buffers for the SCA pool.

  MINMSG  = (SBCNT*MBPS)+MGTRSH, where MBPS is the number of message buffers to
maintain per online system and MGTRSH is the base value of buffers  which  must
be available.

  MINDG  = (SBCNT*DBPS)+DGTRSH, where DBPS is the number of datagram buffers to
maintain per online system and DGTRSH is the base value of buffers  which  must
be available.

o  SC.ABF - Allocate message buffers from SCA pool

	Called by:	SCA to acquire a buffer for NOTTAB
			SC.SMG to give the port a buffer on send failure
			SC.RMG to get the number of buffers to queue
			SC.ONL to get 2 buffers; 1 for .SBOBB and 1 for port
			SC.ACB to get a buffer to use as the connect block
			SC.BF2 to get buffers requested upon connect or accept

  This  routine  is  used to obtain message buffers from SCA's pool. First, the
number of buffers desired is checked against FQCNT and if greater, the  routine
will return an SCSNBA error. Next, the number of buffers left after the request
is  satisfied  (FQCNT-NUMBUF)  is  checked to see if it falls below the minimum
threshold (MGTRSH). [MGTRSH is used because it is the constant lower  threshold
below which no requests for buffers will be granted unless they are small (less
than LRGREQ). MINMSG is not used because it is a fluctuating value which depends
upon  the  number  of  nodes  up  at  the  moment.] If there are enough buffers
remaining (or if not and the request is small), the request is honored. If  the
request  is  honored  because  it  is  a small request, MBUST is incremented to
record this. To honor the request, the message free queue  (top  is  TOPFQ  and
bottom  is  BOTFQ)  is traversed to insure that there actually are the required
number of buffers.

  If  there  is an inconsistency, a SCAMCR BUGCHK will result and FQCNT will be
recalculated by tracing the free queue again. NMBCNT (the number  of  times  we
ran  out  of  message  buffers)  and RMRCNT (the number of times allocation was
refused) are incremented. DDCFSF is incremented to force SC.ALC to  run.  Also,
ASRMR  is  updated  to  reflect  the average size of refused requests. A SCSNBA
error will be returned.

  If  the  scan  of  the  free queue is successful, TOPFQ, BOTFQ, and FQCNT are
updated. If it is found that FQCNT has fallen below MINMSG, DDCFSF  is  set  to
allow SC.ALC to run.

  If  the  request  is  refused,  RMRCNT is incremented and ASRMR is updated to
reflect the average size of refused requests. A SCSNBA error will be  returned.
This  will occur when there are not enough buffers present to grant the request
or when a large request forces the count below the buffer threshold.
o  SC.ALD - Allocate datagram buffers from SCA pool

	Called by:	SC.SDG to give the port a buffer on send failure
			SC.RDG to acquire the buffers to queue
			SC.BF2 to get buffers requested upon connect or accept

  This  routine  is used to obtain datagram buffers from SCA's pool. First, the
number of buffers desired is checked against DFQCNT and if greater, the routine
will return an SCSNBA error. Next, the number of buffers left after the request
is satisfied (DFQCNT-NUMBUF) is checked to see if it falls  below  the  minimum
threshold  (DGTRSH). [DGTRSH is used because it is the constant lower threshold
below which no requests for buffers will be granted unless they are small (less
than LRGREQ). MINDG is not used because it is a fluctuating value which  depends
upon  the  number  of  nodes  up  at  the  moment.] If there are enough buffers
remaining (or if not and the request is small), the request is honored. If  the
request  is  honored  because  it  is  a small request, DBUST is incremented to
record this. To honor the request, the datagram free queue (top is  TOPDFQ  and
bottom  is  BOTDFQ) is traversed to insure that there actually are the required
number of buffers.

  If there is an inconsistency, DFQCNT will be recalculated by tracing the free
queue  again.  NDBCNT  (the number of times we ran out of datagram buffers) and
RDRCNT (the number of times allocation was refused) are incremented. DDCFSF  is
incremented  to  force  SC.ALC  to  run.  Also, ASRDR is updated to reflect the
average size of refused requests. A SCSNBA error will be returned.

  If  the  scan of the free queue is successful, TOPDFQ, BOTDFQ, and DFQCNT are
updated. If it is found that DFQCNT has fallen below MINDG, DDCFSF  is  set  to
allow SC.ALC to run.

  If  the  request  is  refused,  RDRCNT is incremented and ASRDR is updated to
reflect the average size of refused requests. A SCSNBA error will be  returned.
This  will occur when there are not enough buffers present to grant the request
or when a large request forces the count below the buffer threshold.


o  SC.CMG/SC.CDG - Create message/datagram buffers

	Called by:	SC.ALC to create buffers needed to boost above minimum
			SC.BF2 to create buffers needed by connect or accept

	Calls:		SC.BBF to break memory pages into buffer chain

  These  routines are used to create message and datagram buffers. It is called
when the SCA buffer pool is exhausted (or below minimum values) and needs to be
restocked. The number of buffers returned is rounded up  to  fill  an  integral
number of pages so extra buffers may be provided.

  First  the number of pages required to fill the buffer request is calculated.
For each page required, EPGMAP is searched to locate an empty page. If no empty
pages are found, the routine returns with a SCSNEB error. The search starts  at
offset  LSTEPG  (which is initialized to 777) and decrements towards the top of
the map. When a free page is found, the next lower offset is placed  in  LSTEPG
and  a  call is made to MLKMA to lock down the page. Finally, a call is made to
SC.BBF to break the page into buffers  of  the  appropriate  size  (C%MGSZ  for
messages and C%DGSZ for datagrams).
o  SC.BBF - Break memory page into buffers

	Called by:	SCA to create the initial chain of buffers
			SC.CMG to create chain of message buffers
			SC.CDG to create chain of datagram buffers

  This routine will take a page of memory and break it into a chain of message 
or datagram buffers.  The page is broken up into buffers of C%BINV+C%MGSZ size 
for messages and C%BINV+C%DGSZ for datagrams.  C%BINV is the size of the 
invisible area which is prepended to the top of each buffer for local use (it 
is never sent across the CI).  The FLINKs of each buffer point to the next 
buffer in the chain.


o  SC.RBF - Return a message buffer

	Called by:	SC.ERR to return the two buffers obtained at SC.ONL
			SC.INT to return buffer sent by SCA
			SC.RCB to return buffers queued by connection
			SC.JSY to return buffers queued by JSYS
			SC.GCB to return buffers in RET_CREDIT field (.CBRTC)
			SCM.RM to return one of a chain of message buffers
			SC.ABF to return extra buffers from SC.CMG

  This  routine  will  return  message  buffers  to the SCA message free queue.
First, the entire buffer (C%BINV+C%MGSZ) is zeroed. Then the buffer  is  linked
to  BOTFQ  and  FQCNT is incremented to reflect the additional buffer. Note that
this routine is passed back to the caller by SC.ABF as the routine to  call  to
return the buffer.


o  SC.RLD - Return a datagram buffer

	Called by:	SC.CRD to return buffer which was canceled
			SC.RCB to return buffers queued by connection
			SC.JSY to return buffers queued by JSYS
			SCM.RD to return one of a chain of datagram buffers
			SC.ALD to return extra buffers from SC.CDG

  This  routine  will  return  datagram buffers to the SCA datagram free queue.
First, the entire buffer (C%BINV+C%DGSZ) is zeroed. Then the buffer  is  linked
to  BOTDFQ and DFQCNT is incremented to reflect the additional buffer. Note that
this routine is passed back to the caller by SC.ALD as the routine to  call  to
return the buffer.



                                  The SCS% JSYS

                                    31-Jan-83
   SCS% JSYS                                                            Page 1
   General format of JSYS call


          The following is the general format of a call to the SCS% JSYS.


             Call
             T1/     Function code
             T2/     Address of arg block


             Return (+1) Always
             T1/     Function code
             T2/     Address of arg block
             
             An error generates an illegal instruction trap.

     General format of the argument block:

              !=======================================================!
     .SQLEN   !      Words processed      !     Length of block       !
              !-------------------------------------------------------!
              \                                                       \
              \             Function dependent arguments              \
              \                                                       \
              !=======================================================!

          Where the "words processed" is the number of words in  the  argument
     block  that the monitor actually looked at and used.  Hence this field is
     returned by the monitor, not supplied by the user.  The "length of block"
     is the total length of the supplied block including the header word.
          Note that this JSYS  requires  one  or  any  combination  of  wheel,
     maintainance, or network wizard.
   SCS% JSYS                                                            Page 2
   Connect (.SSCON)


                                Connect (.SSCON)



          This function requests a connection with another  node  on  the  CI.
     The  JSYS  will  return  as soon as the connection request has been sent.
     You are notified that your connection request was granted or failed via a
     PSI interrupt.

     The argument block has the following format:
|  
|             !=======================================================!
|    .SQLEN   !      Words processed      !     Length of block       !
|             !-------------------------------------------------------!
|    .SQSPN   !          Byte pointer to source process name          !
|             !-------------------------------------------------------!
|    .SQDPN   !       Byte pointer to destination process name        !
|             !-------------------------------------------------------!
|    .SQSYS   !    SBI of destination     !   6 bits of connect ID    !
|             !-------------------------------------------------------!
|    .SQCDT   !               Pointer to connection data              !
|             !-------------------------------------------------------!
|    .SQAMC   !    Address of first buffer on message buffer chain    !
|             !-------------------------------------------------------!
|    .SQADC   !    Address of first buffer on datagram buffer chain   !
|             !-------------------------------------------------------!
|    .SQRCI   !                  Returned connect ID                  !
|             !=======================================================!
|  


     The byte pointer to the source process name is  a  byte  pointer  to  the
     ASCII  string  which  is the name of your process.  Note that this string
     must end on a null byte and may be  a  maximum  of  16  bytes  long,  not
     including the null byte.

     The byte pointer to destination process name is the byte pointer  to  the
     name of the process you wish to connect to.  This name must also end in a
     null byte and may be a maximum of 16 bytes, not including the null byte.

     The SBI (system block index) is the unique identifier of the  system  you
     wish to connect to.

     Note that the specified strings may be any vaild ASCII  byte  size  (I.E.
     any byte size equal to or larger than 7 bits).  These strings may also be
     generic byte pointers (-1,,STRNG).  If generic byte pointers are given, 7
     bit ASCII terminated by a null byte is assumed.

     The 6 bits of connect ID is 6 right justified bits which will  be  placed
     in the most significant bits of the connect ID.  These bits are generally
     used for connection managment by the user program.  If  initial  data  is
     not desired then this word is zero.
|  
|    The pointer to connection data is the address of a block of  data  SQ%CDT
   SCS% JSYS                                                            Page 3
   Connect (.SSCON)


|    words  long  to  be  sent as connection data.  Note that the monitor will
|    copy SQ%CDT words of data from the users address  space.   Hence  a  full
|    block SQ%CDT words long should be allocated for the data.
   SCS% JSYS                                                            Page 4
   Listen (.SSLIS)


                                 Listen (.SSLIS)



          This function listens for a connection.  Note that the JSYS does not
     block.   You  will  be  notified  of  a  connect to your listen via a PSI
     interrupt.
          There are a number of options that may be used when doing  a  listen
     for  a  connection.   You  may  listen  for a particular process from any
     system by making the system block index  -1.   You  may  listen  for  any
     process  from  a  particular  system  by  making  the byte pointer to the
     destination process name -1.  If the system  block  index  and  the  byte
     pointer  to  the  destination  process name are both -1, then any connect
     request that is not for a particular process name will match your listen.
     Naturally  you  may  specify both a system block index and a process name
     and then only that process from the  named  system  will  be  allowed  to
     connect to your listen.
|  
|  
|  
|             !=======================================================!
|    .SQLEN   !      Processed words     !       Length of block      !
|             !-------------------------------------------------------!
|    .SQSPN   !          Byte pointer to source process name          !
|             !-------------------------------------------------------!
|    .SQDPN   !       Byte pointer to destination process name        !
|             !-------------------------------------------------------!
|    .SQSYS   !    SBI of destination     !   6 bits of connect ID    !
|             !-------------------------------------------------------!
|    .SQMGA   !    Address of first buffer on message buffer chain    !
|             !-------------------------------------------------------!
|    .SQDGA   !    Address of first buffer on datagram buffer chain   !
|             !-------------------------------------------------------!
|    .SQLCI   !                Returned connect ID                    !
|             !=======================================================!
|  


          See the description of .SSCON for an explanation of  each  field  in
     this block.
   SCS% JSYS                                                            Page 5
   Accept (.SSACC)


                          Accept a connection (.SSACC)



          This function tells a remote node that you are granting his  request
     for a connection.



             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !                      Connect ID                       !
             !-------------------------------------------------------!
      .SQCDA !              Pointer to connection data               !
             !=======================================================!



          The pointer to connection data  is  the  address  of  the  block  of
     connection  data  to be sent to the remote system.  The monitor will copy
     SQ%CDT words of data from the users address space  as  data.   Note  that
     this  data will be sent directly over the CI and hence the low order four
     bits are not sent.
   SCS% JSYS                                                            Page 6
   Reject (.SSREJ)


                          Reject a connection (.SSREJ)



          This function code tells a remote node that you are not  allowing  a
     connection to your process.

     The argument block for this function has this format:

             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !                      Connect ID                       !
             !-------------------------------------------------------!
      .SQREJ !                   Rejection reason                    !
             !=======================================================!



          The rejection reason is a relativly small integer that indicates  to
     the remote host why you are not allowing the connection.  MONSYM contains
     a list of these codes.
   SCS% JSYS                                                            Page 7
   Disconnect (.SSDIS)


                               Disconnect (.SSDIS)



          This function closes a connection.   The  disconnect  function  code
     requires the following arguments:



             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !                      Connect ID                       !
             !-------------------------------------------------------!
      .SQDIS !                   Disconnect reason                   !
             !=======================================================!



          The disconnect reason is a relativly  small  positive  integer  that
     indicates  to  the  remote  system,  why  you are closing the connection.
     MONSYM contains the list of definitions of these codes.
   SCS% JSYS                                                            Page 8
   Send a DG (.SSSDG)


                            Send a datagram (.SSSDG)



          This function code sends a datagram.  The  following  arguments  are
     required:


             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !                      Connect ID                       !
             !-------------------------------------------------------!
      .SQADG !               Address of datagram text                !
             !-------------------------------------------------------!
      .SQDGL !        Length in 8 bit bytes of datagram data         !
             !-------------------------------------------------------!
      .SQFLG !                        Flags                  !  OPS  !
             !=======================================================!


          OPS is an  optional  path  specification.   If  specified,  the  OPS
     indicates  that you wish to send this datagram over a particular hardware
     cable (path).  A complete description of  this  field  may  be  found  in
     MONSYM along with the flag definitions for the rest of the word.

                              *** Restrictions ***

     1.  The datagram text may not cross a page boundry.

     2.  A monitor overhead area  of  .SQTXT  words  must  appear  before  the
         message text.

     3.  Swapping of the page will be prevented while it is in the process  of
         being sent.  Hence forcing the page to be swapped before notification
         of message send complete will cause the hardware much grief.

     4.  The datagram text must be packed in  left  justified,  word  aligned,
         eight bit bytes.
   SCS% JSYS                                                            Page 9
   Queue a DG buffer (.SSQRD)


                 Queue a buffer for datagram reception (.SSQRD)



          This function code queues buffers for datagram reception.
          Note that in each buffer the first word is the address of  the  next
     buffer.   The  last  buffer  has  zero as the address of the next buffer.
     This function requires these arguments:


             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !                      Connect ID                       !
             !-------------------------------------------------------!
      .SQAFB !        Address of first buffer on buffer chain        !
             !=======================================================!


                              *** Restrictions ***


|    1.  Datagram buffers must be 152 words in length.
   SCS% JSYS                                                           Page 10
   Send message (.SSSMG)


                             Send a message (.SSSMG)



          This function code sends a message to a remote node.


             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !                      Connect ID                       !
             !-------------------------------------------------------!
      .SQAMT !                Address of message text                !
             !-------------------------------------------------------!
      .SQLMT !           Length of message in 8 bit bytes            !
             !-------------------------------------------------------!
      .SQFLG !                        Flags                  !  OPS  !
             !=======================================================!


          OPS is an abbreviation for "optional path spec".  If specified,  the
     OPS  indicates  that  you  wish  to  send  this message over a particular
     hardware cable (path).  There are three possible settings of these  bits.
     A  zero or one indicate the path to use, either zero or one.  If all bits
     are 1, then the monitor will select the  path  over  which  to  send  the
     message.  The complete set of flag definitions may be found in MONSYM.
     Note that the length of the message is the number of eight bit  bytes  in
     the message.
                              *** Restrictions ***

     1.  The message text may not cross a page boundry.

     2.  A monitor overhead area  of  .SQTXT  words  must  appear  before  the
         message text.

     3.  Swapping of the page will be prevented while it is in the process  of
         being sent.  Hence forcing the page to be swapped before notification
         of message send complete will cause the hardware much grief.
|  
|    4.  Message text may not be longer than 38 36 bit words (152 bytes).
   SCS% JSYS                                                           Page 11
   Queue message recieve buffers (.SSQRM)


                     Queue message receieve buffers (.SSQRM)



|         This function code queues buffer to receieve  messages.   Note  that
|    the  buffer size is fixed at 38, 36 bit words.  It requires the following
|    arguments:


             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !                      Connect ID                       !
             !-------------------------------------------------------!
      .SQAFB !            Address of buffer chain to queue           !
             !=======================================================!
   SCS% JSYS                                                           Page 12
   Cancel DG receive (.SSCRD)


                        Cancel datagram receive (.SSCRD)



          This function code removes a buffer queued for  datagram  reception.
     The  address  that  you  specify must be the address of a buffer that was
     previously queued for receiving datagrams (with .SSQRD).  If this address
     is  not  found  by the monitor when it goes to take the buffer out of its
     queue, the JSYS fails with an illegal instruction  trap.   This  function
     requires these arguments:


             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !                      Connect ID                       !
             !-------------------------------------------------------!
      .SQADB !             Address of buffer to dequeue              !
             !=======================================================!
   SCS% JSYS                                                           Page 13
   Cancel receieve message (.SSCRM)


                        Cancel receieve message (.SSCRM)



          The  function  dequeues  a  buffer  that  was  queued  for   message
     reception.  The buffer address that is specified must be of a buffer that
     you asked to be queued for  message  reception  (with  .SSQRM).   If  the
     monitor does not find the address specified in the argumnet block amongst
     the buffers you queued, the JSYS will fail.  This function  requires  the
     following arguments:


             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !                      Connect ID                       !
             !-------------------------------------------------------!
      .SQADB !             Address of buffer to dequeue              !
             !=======================================================!
   SCS% JSYS                                                           Page 14
   Connect state poll (.SSCSP)


                           Connect state poll (.SSCSP)



          This function returns information about that state of a  connection.
     The argument block to this function includes space for the returned data.
     The argument block for this function looks like this:



             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !                      Connect ID                       !
             !-------------------------------------------------------! ------------
      .SQCST !                   Connection state                    !      ^
             !-------------------------------------------------------!      !
      .SQDCI !                Destination connect ID                 !      !
             !-------------------------------------------------------!   Returned
      .SQBDN !       Byte pointer to destination process name        !     data
             !-------------------------------------------------------!      !
      .SQSBI !           System block index of destination           !      !
             !-------------------------------------------------------!      !
      .SQREA ! Source disconnect reasons !  Dest disconnect reasons  !      v
             !=======================================================! ------------


          Note that the byte pointer  to  destination  process  name  must  be
     provided by the caller and may be either a real byte pointer or minus one
     in the left half and the base address of the string in  the  right  half.
     If  the generic byte pointer is used the monitor will write the string as
     16 word aligned eight bit bytes, not the usual 7 bit bytes!
   SCS% JSYS                                                           Page 15
   Return configuration data (.SSRCD)


                       Return configuration data (.SSRCD)



          This function returns data about another system.  Given  the  system
     block  index the monitor will return data about that system.  The data is
     returned in the block pointed to by T1 which looks like this:


             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !                  Optional connect ID                  !
             !-------------------------------------------------------!
      .SQOSB !              Optional system block index              !
             !-------------------------------------------------------!  -----------
      .SQVCS !   Virtual circuit state   !        Port number        !       ^
             !-------------------------------------------------------!       !
      .SQSAD \                                                       \       !
             \     System address (6 8-bit bytes, word aligned)      \       !
             \                                                       \       !
             !-------------------------------------------------------!       !
      .SQMDD !           Maximum destination datagram size           !       !
             !-------------------------------------------------------!       !
      .SQMDM !           Maximum destination message size            !    Returned
             !-------------------------------------------------------!      data
      .SQDST !               Destination software type               !       !
             !-------------------------------------------------------!       !
      .SQDSV !             Destination software version              !       !
             !-------------------------------------------------------!       !
      .SQDSE !            Destination software edit level            !       !
             !-------------------------------------------------------!       !
      .SQDHT !               Destination hardware type               !       !
             !-------------------------------------------------------!       !
      .SQDHV !             Destination hardware version              !       !
             !-------------------------------------------------------!       !
      .SQPCW \               Port characteristics bytes              \       !
             \    6, 8 bit bytes, word aligned in leftmost 32 bits   \       !
             !-------------------------------------------------------!       !
      .SQLPN !                  Local port number                    !       v
             !=======================================================!  ------------


          The symbols which define the various hardware and software types may
     be found in MONSYM.

          The connect ID and system block index are optional in  that  one  or
     the  other  must  be specified, but not both.  If the connect ID field is
     non-zero then the SBI field is ignored and the  information  returned  is
     for  the  system  implied  by the connect ID.  If the connect ID field is
     zero then the SBI field is used.  Note that this allows the  use  of  the
     zero'th system block index.

          If the local port number is not available, -1 will  be  returned  to
   SCS% JSYS                                                           Page 16
   Return configuration data (.SSRCD)


     the user in offset .SQLPN.
   SCS% JSYS                                                           Page 17
   Return status information (.SSSTS)


                       Return status information (.SSSTS)



          This function returns status information about a connection.  It  is
     intended  as  a  fast  form  of  the  .SSCSP  function code which returns
     detailed information about a  connection.   This  function  requires  the
     following arguments:

             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQCID !                      Connect ID                       !
             !-------------------------------------------------------!
      .SQFST !           Flags          !       Connect state        ! -------------
             !-------------------------------------------------------!    Returned
      .SQSBR !         Reserved         !       SBI of remote        !      data
             !=======================================================! -------------


          The flags which appear in the flags field are:

     1.  Message available - There is at least one message avilable  for  this
         connection.

     2.  Datagram available - There is at least  one  datagram  available  for
         this connection.

     3.  DMA transfer complete - At least one DMA transfer has completed since
         the  last  time  the SCS% JSYS was performed with this function code.
         The bit is cleared in the monitor data base when this  function  code
         is performed.


     The complete set of flag symbol definitions may be found in MONSYM.   The
     connect  state  is  provided such that a reasonable interpretation of the
     flags may be made.
   SCS% JSYS                                                           Page 18
   Receive a message (.SSRMG)


                           Receive a message (.SSRMG)



          This function code returns message text for either the calling  fork
     or  the  specified  connection.   If the connect ID field in the argument
     block is minus one, then the first message found for the calling fork  is
     returned.   If the connect ID is anything but minus one (-1), the monitor
     will use this as a connect ID and return the first message found for that
     connection.   Note  that  if  there  is  no  message available an illegal
     instruction is generated.  The following argument block is  required  for
     this function code.


             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------! -----------
      .SQCID !                  Connect ID or -1                     !      ^
             !-------------------------------------------------------!      !
      .SQARB !              Address of returned buffer               !      !
             !-------------------------------------------------------! Returned data
      .SQDFL !          Flags           !        SBI of remote       !      !
             !-------------------------------------------------------!      !
      .SQLRP !             Length of returned packet               !      v
             !=======================================================! -----------


          The address of returned buffer is the address in  your  working  set
     that  the  monitor  has  placed  your  data.   This address is one of the
     addresses previously specifed by a .SSQRM call.  If no  .SSQRM  call  was
     done, then this function code will fail with an illegal instruction trap.
     If the address is not writable you will also get an  illegal  instruction
     trap.
          The flags are returned by the monitor and  currently  only  indicate
     the data packing mode.
          The length of the returned  packet  is  in  bytes  for  an  industry
     compatible mode message, and words for a high density mode packet.
   SCS% JSYS                                                           Page 19
   Receive a datagram (.SSRDG)


                           Receive a datagram (.SSRDG)



     This function code returns datagram text for either the calling  fork  or
     the  specified connection.  If the connect ID field in the argument block
     is minus one, then the first datagram  found  for  the  calling  fork  is
     returned.   If the connect ID is anything but minus one (-1), the monitor
     will use this as a connect ID and return the  first  datagram  found  for
     that connection.  This is the argument block for this function code:


             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------! -----------
      .SQCID !                  Connect ID or -1                     !      ^
             !-------------------------------------------------------!      !
      .SQARB !              Address of returned buffer               !      !
             !-------------------------------------------------------! Returned data
      .SQDFL !          Flags           !        SBI of remote       !      !
             !-------------------------------------------------------!      !
      .SQLRP !            Length of returned packet                !      v
             !=======================================================! -----------


     The address of returned data is one of  the  addresses  provided  to  the
     monitor on a .SSQRD call.  If no .SSQRD was done or if the address is not
     writable, the JSYS will fail with an illegal instruction trap.  Also note
     that if there was no datagram available this address is zero.
          The flags are returned by the monitor and  currently  only  indicate
     the data packing mode.
          The length of the returned packet is in words  if  this  is  a  high
     density datagram, and bytes if an industry compatible datagram.
   SCS% JSYS                                                           Page 20
   .SSGDE (Get entry from data queue)


                       .SSGDE (Get entry from data queue)



          This function code returns the first entry  from  the  data  request
     complete queue.  The argument block follows:

              !=======================================================!
      .SQLEN  !      Words processed      !      Length of block      !
              !-------------------------------------------------------!
      .SQBID  !           Buffer ID whos transfer completed           !
              !=======================================================!

          The buffer ID indicates which DMA transfer has completed.
   SCS% JSYS                                                           Page 21
   .SSEVT (Get an entry off the event queue)


                    .SSEVT (Get an entry off the event queue)



          This function code retrieves the first entry off  the  event  queue.
     This  queue  is  a  record of events that the JSYS user is to be notified
     about.  The user receives an interrupt on the first  event.   After  this
     events  will  be added to the end of the queue with no further interrupts
     generated.  It is the responsibility of the user to empty this queue upon
     receiving an event interrupt.

          If a  connect  ID  is  specified,  then  the  next  event  for  that
     connection  will  be  returned.  If however the connect ID field is minus
     one, then the next event for the fork is returned.

              !=======================================================!
      .SQLEN  !      Words processed      !      Length of block      !
              !-------------------------------------------------------! -----------
      .SQCID  !                  Connect ID or -1                     !      ^
              !-------------------------------------------------------!      !
      .SQESB  !         Reserved          !       SBI of remote       !      !
              !-------------------------------------------------------!   Returned
      .SQEVT  !                 Returned event code                   !     data
              !-------------------------------------------------------!      !
      .SQDTA  \                                                       \      !
              \                 Returned event data                   \      !
              \                                                       \      v
              !=======================================================! -----------

          The event code describes what event has  occured.   It  is  a  small
     integer  ranging  from  zero  to a maximum value.  Hence it can easily be
     used as an index into an event dispatch table.  The connect ID tells  you
     what  connection this event is relevant to.  The event data is a block of
     data returned for each event type.
   SCS% JSYS                                                           Page 22
   DMA overview


                                  DMA overview



|         To send data to a remote system, you must first  declare  memory  in
|    your  working  set to be part of a buffer.  A buffer is made of segments.
|    Each segment is a contiguous set of 36 bit words that DO NOT CROSS A PAGE
|    BOUNDARY  and  are not more than one page long.  Once the buffer has been
|    established, you must tell the remote system the name of the buffer  that
|    you have declared.
   SCS% JSYS                                                           Page 23
   Map a buffer (.SSMAP)


                              Map a buffer (.SSMAP)
|  
|  
|  
|         This function code associates a portion of memory with an SCA buffer
|    name  to  be  used  in  DMA transfers.  This function takes the following
|    arguments:
|  
|            !=======================================================!
|     .SQLEN !      Processed words     !       Length of block      !
|            !-------------------------------------------------------!
|     .SQBNA !             Returned 32 bit buffer name               ! (Returned)
|            !-------------------------------------------------------!
|            /                                                       /
|            /           Buffer length and address pairs             /
|            /                                                       /
|            !=======================================================!
|  
|         Buffer length and address paris have the following format:
|  
|  
|            !=======================================================!
|    .SQBLN  !        Length in 36 bit words of memory block         !
|            !-------------------------------------------------------!
|    .SQBAD  !          Address of memory for DMA transfer           !
|            !=======================================================!
|  
|         The address for DMA transfer is the  address  in  your  working  set
|    where  you  expect  data  from a DMA transfer to be placed by the CI port
|    microcode.  All pages in your working set  that  are  contained  in  this
|    request  will  be locked into resident memory.  They will remain this way
|    until you unmap the buffer.
|  
|         The buffer name is the descriptor by which all other  references  to
|    this memory is made.


                              *** Restrictions ***

     1.  No buffer segment may cross  a  page  boundary.   Hence  the  longest
         possible buffer segment is one page.



                                      Note:
          All pages containing a buffer segment will be locked  into  physical
     memory.  Unlocking these pages behind SCA's back will cause severe system
     problems!!!
   SCS% JSYS                                                           Page 24
   Unmap a buffer (.SSUMP)


                             Unmap a buffer (.SSUMP)



          This function will remove from  the  monitor  data  base  (unmap)  a
     memory block assigned for DMA transfers.  It requires these arguments:

             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!
      .SQNAM !                  32 bit buffer name                   !
             !=======================================================!

          Upon completion of this call the pages in the memory  block  are  no
     longer locked into physical memory.
   SCS% JSYS                                                           Page 25
   Send data (.SSSND)


                               Send data (.SSSND)



|         This  function  transfers  data  to  a  remote  host.   It  is   the
|    responsibility  of a higher level protocol to arrange the setup of buffer
|    names.  The call requires the following arguments:
|  
|            !=======================================================!
|     .SQLEN !      Processed words     !       Length of block      !
|            !-------------------------------------------------------!
|     .SQCID !       Connect ID for which transfer is to be done     !
|            !-------------------------------------------------------!
|     .SQSNM !          32 bit buffer name of send buffer            !
|            !-------------------------------------------------------!
|     .SQRNM !        32 bit buffer name of receive buffer           !
|            !-------------------------------------------------------!
|     .SQOFS !        Xmit offset       !       Receive offset       !
|            !=======================================================!
   SCS% JSYS                                                           Page 26
|  Request data (.SSREQ)


|                             Request data (.SSREQ)
|  
|  
|  
|         This function tells SCA and the port  to  get  data  for  the  given
|    buffer name.  The following arguments are required:
|  
|            !=======================================================!
|     .SQLEN !      Processed words     !       Length of block      !
|            !-------------------------------------------------------!
|     .SQCID !       Connect ID for which transfer is to be done     !
|            !-------------------------------------------------------!
|     .SQSNM !          32 bit buffer name of send buffer            !
|            !-------------------------------------------------------!
|     .SQRNM !        32 bit buffer name of receive buffer           !
|            !-------------------------------------------------------!
|     .SQOFS !        Xmit offset       !       Receive offset       !
|            !=======================================================!
   SCS% JSYS                                                           Page 27
   Read port counters (.SSRPC)


                           Read port counter (.SSRPC)



          This function reads  the  maintainance  counters  out  of  the  port
     hardware.  The following argument block is used:


             !=======================================================!
      .SQLEN !      Processed words     !       Length of block      !
             !-------------------------------------------------------!  -----------
      .SQP0A !                  Path zero ACK count                  !       ^
             !-------------------------------------------------------!       !
      .SQP0N !                  Path zero NAK count                  !       !
             !-------------------------------------------------------!       !
      .SQP0R !              Path zero no response count              !       !
             !-------------------------------------------------------!       !
      .SQP1A !                  Path one ACK count                   !       !
             !-------------------------------------------------------!    Returned
      .SQP1N !                  Path one NAK count                   !      data  
             !-------------------------------------------------------!       !
      .SQP1R !              Path one no response count               !       !
             !-------------------------------------------------------!       !
      .SQNPT !             Number of packets transmitted             !       !
             !-------------------------------------------------------!       !
      .SQNPR !              Number of packets received               !       !
             !-------------------------------------------------------!       !
      .SQPOR !                    Designated port                    !       v
             !=======================================================!  -----------


          Only the function code is passed to the monitor.  The rest  of  this
     block is information returned by the monitor.
   SCS% JSYS                                                           Page 28
   .SSAIC (Add interrupt channels)


                         .SSAIC (Add interrupt channels)



|         All notifications from SCA  happen  on  four  PSI  channels.   These
|    channels  are:   datagram  available,  message  available,  DMA  transfer
|    complete, and all  other  events.   These  other  events  include  vitual
|    circuit  closure,  connection  managment  events,  and  all  port and SCA
|    related errors.  Interrupts will work just as they do now,  add  the  SCA
|    bits  to  the  interrupt  mask,  add  a cooresponding entry to LEVTAB and
|    CHNTAB, and an interrupt service routine.
|         Note that this call  only  tells  SCA  what  channels  to  use  when
|    interrupts  are  to  be given.  It is not a replacement for the AIC JSYS!
|    The argument block used to associate events with PSI  channels  has  this
|    format:

             !=======================================================!
      .SQLEN !      Words processed      !      Length of block      !
             !-------------------------------------------------------!
             \                                                       \
             \          Up to four channel descriptor words          \
             \                                                       \
             !=======================================================!

     Where channel desrciptor words have the following format:

             !=======================================================!
             !    Interrupt type code    !   Channel for this code   !
             !=======================================================!

     The interrupt type code is a small integer that indicates an event  type.
     The  channel number field allows you to enable and disable interrupts for
     the given event type.  If the channel number is -1  then  interrupts  are
     disabled.   If  it  is an integer between zero and thirty five, then that
     channel will interrupt on the given event  type.   The  next  box  is  an
     example of what the maximum size block would look like.

             !=======================================================!
      .SQLEN !      Words processed      !      Length of block      !
             !-------------------------------------------------------!
             !          .SIDGA           !      Channel number       !
             !-------------------------------------------------------!
             !          .SIMSA           !      Channel number       !
             !-------------------------------------------------------!
             !          .SIDMA           !             -1            !
             !-------------------------------------------------------!
             !          .SIPAN           !      Channel number       !
             !=======================================================!

     In this example interrupts for message available, datagram available, and
     all  other events are being enabled.  Interrupts on DMA transfer complete
     are being disabled.  Note that only the first word  of  this  block  need
     appear  in this position.  The channel descriptor words may appear in any
     order.  There must be at least one but  not  more  than  four  descriptor
   SCS% JSYS                                                           Page 29
   .SSAIC (Add interrupt channels)


     words in a block.
SCA-TABLES.TXT

;States of a connection. Names in all caps are from corporate spec.

	.CSCLO==1		;Closed (CLOSED) 
	.CSLIS==2		;Listening (LISTENING)
	.CSCSE==3		;Connect request was sent (CONNECT_SENT)
	.CSCRE==4		;Connect request was received (CONNECT_REC)
	.CSCAK==5		;Connect response was received (CONNECT_ACK)
	.CSACS==6		;Accept request was sent (ACCEPT_SENT)	
	.CSRJS==7		;Reject request was sent (REJECT_SENT)
	.CSOPN==10		;Connection is open (OPEN)
	.CSDSE==11		;Disconnect request was sent (DISCONNECT_SENT)
	.CSDRE==12		;Disconnect request received (DISCONNECT_REC)
	.CSDAK==13		;Disconnect response received (DISCONNECT_ACK)	
	.CSDMC==14		;Waiting for disconnect response (DISCONNECT_MATCH)

;States of a connection block

	.BSFRE==:1		;Free
	.BSALL==:2		;Allocate
	.BSCNP==:3		;Connect pending
	.BSACP==:4		;Accept pending
	.BSRPN==:5		;Reject pending
	.BSCRP==:6		;Credit pending
	.BSDPN==:7		;Disconnect pending


;Messages

	.STORQ==0		;Connect request
		.LNORQ==^D64
	.STORS==1		;Connect response
		.LNORS==^D16
	.STARQ==2		;Accept request
		.LNARQ==^D64
	.STARS==3		;Accept response
		.LNARS==^D16
	.STRRQ==4		;Reject request
		.LNRRQ==^D16
	.STRRS==5		;Reject response
		.LNRRS==^D12
	.STDRQ==6		;Disconnect request
		.LNDRQ==^D16
	.STDRS==7		;Disconnect response
		.LNDRS==^D12
	.STCRQ==10		;Credit request
		.LNCRQ==^D12
	.STCRS==11		;Credit response
		.LNCRS==^D12

	.STAMG==12		;Application message
	.STADG==13		;Application datagram
;Table X - calls from sysap to SCA.
;Note: if new connection state is in <>, it isn't set until the pending
;message has been sent

Routine	State		Legal?		New block	New connection
					State		State

SC.CON	Closed		Y		CONN_PEND	<connect_sent>
	Listening
	Connect_sent
	Connect_rec
	Connect_ACK
	Open
	Accept_sent
	Reject_sent
	Disconnect_sent
	Disconnect_rec
	Disconnect_ACK
	Disconnect_match



Routine	State		Legal?		New block	New connection
					State		State

SC.LIS	Closed		Y		-		Listen
	Listening
	Connect_sent
	Connect_rec
	Connect_ACK
	Open
	Accept_sent
	Reject_sent
	Disconnect_sent
	Disconnect_rec
	Disconnect_ACK
	Disconnect_match

Routine	State		Legal?		New block	New connection
					State		State

SC.ACC	Closed
	Listening
	Connect_sent
	Connect_rec	Y		ACC_PEND	<Accept-sent>
	Connect_ACK
	Open
	Accept_sent
	Reject_sent
	Disconnect_sent
	Disconnect_rec
	Disconnect_ACK
	Disconnect_match

* * Old code didn't change state
Routine	State		Legal?		New block	New connection
					State		State

SC.REJ	Closed
	Listening
	Connect_sent
	Connect_rec	Y		REJ_PEND	<reject_sent>
	Connect_ACK
	Open
	Accept_sent
	Reject_sent
	Disconnect_sent
	Disconnect_rec
	Disconnect_ACK
	Disconnect_match

* * * Old code left state as "listen"



Routine	State		Legal?		New block	New connection
					State		State

SC.DIS	Closed		Y		FREE		closed
	Listening	Y		FREE		closed
	Connect_sent	Y		FREE		closed
	Connect_rec	Y		REJ_PEND	reject_sent
	Connect_ACK	Y		FREE		closed
	Open		Y		DIS_PEND	disconnect_sent
	Accept_sent	Y		FREE		closed
	Reject_sent	Y		FREE		closed
	Disconnect_sent	Y		FREE		closed
	Disconnect_rec	Y		DIS_PEND	disconnect_match
	Disconnect_ACK	Y		FREE		closed
	Disconnect_match Y		FREE		closed
;Table Y -- processing SCS work queue

Block		Op code		New connection
State		to send		State

CONN_PEND	CONNECT_REQ	connect_sent
ACC_PEND	ACCEPT_REQ	accept_sent
REJ_PEND	REJECT_REQ	reject_sent
DIS_PEND	DISCON_REQ	-- (already done)
CREDIT_PEND	CREDIT_REQ	--
;Table Z - sending an SCS message

Name		Code		Length		priority	Response

CONNECT_REQ	.STORQ==0	.LNORQ==^D64	.MPCMM		CONNECT_RSP
CONNECT_RSP	.STORS==1	.LNORS==^D16	.MPCMM
ACCEPT_REQ	.STARQ==2	.LNARQ==^D64	.MPCMM		ACCEPT_RSP
ACCEPT_RSP	.STARS==3	.LNARS==^D16	.MPCMM
REJECT_REQ	.STRRQ==4	.LNRRQ==^D16	.MPCMM		REJECT_RSP
REJECT_RSP	.STRRS==5	.LNRRS==^D12	.MPCMM
DISCONNECT_REQ 	.STDRQ==6	.LNDRQ==^D16	.MPLOW		DISCONNECT_RSP
DISCONNECT_RSP	.STDRS==7	.LNDRS==^D12	.MPCMM
CREDIT_REQ	.STCRQ==10	.LNCRQ==^D12	.MPFLO		CREDIT_RSP
CREDIT_RSP	.STCRS==11	.LNCRS==^D12	.MPCMM
;Table K - receiving a message

Name		Code	Current 	Legal?	Response	New connection
			State					State

CONNECT_REQ	0	Closed		Y	CONNECT_RSP NM
			Listening	Y	CONNECT_RSP	connect_received
			Connect_sent
			Connect_rec
			Connect_ACK
			Open
			Accept_sent
			Reject_sent
			Disconnect_sent
			Disconnect_rec
			Disconnect_ACK
			Disconnect_match



Name		Code	Current 	Legal?	Response	New connection
			State					State

CONNECT_RSP	1	Closed
			Listening
			Connect_sent
			  success	Y	-		Connect_ACK
			  failure	Y	-		Closed
			Connect_rec
			Connect_ACK
			Open
			Accept_sent
			Reject_sent
			Disconnect_sent
			Disconnect_rec
			Disconnect_ACK
			Disconnect_match

* * * Old code set state to "closed no match" if failure
Name		Code	Current 	Legal?	Response	New connection
			State					State

ACCEPT_REQ	2	Closed		Y	ACCEPT_RSP NM	closed
			Listening
			Connect_sent
			Connect_rec
			Connect_ACK	Y	ACCEPT_RSP	Open
			Open
			Accept_sent
			Reject_sent
			Disconnect_sent
			Disconnect_rec
			Disconnect_ACK
			Disconnect_match

* * * * Old code closed v.c. if state was closed; required block state
of connect_pend, too



Name		Code	Current 	Legal?	Response	New connection
			State					State

ACCEPT_RSP			Closed
			Listening
			Connect_sent
			Connect_rec
			Connect_ACK
			Open
			Accept_sent
			  Match		Y	-		Open
			  No match	Y	-		closed
			Reject_sent
			Disconnect_sent
			Disconnect_rec
			Disconnect_ACK
			Disconnect_match

* * * * Old code expected state to be connect_received; set new state
to closed; required block state of accept_pend
Name		Code	Current 	Legal?	Response	New connection
			State					State

REJECT_REQ		Closed
			Listening
			Connect_sent
			Connect_rec
			Connect_ACK	Y	REJECT_RSP	Closed
			Open
			Accept_sent
			Reject_sent
			Disconnect_sent
			Disconnect_rec
			Disconnect_ACK
			Disconnect_match


* * * Old code set new state to closed-rejected
* * * Why not treat "closed" as legal as in accept_request



Name		Code	Current 	Legal?	Response	New connection
			State					State

REJECT_RSP		Closed
			Listening
			Connect_sent
			Connect_rec
			Connect_ACK
			Open
			Accept_sent
			Reject_sent	Y	-		closed
			Disconnect_sent
			Disconnect_rec
			Disconnect_ACK
			Disconnect_match


* * * Old code expected state to be "listen"; left it as "listen"
Name		Code	Current 	Legal?	Response	New connection

DISCONNECT_REQ		Closed
			Listening
			Connect_sent
			Connect_rec
			Connect_ACK
			Open		Y	DISCONNECT_RSP	disconnect_received
			Accept_sent
			Reject_sent
			Disconnect_sent	Y	DISCONNECT_RSP	disconnect_match
			Disconnect_rec
			Disconnect_ACK	Y	DISCONNECT_RSP	closed
			Disconnect_match




Name		Code	Current 	Legal?	Response	New connection
			State					State

DISCONNECT_RSP		Closed
			Listening
			Connect_sent
			Connect_rec
			Connect_ACK
			Open
			Accept_sent
			Reject_sent
			Disconnect_sent	Y	-		Disconnect_ACK
			Disconnect_rec
			Disconnect_ACK
			Disconnect_match Y	-		closed


+---------------+
! d i g i t a l !   I N T E R O F F I C E  M E M O R A N D U M
+---------------+

TO:  Distribution
                                       DATE:  10 May 83

                                       FROM:  Clair Grant

                                       DEPT:  LCG Software
                                              Engineering

                                       LOC:   MRO1-2/L10

                                       EXT:   6877


SUBJ:  TOPS-20 Systems Communications Service Tester

This is a description of the SCSTST  project,  the  test  vehicle  for
TOPS-20's  implementation  of  the  corporate  Systems  Communications
Acrhitecture being used on the CI.  It is believed that such a  tester
is  a  necessity  for  the  ultimate  success of the project, not just
initial debug and release, but for  future  development,  maintenance,
and performance measurement.

Both  DECnet  and  ARPANET   have   testers,   DTR/DTS   and   TRAFIC,
respectively;  they have been invaluable in recent TOPS-20 development
efforts and the same need exists for SCS.
                                                                Page 2


1.0  PROJECT GOALS

The project goals for the TOPS-20 System Communication  Service  (SCS)
test package are to provide:

     1.  a comprehensive tester for the SCS% JSYS, the  SCA  protocol,
         and the CI device driver

     2.  a quick and reliable means of  determining  that  SCS  is  in
         working order

     3.  a tool for performance comparison between different  versions
         of TOPS-20

     4.  a command file which, when TAKEn by  SCSTST,  will  tell  the
         user that SCS is functioning properly




2.0  RESTRICTIONS/DEFICIENCIES

The SCS tester will have the following restrictions:

     1.  it will not test every invalid way in which the SCS% JSYS can
         be called but will do some fault insertion

     2.  it will be used between TOPS-20 systems only




3.0  FUTURE CONSIDERATIONS

Any developer working on the TOPS-20 SCS  implementation  should  view
the  tester  as  an  integral part of the product.  An SCS development
project should not be considered complete until the  tester  has  been
modified,  if  necessary,  and  run  to  verify  that  SCS  is working
properly.  For example, SCSTST will look for specific error returns in
certain situations;  if someone changes the way the monitor handles an
error condition it must be verified that SCSTST is  not  effected,  or
SCSTST must be modified to handle the new situation.

Also, the design of the SCS tester could be used  by  other  operating
systems  to  provide  a  model  by which inter-system testing could be
done, e.g., DECnet's DTR/DTS.



4.0  GENERAL DESIGN

There will be 1 source file SCSTST.MAC.  It will use the  CMD  package
to  implement  the  command interface;  all functions of the SCS% JSYS
will be used.  SCSTST can be run in  either  "server"  or  "initiator"
mode.   Server  mode responds to incoming test requests, and initiator
                                                                Page 3


mode generates test requests.

SCSTST creates a multi-forking  environment.   The  top  fork  is  the
command   processor;    it   creates   test   streams  (sub-forks)  as
necessitated by the user's command selection.   Also,  a  sub-fork  is
created  which  performs the logging function.  As tests run, they log
information into a buffer which is periodically emptied to a  file  by
the logging fork.

In server mode, it starts  a  sub-fork  and  opens  an  SCS  listener;
whenever  an  incoming  connection  arrives,  that  fork processes the
connection attempt (and subsequent test messages) and another sub-fork
is established as the listener.  When a test finishes, the sub-fork is
killed.  Thus, multiple tests can  be  directed  at  a  single  node's
server  as  long  as  the  maximum  number  of  sub-forks has not been
exceeded.  Likewise, in initiator mode, SCSTST creates a sub-fork  for
each  test called for by the user.  When a test finishes, the sub-fork
is killed.  The user can create multiple tests, possibly to  different
nodes,  simultaneously, as long as the maximum number of sub-forks has
not been exceeded.



5.0  RECORDING OF RESULTS

An entry will be made in a log file for each incoming test request and
its  results.   Counters  will  be maintained by the program and their
values will be entered, as appropriate, in the log.

There will also be a trace  mode.   It  will  provide  a  blow-by-blow
account of each SCS% function performed and the results.  Logging must
be enabled for tracing to occur.



6.0  SCS% FUNCTION TESTING

SCSTST will use the SCS% options in the following tests:

.SSCON          all tests

.SSLIS          declaring SCSTST as the server

.SSACC          all tests except REJECT

.SSREJ          REJECT test

.SSDIS          all tests except REJECT

.SSSDG          DATAGRAM test

.SSQRD          DATAGRAM test

.SSSMG          MESSAGE test
                                                                Page 4


.SSQRM          MESSAGE test

.SSCRD          DATAGRAM test

.SSCRM          MESSAGE test

.SSCSP          IDLE test

.SSRCD          SCSTST initialization, all tests

.SSSTS          IDLE, DATAGRAM, MESSAGE, and DMA tests

.SSRMG          MESSAGE test

.SSRDG          DATAGRAM test

.SSGDE          DMA test

.SSEVT          all tests

.SSMAP          DMA test

.SSUMP          DMA test

.SSSND          DMA test

.SSREQ          DMA test

.SSRPC          all tests

.SSAIC          SCSTST initialization, all tests



7.0  USER INTERFACE

This section defines the command language of SCSTST.



7.1  DECLARE

The DECLARE command has  2  options  -  initiator  and  server;   this
establishes  SCSTST  as  either  the initiator or the server.  You can
only run the program in 1 of the 2 modes;  also, you can't switch from
one mode to the other.  If you are running as an initiator and want to
be a server, you must restart the program.  Example:

SCSTST>DECLARE (SCSTST TO BE THE) INITIATOR
                                                                Page 5


7.2  DISABLE

The DISABLE command directs SCSTST to stop performing  some  function;
there are 2 options - logging and tracing.

SCSTST>DISABLE (TEST FEATURE) TRACING



7.3  ENABLE

The ENABLE command directs SCSTST to start performing  some  function;
there  are  2  options  -  logging  tracing.   When SCSTST is started,
tracing is off and logging goes to the TTY.  Example:

SCSTST>ENABLE (TEST FEATURE) LOGGING (OUTPUT TO) FOO.LOG



7.4  EXIT

The EXIT command returns the  user  to  TOPS-20  command  level.   The
program is continuable, with no change to test parameters.  Example:

SCSTST>EXIT (TO TOPS-20 COMMAND LEVEL)



7.5  HELP

The HELP command prints out text which describes the  general  use  of
the   program.    It  does  not  provide  specific  information  about
individual commands.  Example:

SCSTST>HELP (WITH SCSTST)



7.6  SHOW

The SHOW command displays the current status of SCSTST.   The  current
status  of  logging,  tracing,  and  all  test streams (including test
parameters) are shown.  The output  from  SHOW  always  for  to  TTY:.
Example:

SCSTST>SHOW (CURRENT TEST PARAMETERS)



7.7  STOP

The STOP command is use to ternminate a running test stream.  Example:

SCSTST>STOP (TEST #) 2
                                                                Page 6


7.8  TAKE

The TAKE command is used to execute SCSTST commands from a file.   The
default file is SCSTST.CMD.  Example;

SCSTST>TAKE (COMMANDS FROM) FOO.CMD



7.9  TEST

The TEST command defines the remote node and the test to be run.   The
test options are:

     1.  IDLE - the idle test causes the initiator to send  a  connect
         with  optional  data.   The  server  reads  the first byte of
         optional data, finds the idle code, verifies that the rest of
         the  optional data bytes are null, and accepts the connection
         supplying the same optional data it received in the  connect.
         When  the server is notified that it is ok to send, it simply
         goes  to  sleep,  periodically  waking  to  check  that   the
         connection  is  still  there.   Meanwhile,  the initiator was
         notified that its connection was accepted and checked for the
         optional data it sent in the connect.  It then goes to sleep,
         waking periodically to check that connection is still  there.
         The initiator sends a disconnect when the time period is up.

SCSTST>TEST (TO NODE) 3 (FEATURE) IDLE-CONNECTION (FOR TIME
PERIOD) 00:02:00

    2.  CONNECT - the connect test has 2  options,  with  and  without
        optinal   data.   The  "no  optional  data"  test  causes  the
        initiator to send a connect request  with  no  optional  data.
        The  server  reads  the  first  byte  of  optional data, finds
        nothing and verifies that the rest of the optional data  block
        is empty;  it then does an accept with no optional data.  When
        the server  is  notified  that  it  is  OK  to  send  on  this
        connection,   it   does   a   disconnect   with   reason  code
        connect-with-no-optional-data-ok.   Meanwhile,  the  initiator
        was  notified  that  its  connection  had  been  accepted, and
        checked for no optional data.  When the initiator receives the
        disconnect, it verifies the reason code.

        The "optional data"  test  causes  the  initiator  to  send  a
        connect  request  with  optional  data.   The server reads the
        first     byte     of     optional     data,     finds     the
        connect-no-optional-data  code  and  verifies that the rest of
        the  optional  data  block  has  a  program-specified  set  of
        characters;   it  then  does  an  accept  with  the  identical
        optional data it received in the connect.  When the server  is
        notified  that  it  is  OK  to send, it does a disconnect with
        reason code connect-with-no-optional-data-ok.  Meanwhile,  the
        initiator  was notified that its connection had been accepted,
        and checked for optional data matching what  it  sent  in  the
        connect.   When  the  initiator  receives  the  disconnect, it
                                                                Page 7


        verifies the reason code.

        Example:

SCSTST>TEST (TO NODE) 3 (FEATURE) CONNECT (WITH) NO-OPTIONAL-DATA 

    3.  REJECT - the reject test  has  2  options,  with  and  without
        reason  code.   The "reason code" test causes the initiator to
        send a connect request with optional data.  The  server  reads
        the   first   byte  of  optional  data,  finds  the  code  for
        reject-reason code, verifies that the  rest  of  the  optional
        data   is   null,   and   does   a  reject  with  reason  code
        reject-reason-ok.  When the initiator  is  notified  that  the
        connection attempt was rejected, it verifies the reason code.

        The "no reason code" test  causes  the  initiator  to  send  a
        connect  request  with  optional  data.   The server reads the
        first  byte   of   optional   data,   finds   the   code   for
        reject-no-reason,  verifies that the rest of the optional data
        is null, and does a reject with  no  reason  code.   When  the
        initiator   is   notified  that  the  connection  attempt  was
        rejected, it verifies that no reason code was returned.

        Example:

SCSTST>TEST (TO NODE) 3 (FEATURE) REJECT (WITH) REASON-CODE 

    4.  DISCONNECT - the disconnect  test  has  2  options,  with  and
        without  reason  code.   The  "reason  code"  test  causes the
        initiator to send a connect with optional  data.   The  server
        reads   the   first   byte   of   optional   data,  finds  the
        disconnect-reason code and  verifies  that  the  rest  of  the
        optional data block is empty;  it then does an accept with the
        identical optional data it received in the connect.  When  the
        server is notified that it is OK to send, it does a disconnect
        with  reason  code   disconnect-reason-ok.    Meanwhile,   the
        initiator  was notified that its connection had been accepted,
        and checked for optional data matching what was  sent  in  the
        connect.   When  the  initiator  receives  the  disconnect, it
        verifies the reason code.

        The "no reason code" test sends a connect with optional  data.
        The  server  reads  the first byte of optional data, finds the
        reject-no-reason code  and  verifies  that  the  rest  of  the
        optinal  data  is  null;   it  then  does  and accept with the
        optional data it received on the connect.  When the server  is
        notified  that  it  ok  to  send, it does a disconnect with no
        reason code.  Meanwhile, the initiator has been notified  that
        the  connect  was  accepted,  and  verifies the optional data.
        When the initiator receives the disconnect, it checks  for  no
        reason code.

        Example:

SCSTST>TEST (TO NODE) 3 (FEATURE) DISCONNECT (WITH) NO-REASON-CODE 
                                                                Page 8


    5.  DATAGRAM - the datagram test has  3  options:   a)  number  of
        bytes  per  datagram, b) duration of the test, and c) transfer
        mode.  The initiator sends a connect with optional data.   The
        server  reads  the  optional  data and finds the datagram-mode
        code and the  byte  count,  verifies  that  the  rest  of  the
        optional  data is null, and does and accept with optional data
        matching what it received in the connect.  When it is notified
        that  it  is  OK to send, it simply waits for the datagrams to
        arrive.  Meanwhile, the initiator has been notified  that  its
        connect  has  been  accepted,  verifies the optional data, and
        begins sending datagrams.  The server verifies  each  datagram
        (the byte pattern is predefined in the program) and returns it
        to the initiator who also verifies the byte pattern.  When the
        time period runs out the initiator sends a disconnect.

        Example:

SCSTST>TEST (TO NODE) 3 (FEATURE) DATAGRAMS (OF BYTE COUNT) 200 (FOR
TIME PERIOD) 00:02:00 (IN MODE) HIGH-DENSITY

    6.  MESSAGE - analogous to DATAGRAM

        Example:

SCSTST>TEST (TO NODE) 3 (FEATURE) MESSAGES (OF BYTE COUNT) 200 (FOR
TIME PERIOD) 00:02:00 (IN MODE) INDUSTRY-COMPATIBLE

    7.  DMA-TRANSFERS - analogous to DATAGRAM

        Example:

SCSTST>TEST (TO NODE) 3 (FEATURE) DMA-TRANSFERS (OF BUFFER SIZE) 50
(WITH BUFFER POOL OF) 10 (FOR TIME PERIOD) 00:02:00




7.10  WAIT

The WAIT command directs SCSTST to wait for all current  test  streams
to stop before executing the next SCSTST command.

SCSTST>WAIT (FOR ALL TESTS TO STOP)
                                                                Page 9


8.0  VERIFICATION COMMAND SET

The following command set should be used to verify that TOPS-20's  SCS
is  in  basic  working  order.  It assumes a 2 node configuration;  if
more nodes are available, a similar command set would  be  appropriate
for  each  node.   The  test  should  take  about 20 minutes to run to
completion.

DECLARE INITIATOR

!Part 1 - individual connection management tests
!
TEST 1 CONNECT NO-OPTIONAL-DATA
WAIT
TEST 1 CONNECT OPTIONAL DATA
WAIT
TEST 1 DISCONNECT NO-REASON
WAIT
TEST 1 DISCONNECT REASON
WAIT
TEST 1 REJECT NO-REASON
WAIT
TEST 1 REJECT REASON
WAIT
!
!Part 2 - simultaneous connection management tests
!
TEST 1 CONNECT NO-OPTIONAL-DATA
TEST 1 CONNECT OPTIONAL DATA
TEST 1 DISCONNECT NO-REASON
TEST 1 DISCONNECT REASON
TEST 1 REJECT NO-REASON
TEST 1 REJECT REASON
TEST 1 CONNECT NO-OPTIONAL-DATA
TEST 1 CONNECT OPTIONAL DATA
TEST 1 DISCONNECT NO-REASON
TEST 1 DISCONNECT REASON
TEST 1 REJECT NO-REASON
TEST 1 REJECT REASON
!
!Part 3 - individual data tests, 2 minutes each
!
TEST DATAGRAM 10 2 INDUSTRY-COMPATIBLE
WAIT
TEST 1 DAAGRAM 10 2 HIGH-DENSITY
WAIT
TEST 1 MESSAGE 10 2 INDUSTRY-COMPATIBLE
WAIT
TEST 1 MESSAGE 10 2 HIGH-DENSITY
WAIT
TEST 1 DMA-TRANSFERS 10 5 2
WAIT
!
!Part 4 - multiple datagram test, 1 minute each
!
                                                               Page 10


TEST 1 DATAGRAM 0 1 INDUSTRY-COMPATIBLE         ;an empty datagram
TEST 1 DATAGRAM 1 1 HIGH-DENSITY                ;a small datagram
TEST 1 DATAGRAM 200 1 INDUSTRY-COMPATIBLE       ;a medium datagram
TEST 1 DATAGRAM 604 1 HIGH-DENSITY              ;the biggest datagram
!
!Part 5 - multiple message test, 1 minute each
!
TEST 1 MESSAGE 0 1 INDUSTRY-COMPATIBLE          ;an empty message
TEST 1 MESSAGE 1 1 HIGH-DENSITY                 ;a small message
TEST 1 MESSAGE 50 1 INDUSTRY-COMPATIBLE         ;a medium message
TEST 1 MESSAGE 148 1 HIGH-DENSITY               ;the biggest message
!
!Part 6 - multiple DMA test, 1 minute each
!
TEST 1 DMA-TRANSFERS 0 3 1                      ;an empty transfers
TEST 1 DMA-TRANSFERS 1 3 1                      ;a small transfer
TEST 1 DMA-TRANSFERS 100 3 1                    ;a medium transfer
TEST 1 DMA-TRANSFERS 512 3 1                    ;the biggest transfer
!
!Part 7 - mixed data test, 5 minutes each
!
TEST 1 IDLE-CONNECTION
TEST 1 DATAGRAM 10 5 INDUSTRY-COMPATIBLE
TEST 1 DATAGRAM 10 5 HIGH-DENSITY
TEST 1 MESSAGE 10 5 INDUSTRY-COMPATIBLE
TEST 1 MESSAGE 10 5 HIGH-DENSITY
TEST 1 DMA-TRANSFERS 10 5 5

[END OF SCA-INFO.MEMOS]