top - download
⟦a5683b61e⟧ Wang Wps File
Length: 88375 (0x15937)
Types: Wang Wps File
Notes: PC/PDS/001 - ISSUE 2
Names: »6211A «
Derivation
└─⟦05b6108d7⟧ Bits:30006238 8" Wang WCS floppy, CR 0624A
└─ ⟦this⟧ »6211A «
WangText
…13……09……13……0d……13……02……12……0a……12……02……11……0b……11……02……10……08……10……0c……10…
…0f……0a……0f……01……0e……09……0e……0c……0e……00……0e……01……0e……05……86…1
…02… …02…
…02…
…02…PC/PDS/001
…02…851001…02……02…
PROTOCOL CONVERTER
PACKAGE DESIGN SPECIFICATION…02…ISSUE
1.2…02… PC
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1. GENERAL ....................................
1
1.1 PURPOSE AND SCOPE ........................
1
1.2 APPLICABLE DOCUMENTS .....................
2
1.3 TERMS AND ABBREVIATIONS ..................
3
1.3.1 Terms ................................
3
1.3.2 Abbreviations ........................
5
2. SUMMARY OF REQUIREMENTS ....................
7
2.1 SYSTEM DESCRIPTION .......................
7
2.1.1 System Overview.......................
7
2.1.2 Message Structure ....................
8
2.1.2.1 Message Type......................
8
2.1.2.2 Message Format ...................
9
2.1.2.3 Alphabet .........................
9
2.1.2.4 Message Length ...................
9
2.1.3 CAMPS/SCARS Message Fragmentation.....
10
2.1.3.1 Frame Structure ..................
10
2.1.4 CCIS Message Fragmentation ...........
12
2.1.4.1 Segment Structure ................
12
2.2 SYSTEM FUNCTIONS .........................
15
2.2.1 System Control .......................
15
2.2.2 Message Processing ...................
16
2.2.2.1 Transaction Flow .................
16
2.2.2.2 Transaction Acknowledgement ......
16
2.2.2.3 Transaction Precedence Handling ..
17
2.2.2.4 Transaction Sequence Control .....
17
2.2.2.5 Service Messages .................
17
2.2.2.6 Protocol Functions ...............
18
2.2.2.7 Message Control Field Conversion .
18
2.2.3 Initialization and Close Down ........
19
2.2.4 Error Detection and Error Handling ...
20
2.2.4.1 Unrecoverable Errors .............
20
2.2.4.2 Frame Transmission Errors ........
21
2.2.4.3 Message Control Errors ...........
21
2.2.5 Recovery .............................
23
2.2.6 Statistics ...........................
23
2.2.7 Security .............................
24
2.3 CHARACTERISTICS ..........................
24
2.3.1 Timing ...............................
25
2.3.2 Throughput ...........................
25
2.3.3 Flexibility ..........................
26
3. ENVIRONMENT.................................
26
3.1 EQUIPMENT ................................
26
3.2 SYSTEM SOFTWARE ..........................
30
3.3 ELECTRICAL INTERFACES ....................
30
3.3.1 CCITT V24/PC Pin Connections .........
31
3.3.2 PC to END-SYSTEMS I/F ................
32
4. SOFTWARE SYSTEM DESIGN .....................
36
4.1 SOFTWARE SYSTEM DESCRIPTION ..............
36
4.1.1 Functional Overview ..................
36
4.1.2 Software Structure ...................
39
4.1.2.1 Software Packages ................
39
4.1.2.2 Software Package Interfacing .....
41
4.1.3 Data Flow and Control Logic ..........
43
4.1.3.1 Data Flow ........................
43
4.1.3.2 Control Logic ....................
46
4.1.4 Common Data ..........................
47
4.1.4.1 Data Overview ....................
47
4.1.4.2 Data Declarations ................
49
4.1.5 Interfaces ...........................
50
4.1.5.1 Operator Interface ...............
52
4.1.5.2 TRC Interface ....................
52
4.1.5.2.1 Functional Specification .....
53
4.1.5.2.2 Interface Declarations .......
55
4.1.5.3 PA Interface .....................
56
4.1.5.3.1 Functional Specification .....
56
4.1.5.3.2 Interface Declarations .......
59
4.1.5.4 CSLP Interface ...................
61
4.1.5.4.1 Functional Specification .....
61
4.1.5.4.2 Interface Declarations .......
62
4.1.5.5 CLP Interface ....................
62
4.1.5.5.1 Functional Specification .....
62
4.1.5.5.2 Interface Declarations .......
65
4.2 PACKAGE SPECIFICATIONS ...................
67
4.2.1 Command Interpreter (CI) .............
67
4.2.1.1 Functional Specification .........
67
4.2.1.2 Software Structure ...............
72
4.2.1.3 Package Data .....................
74
4.2.1.3.1 Command Interpreter Data .....
74
4.2.1.3.2 VDU Driver Data ..............
80
4.2.1.4 Package Design ...................
81
4.2.1.4.1 Command Interpreter
Pseudo Code ..................
81
4.2.1.4.2 VDU Driver Pseudo Code .......
95
4.2.1.5 Package Interfaces ............... 102
4.2.2 Traffic Controller (TRC) ............. 103
4.2.2.1 Functional Specification ......... 103
4.2.2.1.1 Line Control ................. 103
4.2.2.1.2 Transfer Control ............. 104
4.2.2.1.3 Test Control ................. 112
4.2.2.2 Software Structure ............... 113
4.2.2.3 Package Data ..................... 116
4.2.2.4 Package Design ................... 119
4.2.2.5 Package Interfaces ............... 119
4.2.3 CAMPS/SCARS Protocol Adapter (CSPA) .. 120
4.2.3.1 Functional Specification ......... 120
4.2.3.1.1 Transfer of Blocks ........... 120
4.2.3.1.2 Framing and Control .......... 123
4.2.3.2 Software Structure ............... 125
4.2.3.3 Package Data ..................... 127
4.2.3.4 Package Design ................... 131
4.2.3.5 Package Interfaces ............... 131
4.2.4 CAMPS/SCARS Low Level Protocols (CSLP) 131
4.2.5 CCIS Protocol Adapter (CPA) .......... 132
4.2.5.1 Functional Specification ......... 132
4.2.5.1.1 Transfer of Blocks ........... 132
4.2.5.1.2 Segmentation and Control ..... 137
4.2.5.1.3 DINDAC Service Messages ...... 139
4.2.5.2 Software Structure ............... 145
4.2.5.3 Package Data ..................... 147
4.2.5.4 Package Design ................... 152
4.2.5.5 Package Interfaces ............... 152
4.2.6 CCIS Low Level Protocols (CLP) ....... 153
4.2.6.1 Functional Specification ......... 153
4.2.6.1.1 OPEN LINK Sequence ........... 159
4.2.6.1.2 DATA TRANSMISSION Sequence ... 164
4.2.6.1.3 CCIS Simulation Sequence ..... 174
4.2.6.2 Software Structure ............... 175
4.2.6.3 Package Data ..................... 177
4.2.6 4 Package Design ................... 186
4.2.6.4.1 Protocol Entry Pseudo Code ... 186
4.2.6.4.2 Event Analyzer Pseudo Code ... 190
4.2.6.4.3 Send CLP Message Pseudo Code . 202
4.2.6.5 Package Interfaces ............... 203
4.2.7 Maintenance Controller (MAC) ......... 205
4.2.7.1 Functional Specification ......... 205
4.2.7.1.1 CPU-SCM Test ................. 206
4.2.7.1.2 EPROM Test ................... 206
4.2.7.1.3 RAM Test ..................... 206
4.2.7.1.4 LTU Test ..................... 207
4.2.7.1.5 Dump ......................... 207
4.2.7.2 Software Structure ............... 207
4.2.7.3 Package Data ..................... 209
4.2.7.4 Package Design ................... 213
4.2.7.4.1 MAC Mainprogram Pseudo Code .. 213
4.2.7.4.2 Read Command Pseudo Code ..... 214
4.2.7.4.3 Read Char VDU Pseudo Code .... 217
4.2.7.4.4 Write Char VDU Pseudo Code ... 218
4.2.7.4.5 Write Line VDU Pseudo Code ... 219
4.2.7.4.6 Analyze Command Pseudo Code .. 220
4.2.7.4.7 Read Parameters Pseudo Code .. 222
4.2.7.4.8 Perform Function Pseudo Code . 223
4.2.7.4.9 Check CPU Pseudo Code ........ 225
4.2.7.4.10 Check EPROM Pseudo Code .... 226
4.2.7.4.11 Check RAM Pseudo Code ...... 227
4.2.7.4.12 Check LTU Pseudo Code ...... 229
4.2.7.4.13 Dump RAM Pseudo Code ....... 231
4.2.7.4.14 Write Result VDU Pseudo Code 233
4.2.7.5 Package Interfaces ............... 234
4.2.8 System Generator and Initialiser (SGI) 234
4.2.8.1 Functional Specification ......... 234
4.2.8.1.1 AMOS Startup ................. 234
4.2.8.1.2 Implementation of SGI Tasks .. 235
4.2.8.2 Package Data ..................... 235
A̲P̲P̲E̲N̲D̲I̲X̲ ̲1̲:
Traffic Controller (TRC) Package Design
A̲P̲P̲E̲N̲D̲I̲X̲ ̲2̲:
CAMPS/SCARS Protocol Adapter (CSPA)
Package Design
A̲P̲P̲E̲N̲D̲I̲X̲ ̲3̲:
CCIS Protocol Adapter (CPA)
Package Design
1̲ ̲ ̲G̲E̲N̲E̲R̲A̲L̲
This chapter describes the general information applicable
to this document. Purpose, scope, document references,
terms and abbreviations are defined.
1.1 P̲U̲R̲P̲O̲S̲E̲ ̲A̲N̲D̲ ̲S̲C̲O̲P̲E̲
a) P̲u̲r̲p̲o̲s̲e̲
The Package Design Specification for the Protocol Converter
(PC) is written to fulfil the following objectives:
To provide the detailed design of the application software
to be developed. Software packages are described to
a level sufficient for coding.
To provide user operational and development personnel
details of the ongoing analysis.
b) S̲c̲o̲p̲e̲
This Package Design Specification is based on the PC
System Specification (Reference 17) and constitutes
the detailed software design on which programming will
be based.
The Package Design Specification covers the application
software to be developed.
Chapter 2 contains a summary of the functional system
requirements. Chapter 3 is an overview of the environment
of the application software. Chapter 4 constitutes
the application software design. Section 4.1 provides
an overview of the total application software system.
Section 4.2 contains the design specifications for
the individual packages.
1.2 A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲
1. Protocol Converter contract SHNMO-82-9205-INF.
1982-04-29.
2. System Requirement Specification (SRS).
Appendix G of Reference 1. 1982-04-29.
3. SCARS II System Design Baseline Vol III A
Rev A and B and C and D
1981-06-30, 1981-07-15, 1982-04-28, 1982-10-15
Burroughs.
or
CPS/ICD/006, 1982-05-18 Christian Rovsing A/S.
4. Functional Description for the SCARS, CAMPS, ACCIS
interface. 1981-02-05. As appendix E to Reference
3.
5. Remote Terminal Supervisor (GRTS).
Honeywell DD40B rev. 0, July 1976.
6. DINDAC CCTC TR-01, 1978-06-30.
7. ACE Security Directive 70-1.
1979-08-31 with change 2 dated 1981-02-06.
8. ACE ADP Standards Manual 96-1-1, part no. 007-3
1980-01-14.
9. AMSG 720A. January 1977.
10. AMSG 719B. September 1976.
11. AQAP 1 and 13.
12 MIL-STD188C. 1969-11-24
13 WWMCCS ADP Telecom Standard Engineering Practices,
DCA November 1979.
(p. 6-01 to 6-09, 10-18 to 10-19, 10-92 to 10-108).
14. Control wires and functions for WWMCCS-PC link
(delivery by SHAPE on or before 3.May 1982).
15. X25 LAP (CAMPS) Product Specification.
CSS-MIC/0422/PSP/1027. 1982-05-28. Chr. Rovsing
A/S.
16. DINDAC Interface Parameter document.
Telex camps log: 631, pc : 002. SHAPE 14 May 1982
17. Protocol Converter System Specification
PC/SDS/001. Issue 2.1, 1982-08-10. Chr. Rovsing
A/S.
18. DINDAC-RCI Protocol Notes. 1982-07-26.
Handout from SHAPE/Novell.
1.3 T̲E̲R̲M̲S̲ ̲A̲N̲D̲ ̲A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
This section defines the terms and abbreviations to
be used in this document.
1.3.1 T̲e̲r̲m̲s̲
The following terms are defined:
E̲n̲d̲ s̲y̲s̲t̲e̲m̲ designates any of the three systems to which
PC is connected, i.e. CAMPS or SCARS II in one end
and CCIS in the other end.
F̲r̲a̲m̲e̲ designates the smallest logical unit of information
to be transferred on the physical link. A frame corresponds
to what is called a subsegment in DINDAC terminology
(cf. Reference 6).
S̲e̲g̲m̲e̲n̲t̲ means the smallest logical unit of information
sent from DINDAC to the GRTS and vice versa. A segment
consists of up to 1140 bytes.
S̲u̲b̲s̲e̲g̲m̲e̲n̲t̲, the smallest logical unit of information
transferred between the CR80 LTU and the DN355/6678.
A subsegment contains up to 324 bytes of data.
OP1.(x:y) A y-bit field with the leftmost bit equal
to bit x taken from the bit sequence OP1
with the rightmost LSB equal to bit 0
OP1&OP2
(x:y:z) A z-bit field from OP2 with the leftmost
bit being bit y is inserted in OP1 with
the leftmost bit inserted as bit x. The
remaining 16-z bits of OP1 are unchanged.
1.3.2 A̲b̲b̲r̲e̲v̲i̲a̲t̲i̲o̲n̲s̲
The following abbreviations are used:
ACCIS Automated Command and Control Information
System
ACE Allied Commands Europe
ACK Acknowledgement
ADP Automated Data Processing
ADTX Action X in Data Transmission Sequence
AMOS Advanced Multiprocessor Operating System
AOLX Action X in Open Link Sequence
CAMPS Computer Aided Message Processing System
CCIS Command and Control Information System
CDRX Control Message X sent from GRTS
CI Command Interpreter
CHAR NATO 7-bit character
CLP CCIS Low Level Protocols
CLS Message Classification
CPA CCIS Protocol Adapter
CR Christian Rovsing A/S
CR80 CR80 minicomputer (Christian Rovsing)
CRDX Control Message X sent from CLP
CSA Cpu Scm Adapter
CSLP CAMPS/SCARS Low Level Protocols
CSPA CAMPS/SCARS Protocol Adapter
DCE Data Circuit-terminating Equipment
DT Data Transmission Sequence
DTE Data Terminal Equipment
DINDAC auto-DIN-wwmccs Direct Access Communications
module
DN355 Honeywell front-end processor
DN6678 DN355 compatible front-end processor
EDTX Event X in Data Transmission Sequence
EOLX Event X in Open Link Sequence
EOM End of Message
EPROM Erasable Programmable Read-only Memory
GRTS/355 General Remote Terminal Supervisor of DN
355
I/F Interface
ICD Interface Control Document
IDRX Information Message X sent from GRTS
IRDX Information Message X sent from CLP
IVSN Initial Voice Switched Network
LIA-N Line Interface Adapter Non switching
LSB Least Significant Bit
LTU Line Terminating Unit
MAC Maintenance Controller
NA Not Applicable
NAK Negative Acknowledgement
NUM Binary Value
PC Protocol Converter
PDL Program Design Language
PIP Project Implementation Plan
PROM Programmable Read-only Memory
QA Quality Assurance
RAM Random Access Memory
RCI Remote Computer Interface (to Honeywell)
RSPL Recommended Spare Parts List
R&M Reliability and Maintainability
SCARS Status and Control Alerting and Reporting
System
SCI Station Channel Identifier
SCM System Control Module
SDRX Service Message X sent from GRTS
SDTX State X in Data Transmission Sequence
SGI System Generator and Initializer
SHAPE Supreme Headquarters Allied Powers Europe
SOLX State X in Open Link Sequence
SRDX Service Message X sent from CLP
SUSDUP Suspected Duplicate
SRS System Requirement Specification
SWELL Software Engineering Low Level Language
TBD To Be Defined
TBS To Be Specified
TSN Transmission Serial Number
TRC Traffic Controller
VDU Visual Display Unit
WWMCCS World Wide Military Command and Control
System
2̲ ̲ ̲S̲U̲M̲M̲A̲R̲Y̲ ̲O̲F̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
This chapter summerizes the software requirements to
PC.
2.1 S̲Y̲S̲T̲E̲M̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
In this section the system and its relations to interfacing
systems are outlined. Formats of the data exchanged
between the systems are described in section 2.1.2.
2.1.1 S̲y̲s̲t̲e̲m̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
The three systems interfacing to the protocol converter
are:
a) CAMPS implemented on CR80 equipment
b) SCARS II implemented on Burroughs equipment
c) CCIS implemented on Honeywell equipment
Transactions are required to be exchanged between any
two of these system.
CAMPS and SCARS II interfaces to the external environment
in the same way based upon an X25 protocol as described
in Reference 3. These two systems can therefore be
interlinked directly without involving the PC.
CCIS as implemented on a Honeywell 6000 configuration
with a DN 355 or a DN 6678 front and network processor
interfaces to the external environment through the
DINDAC and RCI protocols as described in Reference
6 and Reference 5. These protocols are incompatible
with the ones used by CAMPS and SCARS II.
The objective of the protocol converter is thus to
provide a facility to support automated exchange of
transactions between CAMPS or SCARS II on one side
and CCIS on the other side.
This objective is accomplished by connecting each end
system to the converter which shall compensate for
differences in protocols in a way that allows the end
system to operate as if transactions were exchanged
with a matching system.
The relationship between PC and environment is shown
in Figure 2.1.1-1
---------- ---------- ----------
'CAMPS or' ' PC ' ' CCIS '
'SCARS II'----------' '----------' '
' ' ' ' ' '
---------- ---------- ----------
FIGURE 2.1.1-1 SYSTEM CONNECTIVITY
PC and the end systems are collocated and physically
connected by direct cabling. The charaterictics of
the physical interfaces are described in section 3.3.
2.1.2 M̲e̲s̲s̲a̲g̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
In the following the structure and characteristics
of the messages exchanged between the end systems and
passing through PC are described
2.1.2.1 M̲e̲s̲s̲a̲g̲e̲ ̲T̲y̲p̲e̲
The transactions exchanged between the end systems
are of four types:
a) Narrative messages
b) Data messages
c) VDU displays
d) Comments
Furthermore the following service messages may be exchanged
between CCIS, PC and CAMPS/SCARS II:
e) Transaction acknowledgement messages
f) Channel check messages
g) Final number messages
Note that transaction acknowledgement message is not
sent from CCIS through PC to CAMPS/SCARSII.
2.1.2.2 M̲e̲s̲s̲a̲g̲e̲ ̲F̲o̲r̲m̲a̲t̲
All messages except transaction acknowledgements are
transmitted and received in E1 format as defined in
appendix A of Reference 3.
The E1 format divides a message into three parts:
a) header with varying content dependent on message
type.
The following attributes are always present:
1) Station Channel Identifier (SCI)
2) Transmission Serial Number (TSN)
3) Message Classification (CLS)
4) Message Precedence (PRC)
Classification levels are:
U: Unclassified
R: Restricted
C: Confidential
S: Secret
T: Cosmic Top Secret
b) Text containing the information to be communicated.
c) Trailer indicating end-of-message.
2.1.2.3 A̲l̲p̲h̲a̲b̲e̲t̲
All messages passing the protocol converter are coded
in the NATO-7-bit alphabet. This alphabet is defined
on page 3-A-4-2 of Reference 3.
2.1.2.4 M̲e̲s̲s̲a̲g̲e̲ ̲L̲e̲n̲g̲t̲h̲
The length of a message is limited to a maximum value
which depends on the transaction type as follows.
a) Data and narrative messages contain a maximum
of 12000 characters E1 header and trailer included.
Narrative messages contain a maximum of 69
characters per line of text (excluded the line
delimiting characters).
Data messages have no limit on line length.
b) Displays and comments contain a maximum of
20 lines of text E1 header and trailer excluded.
Each line contains a maximum of 80 characters
per line.
2.1.3 C̲A̲M̲P̲S̲/̲S̲C̲A̲R̲S̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲F̲r̲a̲g̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
Here the fragmentation of messages between PC and CAMPS/SCARS
II is described.
Messages are divided into consecutive blocks of information
for transfer on the link. To these blocks are added
control information by the protocol layers. A data
block with control information is called an information
frame and is described in the following.
2.1.3.1 F̲r̲a̲m̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
An information frame is composed of the following components:
HEADER
Flag sequence 1 byte
Address 1 byte
Control 1 byte
INFORMATION FIELD
Line control field 2 bytes
Message control field 6 bytes
Text 1..120 bytes
TRAILER
Frame check sequence 2 bytes
Flag sequence 1 byte
Line control field is not used (ignored when received
by PC, set to binary 0 when transmitted by PC).
Text field is 120 bytes except for last frame and single
frame transaction, where text is 1..120 bytes.
The contents of the message control field is described
in the following Figure 2.1.3.1-1
DESCRIPTION BYTES TYPE VALUE
-----------------------------------------------------
IFL - Information Field Length 1 num 9..128
Number of bytes contained in the
INFORMATION FIELD(see 2.1.3.1)
of a frame.
BSN - Block Sequence Number 1 num 1..100
Numeric value indicating the
position of this block within the
message.
Spare 1
Not used
BTY - Block Type 1 char
Defines the following conditions:
SOM - Start of message block A
MID - Mid message block B
EOM - End of message block C
SOM-EOM - Single block message D
PRC - Message precedence 1 char
Legal value are:
Flash override and superflash 1
Flash 2
Immediate 3
Superpriority 4
Priority 5
Routine 6
TYP - Message type 1 char
Legal value are:
Display in E1 C
Comment in E1 D
Transaction acknowledgement E
Channel check message F
Final number message G
Narrative message in E1 M
Data message in E1 N
Susdup display in E1 O
Susdup comment in E1 P
Susdup narrative message in E1 Q
Susdup data message in E1 R
------------------------------------------------------
FIGURE 2.1.3.1-1 CAMPS/SCARSII MESSAGE CONTROL FIELD
------------------------------------------------------
2.1.4 C̲C̲I̲S̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲F̲r̲a̲g̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
Here the fragmentation of messages between PC and CCIS
is described.
Messages are blocked in two levels.
Each message is divided into one or more segments with
added control information.
Each segment is divided into one or more frames (called
subsegments in Reference 6) with added control information
and described in section 4.2.6.1.
2.1.4.1 S̲e̲g̲m̲e̲n̲t̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
A message segment is composed as follows:
SEGMENT HEADER 34 bytes
DATA 1..1106 bytes
The content of the segment header is shown in following
Figure 2.1.4.1-1.
DESCRIPTION BYTES TYPE VALUE
------------------------------------------------------
CDN - Channel Designator 3 char
Three letter code identification
The value is a constant identifying
the sending station.
CSN - Channel Sequence Number 3 char 000-999
Message sequence number increased
by 1 for each transaction transmitted
(wrap around to 0)
SEG - Message segment number 2 char 01-99
Indicates the relative position of
this segment within the message.
END - Last segment indicator 1 char
Legal values are:
EOM - End of message segment T
Non-EOM '
'
PRC - Message precedence 1 char
Legal values are:
Emergency Y
Flash Z
Immediate O
Priority P
Routine R
CLS - Message classification 1 char
Legal values are:
Cosmic Top Secret T
Secret S
Confidential C
Restricted R
Unclassified U
TYP - Message type 1 char
Legal values are:
Display in E1 C
Comment in E1 D
Transaction acknowledgement E
Channel check message F
Final number message G
Narrative message in E1 M
Data message in E1 N
Susdup display in E1 O
Susdup comment in E1 P
Susdup narrative message in E1 Q
Susdup data message in E1 R
KEY - Program keyword 8 char
Identifies the application
to communicate with.
Legal values are:
in operational mode 'PCTHDL
'
in test mode 'KEN
'
SUB - Message subject code 2 char
Legal values are:
in operational mode 'AA'
in test mode 'QQ'
PRN - Precedence of next message 1 char
in transmission queue.
Legal values are:
Emergency 5
Flash 4
Immediate 3
Priority 2
Routine 1
No message to transmit 0
Unused 1
PSN - Internal processing sequence 6 char
number.
SIZ - Length of segment 4 char 0035-
1140
--------------------------------------------------------
FIGURE 2.1.4.1-1 DINDAC SEGMENT HEADER
--------------------------------------------------------
2.2 S̲Y̲S̲T̲E̲M̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲S̲
2.2.1 S̲y̲s̲t̲e̲m̲ ̲C̲o̲n̲t̲r̲o̲l̲
The system will be controlled by operator interaction.
Commands and responses are communicated via a VDU screen
and keyboard. The VDU to system interface will operate
with speed up to 9600 baud. The VDU will not be required
once the system is brought into normal operation and
may therefore be shared among several converters.
The system will be controllable at various levels called
modes, each mode providing specific control facilities.
The following modes will be implemented:
a) M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲m̲o̲d̲e̲
Provides for basic test and analysis at a low level
(hardware module tests, memory dump).
b) L̲o̲c̲a̲l̲ ̲m̲o̲d̲e̲
Reflects the state where the system is initialised
but still offline. A logon command from the operator
will initiate the sequence to bring the system
online.
c) O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲ ̲m̲o̲d̲e̲
The system is online i.e. end systems are connected
and transactions may be exchanged.
d) T̲e̲s̲t̲ ̲m̲o̲d̲e̲
The system is online but not in normal operation.
Provides for individual test of the links PC-CAMPS/SCARS
II and PC-CCIS by transmitting and receiving test
messages prestored in PC.
2.2.2 M̲e̲s̲s̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
The requirements to the message processing capability
of PC is summarised in this section.
2.2.2.1 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲F̲l̲o̲w̲
With the system online transactions may arrive from
end systems to PC simultaneously. PC will therefore
be prepared to handle two transactions, one from each
side at a time. Since the PC-CCIS link is halfduplex
this implies that PC may have to store a transaction
coming in from CAMPS/SCARS until the CCIS link is available.
PC will therefore be designed to have the capacity
for storing two complete transactions, one for each
direction.
2.2.2.2 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲A̲c̲k̲n̲o̲w̲l̲e̲d̲g̲e̲m̲e̲n̲t̲
Transactions will be acknowledged by end systems. PC
will never generate and send transaction acknowledgement,
as this is a responsibility of the receiving end system.
When PC has passed a transaction the receiver shall
send a transaction acknowledgement in accordance with
its protocol.
CAMPS/SCARS will acknowledge by transmitting a transaction
acknowledgement service message from its level 4 protocol.
This transaction acknowledgement service message is
passed on by PC unmodified and handled by DINDAC as
a normal transaction. When the CCIS application has
received the transaction acknowledgement service message
the next transaction may be submitted for transmission.
CCIS will acknowledge by letting the SUPER-ACK service
message generated by its DINDAC protocol act as the
final transaction acknowledgement. This SUPER-ACK is
by PC converted to a CAMPS/SCARS transaction acknowledgement
service message (this requires that PC saves the TSN
number of the transaction being acknowledged) and sent
to CAMPS/SCARS. The reason for not letting the CCIS
application generate the CAMPS/SCARS transaction service
message and pass this transparently through DINDAC
and PC is not to violate the timeout on transaction
acknowledgement applied in
CAMPS/SCARS.
2.2.2.3 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲P̲r̲e̲c̲e̲d̲e̲n̲c̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
As mentioned under transaction flow, a transaction
from CAMPS/SCARS will be stored in PC if the CCIS-PC
link is not available due to incoming transaction from
CCIS.
PC will assure the CAMPS/SCARS transaction to get through
to CCIS in the following way:
a) If the CAMPS/SCARS transaction is of precedence
Flash ̲override /superflash or Flash and the incoming
CCIS transaction is of lower precedence, then PC
will apply the override facility of the CCIS protocol
to stop reception of the incoming CCIS transaction
and start transmission of the CAMPS/SCARS transaction.
Note that the override can only be done after a
complete segment has been received, which is why
one-segment transactions (size up to 1140 bytes)
can not be overridden.
b) If a) does not apply (i.e. no override) PC receives
the complete transaction from CCIS, sends the SUPER-ACK/SUPER-NAK
with the 'next ̲to ̲transmit' field set to PC. PC
starts transmission of the waiting transaction
from CAMPS/SCARS when the 'transmit ̲data' request
is received from CCIS.
On the reception of the transaction acknowledgement
service message from CAMPS/SCARS the following
is done: the PRN field of the outgoing transaction
will contain the precedence of the transaction
acknowledgement on queue in PC.
2.2.2.4 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲S̲e̲q̲u̲e̲n̲c̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
a) It is the responsibility of the end systems to
run the transaction sequence control as the transaction
sequence number (TSN) is part of the E1 format.
b) However, since the DINDAC level runs a separate
transaction sequence control based on the channel
sequence number (CSN) of the segment header, PC
will handle the CSN processing on the PC-CCIS link.
2.2.2.5 S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
Channel check and final number service messages will
be passed on transparently by PC. Transaction acknowledgement
service message sent from CAMPS/SCARS will also be
passed on to the CCIS end. A SUPER-ACK received from
CCIS (DINDAC) will on the other hand be
converted to a transaction acknowledgement service
message and sent to CAMPS/SCARS; CCIS shall therefore
not generate any further transaction acknowledgement,
however, the SUPER-ACK acknowledging a transaction
acknowledgement service message is not passed on towards
CAMPS or SCARS.
2.2.2.6 P̲r̲o̲t̲o̲c̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
a) PC will handle transactions to-from CAMPS/SCARS
in accordance with the level 1,2 and 3 protocols
of Reference 3. Message fragmentation will be as
defined in section 2.1.3.
b) PC will handle transactions to-from CCIS in accordance
with the level 1,2 and 3 (RCI Reference 5) and
that part of level 4 (DINDAC Reference 6) that
concerns validity check/generation of segment headers,
segment sequence control, transaction sequence
control and handling of DINDAC service messages.
Message fragmentation will be as defined in section
2.1.4.
The RCI facility for data compression will not be implemented,
in either direction.
c) PC will pass on the full E1 format unmodified.
It is a duty of both end systems to handle the
E1 formatting.
d) PC will check on the total length of a transaction.
This is further defined in section 4.2.2.1.2.
2.2.2.7 M̲e̲s̲s̲a̲g̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲i̲e̲l̲d̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲
Control information is contained in the DINDAC segment
header for messages to-from CCIS and in the Message
Control Field of level 3 frames for messages to-from
CAMPS/SCARS. There is not a one-to-one mapping between
these fields. How PC will supply the information required
is described here.
a) For CAMPS/SCARS to CCIS transmission PC will provide
the DINDAC segment header contents as follows (ref.
figure 2.1.4.1-1):
CDN is SCI of E1 format line B
CSN is generated by PC
SEG is generated by PC
END is generated by PC
PRC is converted from PRC of Figure 2.1.3.1-1
CLS is CLS of E1 format line C
TYP is TYP of Figure 2.1.3.1-1
KEY is 'PCTHDL '(operational mode) or 'KEN
'(test mode)
SUB is 'AA'(operational mode) or
'QQ'(test mode)
PRN is generated by PC
PSN is generated by PC
SIZ is generated by PC
b) For CCIS to CAMPS/SCARS transmission PC will provide
the Message Control Field contents as follows (cf.Figure
2.1.3.1-1)
IFL is generated by PC
BSN is generated by PC
BTY is generated by PC
PRC is converted from PRC of Figure 2.1.4.1-1
TYP is TYP of Figure 2.1.4.1-1
c) Predence (PRC) is converted as follows:
CAMPS/SCARS CCIS(DINDAC)
Flash override/superflash ---- Emergency
Flash ---- Flash
Immediate ---- Immediate
Superpriority ---- Priority
Priority ---- Priority
Routine ---- Routine
2.2.3 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲
a) I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
System initialisation requires operator interaction
via VDU.
Power-on will bring the system into maintenance mode.
An Init command from the operator will initialise the
system i.e. bring up the operating system, start up
the application processes and load the LTU's. The system
will then be in local mode still offline but ready
to receive a logon command.
A logon sequence from the operator will bring the system
online. The logon command will have the following parameters:
CCIS parameters:
- userid, password for logon to DINDAC, up to
12 characters each
- baud rate for outgoing line (2400, 4800 or
9600).
CAMPS/SCARS parameters:
- end system (CAMPS or SCARS)
PC will verify that transactions passing PC are
in
accordance with the end system specified
(SCI check)
- baud rate for outgoing line (2400, 4800 or
9600).
b) C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲ ̲(̲O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲ ̲M̲o̲d̲e̲)̲
Close down will bring the system from online to offline
local mode. The action performed when closing down
is to disconnect the links to the end systems.
Close down will be performed on occurrence of one of
the following events:
-Logoff command from operator
-Disconnect from one of the end systems
-Link failure on one of the two links
-Internal malfunctioning detected in PC.
2.2.4 E̲r̲r̲o̲r̲ ̲D̲e̲t̲e̲c̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
2.2.4.1 U̲n̲r̲e̲c̲o̲v̲e̲r̲a̲b̲l̲e̲ ̲E̲r̲r̲o̲r̲s̲
These are errors due to PC internal malfunctioning,
link failures, and failures of end systems. If PC detects
an unrecoverable error it will close down the system
as described in section 2.2.3. An error message will
be sent to the VDU.
If the VDU is not present, the error message is displayed
upon connection. This result line is followed by a
prompt on the VDU indicating LOCAL mode.
2.2.4.2 F̲r̲a̲m̲e̲ ̲T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲E̲r̲r̲o̲r̲s̲
These errors are detected by low level protocols as
frame check sequence error on CAMPS/SCARS side and
block check error on the CCIS side. The protocols in
question will perform recovery in terms of retransmission
requests on occurrence of these errors.
Error counters are available to operator applying the
show statistics command.
2.2.4.3 M̲e̲s̲s̲a̲g̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲E̲r̲r̲o̲r̲s̲
These are errors detected as inconsistence or invalidity
in content of the message control field of CAMPS/SCARS
level 3 frames and the segment header of CCIS segments.
Errors detected as excessive message length (too long
message error) are also included in this category.
Message control errors are detected and reported by
PC as shown in the following scenarios, but end systems
are responsible for recovery.
CCIS detects error in CCIS-to-CAMPS/SCARS transmission:
CCIS PC CAMPS/SCARS
…0c…$$…0c… BUST -
…0c…$$…0c… preempt -
…0c…$$…0c… - transaction
ack
…0c…$$…0c… - SUPER-NAK
PC detects error in CCIS-to-CAMPS/SCARS transmission:
CCIS PC CAMPS/SCARS
…0c…$$…0c… preempt -
…0c…$$…0c… - transaction
ack
…0c…$$…0c… - SUPER-NAK
Note: the transaction ack is not passed on to CCIS
CCIS detects error in CAMPS/SCARS-to-CCIS transmission:
CAMPS/SCARS PC CCIS
…0c…$$…0c… - SUPER-NAK
…0c…$$…0c… - accept and
discard
until EOM
no action
towards
CAMPS/SCARS
timeout
PC detects error in CAMPS/SCARS-to-CCIS transmission:
CAMPS/SCARS PC CCIS
…0c…$$…0c… - accept and
discard
until EOM.
…0c…$$…0c… BUST -
…0c…$$…0c… - SUPER-NAK
no action
towards
CAMPS/SCARS
timeout
The problem in CAMPS/SCARS-to-CCIS transmissions is
that there is no way of telling the sender that the
transmission went wrong. The only way is to suppress
the transaction acknowledgement, which implies that
the sender will wait until he times out.
Messages exceeding the total length limits are handled
as follows by PC:
a) For transmission towards CCIS the above procedure
for PC detected errors in CAMPS/SCARS-to-CCIS transmission
is followed.
b) For transmission towards CAMPS/SCARS the first
maximum length characters are transmitted followed
by the CAMPS/SCARS preemption sequence. The remaining
part is discarded by PC.
2.2.5 R̲e̲c̲o̲v̲e̲r̲y̲
Recovery due to errors detected in the message exchange
will be implemented on frame level. PC will implement
the recovery facility contained in the CAMPS/SCARS
level 2 protocol and the CCIS RCI protocol to ensure
error free transmission of frames.
Recovery of entire transactions will not be done by
PC, this being a responsibility of the end system.
Recovery on detection of software failures internal
to PC will not be done. On such occurences the system
will be closed down. The success of the close down
depends on the severity of the error.
2.2.6 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
PC will implement a facility for collecting statistics
concerning frame transmission/reception to/from both
end systems. The data collected for each side is the
number of:
- frames transmitted
- frames retransmitted
- error-free received frames
- frames received with error.
The statistics will be displayed on the VDU on demand
and a separate command for resetting the counters will
be implemented The counters are initialized to value
0 at system initialization. The counters are not reset
automatically by logon.
2.2.7 S̲e̲c̲u̲r̲i̲t̲y̲
The security requirement is covered by the following
facilities:
a) Internal buffer memory used to store a message
in transit will be cleared as soon as the message
has passed PC. Buffers will also be cleared
whenever a new mode is entered and when a preemption
occurs.
b) There will be no possibility of displaying
message content on the maintenance VDU. Neither
will it be possible to enter message text from
the VDU to be sent to the end systems. Logon
sequences will however be entered from VDU
and sent to end systems to bring the system
on line
c) Data in a transaction will not be lost due
to PC failures since transactions are acknowledged
by the end systems, and kept there until acknowledged.
d) All software reside in EPROM. The system does
not contain any removable storage units such
as disk packs.
e) The converter is enclosed in TEMPEST rack when
connected to the end systems. The VDU is the
type approved for CAMPS. The VDU is connected
to the converter by fiberoptic cable.
2.3 C̲H̲A̲R̲A̲C̲T̲E̲R̲I̲S̲T̲I̲C̲S̲
In the following subsections system characteristics
are covered in terms of timing, throughput and flexibility.
2.3.1 T̲i̲m̲i̲n̲g̲
a) The delay in message transfer due to processing
in the converter will be, in normal conditions,
less than one second. This time is defined as the
time elapsed between the last information frame
received by the converter and the last information
frame transmitted by the converter and from which
is deducted the transmission transfer time, the
link turn around time and the time that the frames
are buffered up in the Protocol Converter due to
unavailability of the halfduplex PC-CCIS link.
b) The response time for the keyboard operation will
be within 5 sec. on 95 percent of cases.
c) Initialization time shall not exceed 3 min including
operator actions but excluding time used for eventual
manual replacement of on-line converter by the
redundant off-line converter and patching VDU connection
to the converter in question.
2.3.2 T̲h̲r̲o̲u̲g̲h̲p̲u̲t̲
a) Message throughput is maximised by keeping the
delay caused by the protocol conversion as low
as possible. Thus incoming messages are not collected
and stored completely in the converter before transmitted
to the other end system. The system will allow
for a message to flow continuously through the
converter with parallel transmission and reception
of the same message. As soon as the converter has
received a portion of a message sufficient for
the outgoing protocol to handle, transmission will
start. The amount of message information to be
stored in the converter depends only on the protocols
of the end systems. It should be observed in this
connection that for transfer from CAMPS/SCARS to
CCIS PC will have to collect a whole segment (1140
bytes) since the PC generated segment header shall
contain information about length of segment and
whether more segments are to follow or not.
b) The converter will be able to support data transfer
between the end systems at up to 9600 baud line
speed.
2.3.3 F̲l̲e̲x̲i̲b̲i̲l̲i̲t̲y̲
The application software will be composed of functional
components with well defined interfaces between them.
The protocols functions will be isolated and there
will be no direct interaction between the protocols
of the CAMPS/SCARS side of the converter and the protocols
of the CCIS side. In this way future changes in protocols
may be implemented without having to modify the functionally
unaffected part of the system.
Since the software is located in EPROM, any modification
in software will, require regeneration of EPROM.
3̲ ̲ ̲E̲N̲V̲I̲R̲O̲N̲M̲E̲N̲T̲
Environment is understood as the environment of the
application software. Therefore, this chapter describes:
- equipment on which the PC is implemented
- system software used
- electrical interfaces towards end systems
3.1 E̲Q̲U̲I̲P̲M̲E̲N̲T̲
One PC Processor Unit utilizes the following hardware:
One CR80M CPU/SCM processor
One 64K EPROM memory unit
One 128K RAM memory unit
Two Line Terminating Units (LTUs).
One Visual Display Unit (VDU) for start up, test
and maintenance. The VDU is shared by several converters.
The converter configuration is outlined in Figure 3.1-1.
A list of CR80 hardware modules used for one converter
is given in Figure 3.1-2.
The individual hardware items are described in Reference
17, section 3.1.
FIGURE 3.1-1
CONVERTER CONFIGURATION
--------------------------------------------------------
' Quantity Module …02…CR no.
'
'------------------------------------------------------'
' 1 CPU-SCM, single bus CR8002M
'
' 1 128k W RAM CR8016M
'
' 1 64K W EPROM CR8013M
'
' 2 Synchronous LTU, 16k W CR8066M
'
' 2 Line I/F Adapter, LIA-N CR8082M
'
' 1 CPU-SCM Adapter, CSA CR8070M
'
' 1 Mini Crate, single bus CR8115M
'
' 2 V28 L/L adapter, 1 channel CR80110S
'
' 1 OPTO T/R adapter, OM-2 CR80108S
'
' 1 Adapter power supply CR1102S
'
' 1 Adapter Crate CR1104S
'
--------------------------------------------------------
FIGURE 3.1-2
CR80 EQUIPMENT FOR ONE PROTOCOL CONVERTER
3.2 S̲Y̲S̲T̲E̲M̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲
Distinction is made between application software, system
software and development support software. Application
software is the subject of this document. System software
consists of the operating system and drivers providing
input/output facilities.
The components of system software to be used are listed
in the following.
The system software components used are:
AMOS, Advanced Multiprocessing Operating System
LTU drivers
3.3 E̲L̲E̲C̲T̲R̲I̲C̲A̲L̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲S̲
This section describes the electrical interfaces between
PC and the three end-systems CAMPS, SCARSII, and CCIS.
Applicable I/F control documents are:
CAMPS/PC : Reference 3
SCARSII/PC : Reference 3
CCIS/PC : Reference 12, 13, and 14
3.3.1 C̲C̲I̲T̲T̲ ̲V̲2̲4̲/̲P̲C̲ ̲P̲I̲N̲ ̲C̲O̲N̲N̲E̲C̲T̲I̲O̲N̲S̲
--------------------------------------------------------
' V24 PIN ABBREV. NAME
'
-------------------------------------------------------'
' 101 1 PG Protective Ground
'
' 102 7 SG Signal Ground
'
' 103 2 TD Transmitted Data
'
' 104 3 RD Received Data
'
' 105 4 RTS Request to Send
'
' 106 5 CTS Clear to Send
'
' 107 6 DSR Data Set Ready
'
' 108.2 20 DTR Data Terminal Ready
'
' 109 8 CD Carrier Detect
'
' 113 24 TC Transmitter Clock (DTE)'
' 114 15 TC Transmitter Clock (DCE)
' 115 17 RC Receiver Clock (DCE)
'
--------------------------------------------------------
FIGURE 3.3.1-1
V24/PC CONNECTIONS
3.3.2 P̲C̲ ̲T̲O̲ ̲E̲N̲D̲ ̲S̲Y̲S̲T̲E̲M̲S̲ ̲I̲/̲F̲
The following three figures show the electrical interface
between PC and connected systems.
FIGURE 3.3.2-1
CAMPS TO PC I/F
FIGURE 3.3.2-2
SCARSII TO PC I/F
FIGURE 3.3.2-3
CCIS TO PC I/F
4̲ ̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲ ̲S̲Y̲S̲T̲E̲M̲ ̲D̲E̲S̲I̲G̲N̲
This chapter details the design of the Protocol Converter
application system.
Section 4.1 contains description of common features
and section 4.2 contains detailed specifications of
individual software packages.
4.1 S̲O̲F̲T̲W̲A̲R̲E̲ ̲S̲Y̲S̲T̲E̲M̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
The system is outlined in terms of functional components,
software structure, main data flow and control logic,
common data descriptions, and interface specifications.
4.1.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
The system is composed of functional packages as shown
in figure 4.1.1-1.
The functional responsibilities of these packages are
outlined in the following. The packages are described
in details in section 4.2.1 through 4.2.8.
a) C̲o̲m̲m̲a̲n̲d̲ ̲I̲n̲t̲e̲r̲p̲r̲e̲t̲e̲r̲ ̲(̲C̲I̲)̲
Responsible for the operator interface VDU-system.
- Decodes commands from operator.
- Dispatches commands for execution by specific
system components.
- Communicates result of command to operator.
- VDU driver functions.
b) T̲r̲a̲f̲f̲i̲c̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲ ̲(̲T̲R̲C̲)̲
Responsible for message transfer.
- Control of links (logon, logoff).
- Control of transaction transfer.
- Transaction origin check (SCI check).
- Transaction Length check.
- Control of on-line test transactions.
FIGURE 4.1.1-1
FUNCTIONAL COMPONENTS
c) C̲A̲M̲P̲S̲/̲S̲C̲A̲R̲S̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ ̲A̲d̲a̲p̲t̲e̲r̲ ̲(̲C̲S̲P̲A̲)̲
Responsible for X25 level 3 protocol functions
towards CAMPS/SCARS.
- Blocking of transactions (framing).
- Message control field check.
- Transfer of frames in and out.
d) C̲A̲M̲P̲S̲/̲S̲C̲A̲R̲S̲ ̲L̲o̲w̲ ̲L̲e̲v̲e̲l̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲s̲ ̲(̲C̲S̲L̲P̲)̲
Responsible for X25 level 2 and 1 protocol functions
towards CAMPS/SCARS.
- Level 2 framing.
- Frame check sequence control.
- Transfer of frames in and out.
- Frame acknowledgement.
- Frame recovery (retransmissions).
- Frame statistics collection.
- Physical line control (level 1).
e) C̲C̲I̲S̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ ̲A̲d̲a̲p̲t̲e̲r̲ ̲(̲C̲P̲A̲)̲
Responsible for the DINDAC level protocol functions
towards CCIS.
- Blocking of transactions (segmentation).
- Segment header control.
- Transfer of segments in and out.
- Handling DINDAC service messages.
f) C̲C̲I̲S̲ ̲L̲o̲w̲ ̲L̲e̲v̲e̲l̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲s̲ ̲(̲C̲L̲P̲)̲
Responsible for the RCI/GTRS level protocol functions
towards CCIS.
- Blocking of segments (subsegmentation).
- Transfer of subsegments in and out.
- Subsegment acknowledgement.
- Subsegment recovery (retransmissions).
- Subsegment statistics collection.
- Parity control.
- Physical line control.
g) M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲ ̲(̲M̲A̲C̲)̲
Responsible for off-line hardware module test facilities
(maintenance mode).
- Decodes test commands from operator (VDU).
- Starts hardware module test programs.
- Communicates result of test to operator (VDU).
h) S̲y̲s̲t̲e̲m̲ ̲G̲e̲n̲e̲r̲a̲t̲o̲r̲ ̲a̲n̲d̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲e̲r̲ ̲(̲S̲G̲I̲)̲
Responsible for generation and initialization of
system.
- Activate operating system.
- Create and initialize system processes.
4.1.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
4.1.2.1 S̲o̲f̲t̲w̲a̲r̲e̲ ̲P̲a̲c̲k̲a̲g̲e̲s̲
Each of the functional components identified in 4.1.1
is implemented as a software package.
Each package consists s̲t̲a̲t̲i̲c̲a̲l̲l̲y̲ of a set of data declarations
and a set of package modules, each module containing
a set of procedures describing the operations performed
on the data. Each module is implemented as a separate
compilable unit of software.
Each package consists d̲y̲n̲a̲m̲i̲c̲a̲l̲l̲y̲ of one or more processes
running under supervision of the AMOS operating system.
Processes share the processing capability of the computer,
the operating system allocating time slots for each
process to execute.
Figure 4.1.2.1-1 shows the software packages and their
interfaces. Furthermore, the underlying hardware is
indicated. Note thus that CSLP and CLP each reside
in a dedicated LTU (front end processor).
FIGURE 4.1.2.1-1
SOFTWARE PACKAGES AND INTERFACES
4.1.2.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲i̲n̲g̲
Package interfaces are d̲i̲r̲e̲c̲t̲e̲d̲ interfaces.
Logically, an interface consists of a set of c̲o̲m̲m̲a̲n̲d̲s̲
and corresponding r̲e̲s̲p̲o̲n̲s̲e̲s̲. Commands are communicated
in the direction of the interface and responses are
returned in the opposite direction. This situation
is depicted in figure 4.1.2-1.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Package A Package B
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ B interface ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
A B: command
B A: response
F̲I̲G̲U̲R̲E̲ ̲4̲.̲1̲.̲2̲.̲2̲-̲1̲ GENERAL PACKAGE INTERFACE
Since packages are normally implemented as processes,
the exchange of commands and responses is implemented
using the AMOS interprocess communication facilities.
AMOS interprocess communication offers a set of functions
for transfer of information from one process to another.
The amount of information to transfer is limited to
fixed size buffers of 5 words.
These functions used for interfacing are the following:
a) send ̲message (receiver, info)(event)
c̲a̲l̲l̲ ̲p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲:
receiver: name of receiving process
info: ref to buffer (5 words) to transfer
r̲e̲t̲u̲r̲n̲ ̲p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲:
event: id used to identify the answer
later sent by receiver
f̲u̲n̲c̲t̲i̲o̲n̲:
The info is sent to receiver which will get it
by calling the wait ̲event function.
b) wait ̲event (mask, info)(eventtype, event)
c̲a̲l̲l̲ ̲p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲:
mask: defines types of events to wait for,
i.e. message, answer, interrupt, e.a.
info: ref to empty buffer (5 words) for
receiving information
r̲e̲t̲u̲r̲n̲ ̲p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲:
eventtype: identifies which of the events defined
in mask has occured
event: id to be returned when answer is sent
later
f̲u̲n̲c̲t̲i̲o̲n̲:
If an event has occured, the process continues
execution, otherwise execution is suspended until
one of the events defined in mask has occured.
c) send ̲answer (info, event)()
c̲a̲l̲l̲ ̲p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲:
info: ref to buffer (5 words) containing
answer to send
event: id received in wait ̲event identifying
the message to which the answer refers
r̲e̲t̲u̲r̲n̲ ̲p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲:
none
f̲u̲n̲c̲t̲i̲o̲n̲:
The info is sent to the process which has earlier
sent a message identified by event. This process
will get the answer by calling wait ̲event or
wait ̲answer.
d) wait ̲answer (delay, event, info)(eventtype, event)
c̲a̲l̲l̲ ̲p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲:
delay: time limit for receiving answer
event: id returned in send ̲message call
info: ref to empty buffer (5 words) for
receiving information
r̲e̲t̲u̲r̲n̲ ̲p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲:
eventtype: constant ( = answer or timeout)
event: dummy
f̲u̲n̲c̲t̲i̲o̲n̲:
If the answer to the send ̲message identified by
event has arrived, the process continues execution,
otherwise execution is suspended until the specific
event has occured or delay time units has passed
(timeout).
The exchange of a command and response along an interface
can now take place as follows:
s̲e̲n̲d̲e̲r̲ ̲o̲f̲ ̲c̲o̲m̲m̲a̲n̲d̲ r̲e̲c̲e̲i̲v̲e̲r̲ ̲o̲f̲ ̲c̲o̲m̲m̲a̲n̲d̲
command
send ̲message wait ̲event
wait ̲answer send ̲answer
response
Wait ̲answer can be replaced by wait ̲event if other
events are accepted as well.
Communication along interfaces will be described as
above in the package specifications even though the
interfaces to the LTU resident packages CLP and CSLP
involve the LTU driver to which the commands are sent
rather than to the packages directly.
4.1.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
The interpackage data flow and control logic are described
in the following.
4.1.3.1 D̲a̲t̲a̲ ̲F̲l̲o̲w̲
The data flow through the system for transactions from
CAMPS/SCARS to CCIS is shown in figure 4.1.3.1-1 and
from CCIS to CAMPS/SCARS in figure 4.1.3.1-2.
The logic controlling this transaction data flow is
shown in figures 4.1.3.2-2 and 4.1.3.2-3 of section
4.1.3.2.
FIGURE 4.1.3.1-1
PC TRANSACTION DATA FLOW
CAMPS/SCARS TO CCIS
FIGURE 4.1.3.1-2
PC TRANSACTION DATA FLOW
CCIS TO CAMPS/SCARS
4.1.3.2 C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
The interpackage control logic is accomplished by sending
commands and receiving responses along the package
interfaces.
This is depicted in figures 4.1.3.2-1 through 3.
Figure 4.1.3.2-1 shows the control flow resulting from
a logon command from the operator.
Figure 4.1.3.2-2 shows the control flow involved in
transaction transfer from CAMPS/SCARS to CCIS.
Figure 4.1.3.2-3 shows the control flow involved in
transaction transfer from CCIS to CAMPS/SCARS.
A detailed description of the interface commands can
be found in section 4.1.5 and subsections.
FIGURE 4.1.3.2-1
INTER PACKAGE CONTROL FLOW LOGON SEQUENCE
FIGURE 4.1.3.2-2
INTER PACKAGE CONTROL FLOW CAMPS/SCARS TO CCIS TRANSFER
FIGURE 4.1.3.2-3
INTER PACKAGE CONTROL FLOW CCIS TO CAMPS/SCARS TRANSFER
4.1.4 C̲o̲m̲m̲o̲n̲ ̲D̲a̲t̲a̲
Here the common data are defined in terms of variables
Types and Constants.
The definitions follow the SWELL programming standard
for data declarations (PASCAL-like structured types).
4.1.4.1 D̲a̲t̲a̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
There are three common variables:
a) S̲y̲s̲t̲e̲m̲ ̲M̲o̲d̲e̲ describing current mode of the system.
The system ̲mode variable is accessed through commonly
available so-called monitor procedures. These are:
1) MONITOR (switch ̲mode, new ̲mode)();
This procedure will set the system ̲mode variable
to value new ̲mode.
In addition, the following buffers will be
cleared:
pc ̲trans (scamps ̲to ̲ccis) (cf. 4.1.4.2b))
pc ̲trans (ccis ̲to ̲scamps) (cf. 4.1.4.2b))
to ̲cslp ̲buf (cf. 4.1.4.2d))
from ̲cslp ̲buf (cf. 4.1.4.2d))
to ̲clp ̲buf (cf. 4.1.4.2d))
from ̲clp ̲buf (cf. 4.1.4.2d))
2) MONITOR (read ̲mode)(system ̲mode);
This procedure returns the current value of
system ̲mode.
b) P̲C̲-̲T̲r̲a̲n̲s̲ data area for storing transactions passing
PC. There are two of these data areas, one for
each direction of transfer.
Incoming data blocks are accumulated sequentially
in pc ̲trans and outgoing data blocks are removed
sequentially from pc ̲trans. Two internal counters
keep track of current content.
c) F̲r̲a̲m̲e̲ ̲B̲u̲f̲f̲e̲r̲s̲ for intermediate storage of single
frames or segments with headers.
Two buffers:
to ̲cslp ̲buf
from ̲cslp ̲buf
are used by CSPA for transfer of blocks to/from
PC-Trans, and by LTU driver for transfer of X25
level 3 frames to/from CSLP.
Two buffers:
to ̲clp ̲buf
from ̲clp ̲buf
are used by CPA for transfer of blocks to/from
PC-Trans, and by LTU driver for transfer of DINDAC
segments to/from CLP.
The use of these buffers is controlled by CSPA,
CPA respectively.
Figure 4.1.4.1-1 depicts the common data variables.
The details of the data structures are described in
4.1.4.2. The figure shows two pc ̲trans data areas consisting
of a text buffer prefixed by a descriptor. The arrows
from descriptor to text indicate current byte counts
of input and output for the transaction in transfer.
System ̲mode is a simple variable. Frame buffers are
capable of storing one X25 level 3 frame or one DINDAC
Segment.
FIGURE 4.1.4.1-1
COMMON AREA OVERVIEW
4.1.4.2 D̲a̲t̲a̲ ̲D̲e̲c̲l̲a̲r̲a̲t̲i̲o̲n̲s̲
a) S̲y̲s̲t̲e̲m̲ ̲M̲o̲d̲e̲
TYPE
mode ̲type = word ̲char;
CONST
maintenance ̲mode = 'M';
local ̲mode = 'L';
operational ̲mode = 'O';
test ̲mode = 'T';
VAR
system ̲mode : mode ̲type;
b) P̲C̲ ̲T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲o̲r̲s̲
TYPE
pc ̲trans ̲desc = "pc global transaction descriptor
RECORD
sci : ARRAY (0..3) "defined at logon
OF char; "3 letters (trailing
0)
typ : char; "transaction type
(C,D,E,F,G,M,N,O,P,Q,R
prc : char; "precedence
(Y,Z,O,P,R)
cls : char; "classification
(T,S,C,R,U)
state : pc ̲trans ̲state; "state of transfer
b ̲lim : integer; "max block size
c ̲in : integer; "curr. input byte
count
c ̲out : integer; "curr. output byte
count
buf : ARRAY(0..buf ̲lim) "text buffer
OF char;
END;
pc ̲trans ̲state = "state of transaction transfer
( trans ̲idle,
trans ̲input ̲enabled,
trans ̲end ̲of ̲input,
trans ̲end ̲of ̲output,
trans ̲spooling ̲output);
flow ̲direction =
( scamps ̲to ̲ccis,
ccis ̲to ̲scamps );
CONST
buf ̲lim = trans ̲length ̲limit + ccis ̲segment ̲limit;
VAR
"two transaction buffers, one for each direction
pc ̲trans: ARRAY(flow ̲direction) OF pc ̲trans ̲desc;
c) S̲y̲s̲t̲e̲m̲ ̲C̲o̲n̲s̲t̲a̲n̲t̲s̲
TYPE
end ̲system =
( camps,
scars,
ccis,
unknown );
CONST
trans ̲length ̲limit = 12004; "characters
short ̲trans ̲length ̲limit = 2000; "characters
scamps ̲frame ̲limit = 128; "characters
scamps ̲frame ̲retrans = 3; "no of retransmissions
scamps ̲frames ̲unacked= 3; "max no of
outstanding
"frames
scamps ̲frame ̲timeout = 3; "seconds
scamps ̲preempt ̲sequence = cr,cr,lf,'ZPH ZPH',cr,cr,lf,
lf,lf,lf,lf,lf,lf,lf,'NNNN';
scamps ̲preempt ̲size = 24; " characters
ccis ̲segment ̲limit = 1140; "characters
ccis ̲frame ̲limit = 340; "characters
ccis ̲frame ̲timeout = 7; "seconds
ccis ̲com ̲program = 'PCTHDL '; "name of ccis
prog
ccis ̲test ̲program = 'KEN '; "name of ccis
test prog
ccis ̲com ̲sub = 'AA'; "operational
sub code
ccis ̲test ̲sub = 'QQ'; "test sub
code
"Package identifiers"
CONST "see section 4.2.1.1e)
ci ̲id = #9000;
trc ̲id = #A000;
cpa ̲id = #B000;
cspa ̲id = #C000;
mac ̲id = #D000;
clsp ̲id = #E000;
clp ̲id = #F000;
d) F̲r̲a̲m̲e̲ ̲B̲u̲f̲f̲e̲r̲s̲
VAR
to ̲clsp ̲buf,
from ̲cslp ̲buf:ARRAY(0..scamps ̲frame ̲limit-1)
OF char;
to ̲clp ̲buf,
from ̲cp ̲buf:ARRAY(0..CCIC ̲Segment limit-1) OF
char;
4.1.5 I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
In the following subsections the internal system interfaces
are described in terms of functions and related declarations.
Figure 4.1.5-1 provides an overview of the package
interfaces.
FIGURE 4.1.5-1
PACKAGE INTERFACE OVERVIEW
4.1.5.1 O̲p̲e̲r̲a̲t̲o̲r̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The functions available to the operator of PC are the
following:
Check
Dump
Init
Maintenance
Logon
Logoff
Show statistics
Reset statistics
Test
Verify
These are functionally described in reference 17 Protocol
Converter System Specification, section 4.1.1.
The function syntax applied by the interface is defined
in reference 17 Protocol Converter System Specification,
section 4.1.5.1
4.1.5.2 T̲R̲C̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
This interface defines the functions offered by the
Traffic Controller Package to the environment as well
as the declarations specifying how the functions are
communicated to/from TRC as commands and responses.
The interface contains the following functions:
trc ̲logon
trc ̲logoff
trc ̲enable ̲status
trc ̲test
trc ̲verify
4.1.5.2.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) trc ̲logon (scamps ̲params, ccis ̲params)(cc)
p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
scamps ̲params are
1) system: scars or camps
2) speed: baud rate 2400, 4800 or 9600
3) sci: channel identifier
ccis ̲params are
1) speed: baud rate 2400, 4800 or 9600
2) sci: channel identifier
3) id ̲pass: userid and password to ccis
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok, wrong ̲mode, ccis ̲failed,
scamps ̲failed
f̲u̲n̲c̲t̲i̲o̲n̲
Links are opened to both end systems.
System ̲mode on entry is local ̲mode.
System ̲mode on return is operational ̲mode if ok,
otherwise unchanged.
b) trc ̲logoff ()(cc)
r̲e̲s̲u̲l̲t̲
cc: completion codes
ok, wrong ̲mode
f̲u̲n̲c̲t̲i̲o̲n̲
Links to both end ̲systems are closed.
System ̲mode on entry is operational ̲mode or test
̲mode.
System ̲mode on return is local ̲mode if ok, otherwise
unchanged.
c) trc ̲enable ̲status ()(cc)
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok
link ̲closed reason code
f̲u̲n̲c̲t̲i̲o̲n̲
Response containing result of this command is returned
in the following situations:
1) Performing trc ̲logoff
cc = ok is returned
2) Any other close down situation
cc = link ̲closed reason code
d) trc ̲test ()(cc)
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok, wrong ̲mode
f̲u̲n̲c̲t̲i̲o̲n̲
Test mode is entered.
System ̲mode on entry is operational ̲mode.
System ̲mode on return is test ̲mode if ok, otherwise
unchanged.
e) trc ̲verify (system, length)(cc)
p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
system: ccis, camps or scars
length: no of characters in test message
generated
r̲e̲s̲u̲l̲t̲
cc: completion codes
ok, wrong ̲mode, test ̲failed
f̲u̲n̲c̲t̲i̲o̲n̲
Verify one link by transmitting test message and
receiving same message.
Compare message sent with message received.
If the result of the compare is ok the test is
passed otherwise result is failed.
System ̲mode on entry is test ̲mode, unchanged on
return.
4.1.5.2.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲c̲l̲a̲r̲a̲t̲i̲o̲n̲s̲
TYPE
trc ̲command ̲id =
( trc ̲logon ̲id,
trc ̲logoff ̲id,
trc ̲test ̲id,
trc ̲verify ̲id,
trc ̲enable ̲status ̲id );
trc ̲command = "command buffer sent from CI to TRC
RECORD
id: trc ̲command ̲id;
params: ARRAY(0..3) OF integer
END;
trc ̲logon ̲cmd =
RECORD
id: trc ̲command ̲id;
scamps ̲params: address;
ccis ̲params: address;
END;
scamps ̲logon ̲params =
RECORD
speed : ARRAY(0..1) " (0) = 0 (not used)
OF byte; " (1) = baud rate:
" #OB 2400
" #OC 4800
" #OD 9600
system : end ̲system ; " camps or scars
sci : ARRAY(0..3) " channel id
OF char; " 3 letters
END;
ccis ̲logon ̲params =
RECORD
speed : ARRAY(0..1) " (0) = 0 (not used)
OF byte; " (1) = baud rate:
" #OB 2400
" #OC 4800
" #OD 9600
id ̲pass : ARRAY(0..35) " $*$LODid$password/DNM
OF char; " left adjusted,
" trailing 0's
sci : ARRAY(0..3) " channel id
OF char; " 3 letters
END;
…86…1 …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02…
trc ̲verify ̲cmd =
RECORD
id: trc ̲command ̲id;
system: end ̲system; "camps, scars
or ccis
length: integer; "length of
test message
END;
trc ̲response = "response buffer returned from TRC
to CI"
RECORD
id: trc ̲command ̲id; "command
replied
cc: completion ̲code;
result: ARRAY(0..2) OF integer;
END;
4.1.5.3 P̲A̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
This interface defines the functions offered by the
…02…CAMPS/SCARS Protocol Adapter package (CSPA) and the
CCIS Protocol Adapter package (CPA), the interface
being identical to both packages.
The interface contains the following functions:
pa ̲logon
pa ̲logoff
pa ̲request ̲input
pa ̲request ̲output
pa ̲send ̲ack
pa ̲cancel
4.1.5.3.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) pa ̲logon (scamps ̲params, ccis ̲params)(cc,sender)
p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
scamps ̲params are as defined in 4.1.5.2.1.9
ccis ̲params are as defined in 4.1.5.2.1.a
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok, failed
sender: CPA or CSPA
f̲u̲n̲c̲t̲i̲o̲n̲
Link to one of the end systems is opened.
b) pa ̲logoff ()(cc, sender)
r̲e̲s̲u̲l̲t̲
cc: completion code:
ok
sender: CPA or CSPA
f̲u̲n̲c̲t̲i̲o̲n̲
Link to one of the end systems is closed.
c) pa ̲request ̲input (buf ̲addr)(cc,sender,bytes,eoi)
p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
buf ̲addr: address of pc ̲trans buffer
where input is delivered
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok, link ̲down, message ̲control
̲error, cancelled,
new ̲transaction,
protocol ̲failure
sender: CPA or CSPA
bytes: no of bytes transferred
eoi: true if end of input
(last block of transaction)
f̲u̲n̲c̲t̲i̲o̲n̲
One block of input is requested.
When transferred, response to the command is received.
Max. block size is for CSPA
scamps ̲frame ̲limit-8 (=120)
and for CPA
ccis ̲segment ̲limit-34 (=1106).
The data block is transferred to
pc ̲trans.buf starting at location
pc ̲trans.c ̲in.
If first block of transaction, fields
pc ̲trans.typ
pc ̲trans.prc
pc ̲trans.cls
are loaded.
If first block of transaction and pc ̲trans.c ̲in
= 0 (indicating that buffer is not empty). cc =
new ̲transaction is returned and no data is transferred.
d) pa ̲request ̲output (buf ̲addr, bytes, block ̲type)
(cc, sender)
p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
buf ̲addr: address of pc ̲trans buffer
from where output is taken
bytes: no of bytes to transfer
block ̲type: single ̲block, start ̲block,
mid ̲block or end ̲block
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok, link ̲down, message ̲con-
trol ̲error, cancelled, proto-
col ̲failure
sender: CPA or CSPA
f̲u̲n̲c̲t̲i̲o̲n̲
One block of data is requested for output.
When done, response is received.
Max. block size is for CSPA
scamps ̲frame ̲limit-8 (=120)
and for CPA
ccis ̲segment ̲limit-34 (=1106).
The data block is transferred from pc ̲trans.buf
starting at location pc ̲trans.c ̲out.
If block ̲type is single ̲block or end ̲block, response
will not be returned until acknowledgement of the
entire transaction has been received from the output
destination.
e) pa ̲send ̲ack (sci ̲tsn)(cc, sender)
p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
sci ̲tsn: 6 character string containing
sci and tsn of transaction
to acknowledge.
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok, link ̲down, message ̲control
̲error, cancelled, proto
col ̲failure
sender: …02…CPA or CSPA
f̲u̲n̲c̲t̲i̲o̲n̲
Transaction acknowledgement service message is
sent.
f) pa ̲cancel (flow )(cc, sender)
p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
flow: input or output
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok
sender: CPA or CSPA
f̲u̲n̲c̲t̲i̲o̲n̲
Current processing of input or output is cancelled.
The cancellation refers to the entire transaction.
Outstanding requests are returned with cc = cancelled.
4.1.5.3.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲c̲l̲a̲r̲a̲t̲i̲o̲n̲s̲
TYPE
pa ̲command ̲id =
( pa ̲logon ̲id,
pa ̲logoff ̲id,
pa ̲request ̲input ̲id,
pa ̲request ̲output ̲id,
pa ̲send ̲ack ̲id,
pa ̲cancel ̲id );
pa ̲command = "general command buffer sent from
TRC
"to CPA and CSPA
RECORD
id: pa ̲command ̲id; "command identification
params: ARRAY(0..3) OF integer;
END;
pa ̲logon ̲cmd =
RECORD
id: pa ̲command ̲id;
scamps ̲params: address; "of parameter
buffer
ccis ̲params: address; "of parameter
buffer
END;
pa ̲request ̲input ̲cmd =
RECORD
id: pa ̲command ̲id;
addr: address; "of pc ̲trans
descriptor
END;
pa ̲request ̲output ̲cmd =
RECORD
id: pa ̲command ̲id;
addr: address; "of pc ̲trans
descriptor
bytes: integer; "no of bytes
to output
block ̲type: block ̲types;
END;
pa ̲send ̲ack ̲cmd =
RECORD
id: pa ̲command ̲id;
sci ̲tsn: ARRAY(0..5) OF char;
END;
pa ̲cancel ̲cmd =
RECORD
id: pa ̲command ̲id;
flow: flow ̲type;
END
pa ̲response = "general response buffer returned
RECORD
id: pa ̲command ̲id; "id of command
responded
cc: completion ̲code;
sender: package ̲id; "cpa ̲id or cspa
̲id
result: ARRAY(0..1) OF integer; "additional
results
if any
END;
pa ̲request ̲input ̲rsp =
RECORD
id: pa ̲command ̲id; "id of command
responded
cc: completion ̲code;
sender: package ̲id; "cpa ̲id or cspa
̲id
bytes: integer; "no of bytes returned
eoi: boolean; "true if last block
END;
block ̲types = "position of data block in transaction
( single ̲block,
start ̲block,
mid ̲block,
end ̲block
);
flow ̲type =
( input,
output );
4.1.5.4 C̲S̲L̲P̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
This interface defines the functions offered by the
CAMPS/SCARS Low Level Protocol package (CSLP) to the
environment as well as the declarations specifying
format of commands and responses. The communication
goes via the CAMPS/SCARS LTU Driver (SCADRV).
The interface contains the following functions:
cslp ̲reopen
cslp ̲set ̲up ̲lines
cslp ̲set ̲up ̲link
cslp ̲disc ̲lines
cslp ̲disc ̲link
cslp ̲request ̲input
cslp ̲request ̲output
cslp ̲cancel ̲input
cslp ̲cancel ̲output
cslp ̲statistics
cslp ̲cancel ̲command
cslp ̲close
cslp ̲bootload
4.1.5.4.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) cslp ̲reopen (retrans,
outstanding,
timeout ̲time,
speed)
(cc)
p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
retrans: max.no of frame retransmissions
outstanding: Max. no of outstanding frames
timeout ̲time: frame acknowledgement timeout
(param * 200 msec.)
speed: outgoing baudrate
(#OB = 2400
#OC = 4800
#OD = 9600)
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok, wrong ̲parameter,
not ̲disconnected
f̲u̲n̲c̲t̲i̲o̲n̲
The data channel in the LTU is initialized with
the parameters specified. Link must be disconnected
when applying this function.
b) cslp ̲set ̲up ̲lines ( ) (cc)
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok, not disconnected
f̲u̲n̲c̲t̲i̲o̲n̲
set up status lines according to X.21 bis. X.25
level 2 TX-protocol must be disconnected when applying
this function.
c) cslp ̲disc ̲lines ( ) (cc)
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok, not ̲disconnected
f̲u̲n̲c̲t̲i̲o̲n̲
Disconnect status lines according to X.21 bis.
X.25 level 2 protocol must be disconnected when
applying this function.
d) cslp ̲set ̲up ̲link ( ) (cc)
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok, not ̲disconnected
f̲u̲n̲c̲t̲i̲o̲n̲
Connect X.25 level 2 protocol.
X.25 level 2 TX-protocol must be disconnected when
applying this function.
e) cslp ̲disc ̲link ( ) (cc)
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok, not ̲connected
f̲u̲n̲c̲t̲i̲o̲n̲
Disconnect X.25 level 2 protocol.
X.25 level 2 TX-protocol must be disconnected when
applying this function
f) cslp ̲request ̲input (addr) (cc, bytes)
p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
addr: address of input buffer
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok, link ̲down, cancelled,
protocol ̲failure
bytes: no. of bytes delivered
f̲u̲n̲c̲t̲i̲o̲n̲
One block of input is requested (X25 frame).
g) cslp ̲request ̲output (addr, bytes) (cc)
p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
addr: address of output buffer
bytes: no. of bytes to output
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok, link ̲down, cancelled,
protocol ̲failure
f̲u̲n̲c̲t̲i̲o̲n̲
one block of output is sent (X25 frame).
h) cslp ̲cancel ̲input ( ) (cc)
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok
f̲u̲n̲c̲t̲i̲o̲n̲
Cancel pending input request
i) cslp ̲cancel ̲output ( ) (cc)
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok
f̲u̲n̲c̲t̲i̲o̲n̲
Cancel pending output request
j) cslp ̲statistics
( reset ̲noreset ̲transmit ̲count,
reset ̲noreset ̲retransmit ̲count,
reset ̲noreset ̲received ̲error ̲free ̲count,
reset ̲noreset ̲CRC ̲error ̲count,
reset ̲noreset ̲frames ̲too ̲long ̲count,
reset ̲noreset ̲frames ̲too ̲short ̲count,
reset ̲noreset ̲DCD ̲drop ̲count)
( cc,
frames ̲transmitted,
frames ̲retransmitted,
frames ̲received ̲error ̲free,
CRC ̲errors
frames ̲too ̲long
frames ̲too ̲short
DCD ̲drops )
p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
reset ̲noreset ̲transmit ̲count
. .
reset ̲noreset ̲DCD ̲drop ̲count: These
parameters indicate whether
the related counters on com-
pletion of the function shall
be reset (value zero) or
not (value non zero).
r̲e̲s̲u̲l̲t̲
cc: completion code:
ok
frames ̲transmitted
. .
DCD ̲drops: current values of related
statistic counters.
f̲u̲n̲c̲t̲i̲o̲n̲
Accumulated values of frame statistic counters
are returned. Corresponding input parameters indicate
if the counters shall be reset (RESET STATISTICS)
or not (SHOW STATISTICS)
k) cslp ̲cancel ̲command (cmd ̲id) (cc)
p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
cmd ̲id: id of command to cancel
R̲e̲s̲u̲l̲t̲
cc: completion codes:
ok
f̲u̲n̲c̲t̲i̲o̲n̲
Cancel pending command identified by cmd ̲id.
This command is not sent to CSLP, but the LTU Driver
will generate a response to the pending command
with cc = cancelled.
l) cslp ̲close () (cc)
R̲e̲s̲u̲l̲t̲
cc: completion codes:
ok
f̲u̲n̲c̲t̲i̲o̲n̲
Close the link. This command replaces
cslp ̲disc ̲link, cslp ̲disc ̲lines.
m) cslp ̲bootload () (cc)
R̲e̲s̲u̲l̲t̲
cc: completion codes:
ok, bootload ̲failed
f̲u̲n̲c̲t̲i̲o̲n̲
This command directs the LTU Driver to download
CSLP into the LTU.
4.1.5.4.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲c̲l̲a̲r̲a̲t̲i̲o̲n̲s̲
TYPE
cslp ̲command ̲id =
( cslp ̲reopen ̲id,
cslp ̲set ̲up ̲lines ̲id,
cslp ̲disc ̲lines ̲id,
cslp ̲set ̲up ̲link ̲id,
cslp ̲disc ̲link ̲id,
cslp ̲request ̲input ̲id,
cslp ̲request ̲output ̲id,
cslp ̲cancel ̲input ̲id,
cslp ̲cancel ̲output ̲id,
cslp ̲statistics ̲id,
cslp ̲cancel ̲command ̲id,
cslp ̲close ̲id,
cslp ̲bootload ̲id);
cslp ̲command = " general command buffer
RECORD
id: cslp ̲command ̲id; " command identification
params: ARRAY(0..3) OF integer;
END;
cslp ̲reopen ̲cmd =
RECORD
id: cslp ̲command ̲id;
addr: address; "of cslp ̲reopen ̲params
bytes: integer; "size of param buffer
END;
cslp ̲reopen ̲params =
RECORD
retrans: byte; " max frame retransmissions
outstanding: byte; " max outstanding frames
timeout ̲time: byte; " frame ack timeout (* 200
msec)
speed: byte; " baud rate out
" (#0B=2400, #0C=4800, #0D=9600)
END;
cslp ̲request ̲input ̲cmd =
RECORD
id: cslp ̲command ̲id;
addr: address; " of data buffer
END;
cslp ̲request ̲output ̲cmd =
RECORD
id: cslp ̲command ̲id;
addr: address; " of data buffer
bytes: integer; " amount to transfer
END;
cslp ̲statistics ̲cmd =
RECORD
id: cslp ̲command ̲id;
addr: address; "of buffer containing cslp ̲
"statistics ̲params on call
"and NL cslp ̲response ̲
"params on return
fill: ARRAY (0..2) OF integer "dummy
END;
cslp ̲statistics ̲params =
RECORD " input value 0 indicates reset of counter
" value 1 indicates no reset of counter
frames ̲transmitted: byte;
frames ̲retransmitted: byte;
frames ̲received ̲error ̲free: byte;
CRC ̲errors: byte;
frames ̲too ̲long: byte;
frames ̲too ̲short: byte;
DCD ̲drops: byte;
END;
cslp ̲response = " response buffer returned from cslp
RECORD
id: lp ̲command ̲id; " id of related command
cc: completion ̲code;
bytes: integer; " used by request
̲input
fill: ARRAY(0..l) OF integer; " dummy
END;
cslp ̲response ̲params =
RECORD
frames ̲transmitted,
frames ̲retransmitted,
frames ̲received: integer;
frame ̲errors: ARRAY (0..3) OF byte;
"(0) = CRC errors, (1) = too long frames
"(2) = too short frames, (3) = DCD drops
cslp ̲cancel ̲command ̲cmd :
RECORD
id: cslp ̲command ̲id;
cmd ̲id: cslp ̲command ̲id;
END;
4.1.5.5 C̲L̲P̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
This interface defines the functions offered by the
CCIS Low Level Protocol package (CLP) to the environment
as well as the declarations specifying format of command
and responses. The communication goes via the CCIS
LTU Driver (CISDRV).
The interface contains the following functions:
clp ̲open ̲link
clp ̲close ̲link
clp ̲request ̲input
clp ̲request ̲output
clp ̲cancel ̲input
clp ̲cancel ̲output
clp ̲show ̲statistics
clp ̲reset ̲statistics
clp ̲cancel ̲command
clp ̲bootload
4.1.5.5.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) clp ̲open ̲link (ccis ̲params)(cc)
p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
ccis ̲params are
1) speed: baud rate 2400, 4800 or 9600
(#OB = 2400
#OC = 4800
#OD = 9600)
2) id ̲pass: userid and password to ccis
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok, ccis ̲failed
f̲u̲n̲c̲t̲i̲o̲n̲
Link to ccis is opened and logon to DINDAC performed.
b) clp ̲close ̲link ()(cc)
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok
f̲u̲n̲c̲t̲i̲o̲n̲
Disconnect the link to ccis.
c) clp ̲request ̲input (addr, clp ̲action)(cc, bytes)
p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
addr: address of input buffer
clp ̲action: = 1 do not start sending
'ack ̲no ̲request'
= 0 start sending 'ack ̲no
̲
request' if previous input
is unacknowledged.
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok, link ̲down, cancelled, protocol
̲failure
bytes: no of bytes delivered
f̲u̲n̲c̲t̲i̲o̲n̲
One block of input is requested (a DINDAC data
segment or service message). The clp ̲action flag
tells the immediate action when receiving this
command.
d) clp ̲request ̲output (addr, bytes, clp ̲action)(cc)
p̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
addr: address of output buffer
bytes: no of bytes to output
clp ̲action: = 1 await 'transmit ̲data'
before sending output
= 0 send 'break' and await
'transmit ̲data' before
sending output.
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok, link ̲down, cancelled, protocol
̲failure, link ̲busy
f̲u̲n̲c̲t̲i̲o̲n̲
One block of output is sent (a DINDAC segment or
service message). The clp ̲action flag tells the
immediate action prior to sending output.
e) clp ̲cancel ̲input ()(cc)
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok
f̲u̲n̲c̲t̲i̲o̲n̲
Cancel pending input request.
f) clp ̲cancel ̲output ()(cc)
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok
f̲u̲n̲c̲t̲i̲o̲n̲
Cancel pending output request.
g) clp ̲show ̲statistics ()
( cc,
frames ̲transmitted,
frames ̲retransmitted,
frames ̲received ̲error ̲free,
frames ̲received ̲with ̲error )
r̲e̲s̲u̲l̲t̲
cc: completion code:
ok
frames ̲transmitted: counter
frames ̲retransmitted: counter
frames ̲received ̲error ̲free: counter
frames ̲received ̲with ̲error: counter
f̲u̲n̲c̲t̲i̲o̲n̲
Return accumulated values of the statistics counters.
h) clp ̲reset ̲statistics ()(cc)
r̲e̲s̲u̲l̲t̲
cc: completion code:
ok
f̲u̲n̲c̲t̲i̲o̲n̲
Reset frame statistic counters.
i) clp ̲cancel ̲command (cmd ̲id) (cc)
p̲a̲r̲a̲m̲e̲t̲e̲r̲
cmd ̲id: id of command to cancel
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok
f̲u̲n̲c̲t̲i̲o̲n̲
Cancel pending command identified by cmd ̲id.
This command is not sent to CLP, but the LTU Driver
will generate a response to the pending command
with cc = cancelled.
j) clp ̲bootload () (cc)
r̲e̲s̲u̲l̲t̲
cc: completion codes:
ok, bootload ̲failed
f̲u̲n̲c̲t̲i̲o̲n̲
This command directs the LTU Driver to download
CLP into the LTU.
4.1.5.5.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲c̲l̲a̲r̲a̲t̲i̲o̲n̲s̲
TYPE
clp ̲command ̲id = ( "identifies incoming
cmd
clp ̲open ̲link ̲id,
clp ̲close ̲link ̲id,
clp ̲request ̲input ̲id,
clp ̲request ̲output ̲id,
clp ̲cancel ̲input ̲id,
clp ̲cancel ̲output ̲id,
clp ̲show ̲statistics ̲id,
clp ̲reset ̲statistics ̲id);
clp ̲cancel ̲command ̲id,
clp ̲bootload ̲id);
clp ̲open ̲link ̲cmd =
RECORD
id: clp ̲command ̲id;
addr: address; "of clp ̲logon ̲params
bytes: integer; "size of clp ̲logon ̲params
"trailing 0'S excluded from
id ̲pass
END;
clp ̲logon ̲params =
RECORD
speed: ARRAY(0..1) OF byte; "(0) = 0 (not
used)
"(1) baud
rate:
"#0B 2400
"#0C 4800
"#0D 9600
id ̲pass: ARRAY(0..35) OF char;
END;
clp ̲close ̲cmd =
RECORD
id: clp ̲command ̲id;
END;
clp ̲request ̲input ̲cmd =
RECORD
id: clp ̲command ̲id;
addr: address; "of data buffer
clp ̲action: integer; " = 1 do not send 'ack ̲no
̲request'
" = 0 Send 'ack ̲no ̲request"
if
" unanswered input
END;
clp ̲request ̲output ̲cmd =
RECORD
id: clp ̲command ̲id;
addr: address; "of data buffer
bytes: integer; "amount to transfer
clp ̲action: integer; " = 1 await 'transmit ̲data'
" = 0 send 'break' and await
'transmit ̲data'
END;
clp ̲cancel ̲input ̲cmd =
RECORD
id: clp ̲command ̲id;
END;
clp ̲cancel ̲output ̲cmd =
RECORD
id: clp ̲command ̲id;
END;
clp ̲show ̲statistics ̲cmd =
RECORD
id: clp ̲command ̲id;
addr: address; "of result buffer
END;
clp ̲reset ̲statistics ̲cmd =
RECORD
id: clp ̲command ̲id;
END;
clp ̲cancel ̲command ̲cmd =
RECORD
id: clp ̲command ̲id;
cmd ̲id; clp ̲command ̲id;
END;
clp ̲response =
RECORD
id: clp ̲command ̲id;
cc: completion ̲code
bytes: integer;
fill: ARRAY(0..1) OF integer;
END;
clp ̲response ̲params =
RECORD
frames ̲transmitted,
frames ̲retransmitted,
frames ̲received ̲error ̲free,
frames ̲received ̲with ̲error: integer;
END;
