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