top - download
⟦8fa106794⟧ Wang Wps File
Length: 52715 (0xcdeb)
Types: Wang Wps File
Notes: CPS/SDS/006
Names: »1079A «
Derivation
└─⟦53e9d9273⟧ Bits:30006039 8" Wang WCS floppy, CR 0063A
└─ ⟦this⟧ »1079A «
WangText
…07……00……00……00……00…:…0a……00……00…:…0b…: 7…0c…7…05…6…0d…6…06…5…09…5…0d…5…01…5…06…4…0b…4…01…4…06…3…0c…3…0e…3…01…3…02…3
2…09…2…0f…2 2…05……86…1 …02… …02… …02…
…02…CPS/SDS/006
…02…HKI/810801…02……02…
I/O CONTROL
…02……02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 GENERAL ......................................
9
1.1 PURPOSE AND SCOPE ........................
9
1.1.1 Purpose ..............................
9
1.1.2 Scope ................................
9
1.2 APPLICABLE DOCUMENTS AND PROJECT
REFERENCES................................
10
1.2.1 Applicable Documents .................
10
1.2.2 Project References ...................
10
1.3 TERMS AND ABBREVIATIONS ..................
11
1.3.1 Terms ................................
11
1.3.2 Abbreviations ........................
14
2 SUMMARY OF REQUIREMENTS ......................
17
2.1 PACKAGE DESCRIPTION ......................
17
2.1.1 Summary of Functions .................
20
2.1.2 Summary of External Interfaces .......
22
2.2 PACKAGE FUNCTIONS ........................
25
2.2.1 Main Functions (Normal Operation) ....
25
2.2.1.1 Line Interface Control ...........
25
2.2.1.2 Device and Line Control Functions
37
2.2.1.2.1 NICS TARE Control Function ...
37
2.2.1.2.2 SCARS/CCIS Control Function ..
37
2.2.1.2.3 TRC, Point-to-Point Connection
Control Function .............
43
2.2.1.2.4 OCR Control Function .........
43
2.2.1.2.5 Teleprinter Control Function .
43
2.2.1.2.6 PTP/PTR Control Function .....
43
2.2.1.2.7 Medium Speed Teleprinter Con-
trol Function ................
44
2.2.1.2.8 VDU Control Function .........
44
2.2.1.2.9 Software Development VDU
Control Function .............
50
2.2.1.2.10 Line Printer Handler Function
50
2.2.1.2.11 PU-PU Handler ................
50
2.2.1.2.12 SSC Handler Functions ........
50
2.2.1.2.13 Physical Security Key ........
50
2.2.1.2.14 Message Record Format ........
51
2.2.2 Functional Responsibilities ..........
53
2.2.2.1 Initialization, Closedown, and
Restart ..........................
53
2.2.2.1.1 Initialization ...............
53
2.2.2.1.2 Close Down ...................
53
2.2.2.1.3 Restart ......................
53
2.2.2.2 Checkpointing and Recovery .......
54
2.2.2.3 Error Detection and Error Handling
54
2.2.2.3.1 Request Validation Errors ....
54
2.2.2.3.2 External Interface Errors ....
54
2.2.2.4 Integrity of Operation ...........
55
2.2.2.5 Data Collection (LOG, STATISTICS,
and REPORTS) .....................
55
2.2.2.6 Security .........................
55
2.2.2.6.1 Access Control ...............
56
2.2.2.6.2 Other Security Measures ......
56
2.3 CHARACTERISTICS ..........................
56
2.3.1 Timing ...............................
56
2.3.1.1 PU Timing ........................
56
2.3.1.2 TDX Timing .......................
57
2.3.1.3 LTUX and LTU Timing ..............
57
2.3.1.4 Timing Examples ..................
58
2.3.2 Throughput ...........................
58
2.3.3 Flexibility ..........................
59
2.3.4 Accurracy ............................
59
3 ENVIRONMENT ..................................
60
3.1 EQUIPMENT ................................
60
3.2 SOFTWARE .................................
60
3.2.1 System Software ......................
60
3.2.2 Development Support Software .........
60
3.3 INTERFACES ...............................
60
3.3.1 External Interfaces ..................
60
3.3.2 Package Interfaces ...................
61
3.4 FUNCTIONS MAINTAINED BY OTHER PACKAGES ...
61
3.4.1 Restart ..............................
61
3.4.2 Watchdog Interfaces ..................
61
4 PACKAGE DESIGN ...............................
62
4.1 PACKAGE OVERVIEW .........................
62
4.1.1 Functional Specification .............
62
4.1.2 Software Structure ...................
77
4.1.2.1 Overview .........................
77
4.1.2.2 Functions Allocation .............
79
4.1.3 Data Flow and Control Logic ..........
85
4.1.4 Package Data .........................
87
4.1.5 Common Data ..........................
87
4.1.6 Interfaces ...........................
96
4.1.6.1 External Interfaces ..............
96
4.1.6.2 Package Interfaces ...............
96
4.1.6.2.1 Control Interfaces ...........
96
4.1.6.2.2 Data Transport Interfaces ....
98
4.1.6.2.2.1 Medium Speed Teleprinter
Data .....................
101
4.1.6.2.2.2 PTP/PTR Data Interface ...
103
4.1.6.2.2.3 TRC, Point to Point Data
Interface ................
106
4.1.6.2.2.4 OCR Data Interface .......
106
4.1.6.2.2.5 PU-PU Data Interface .....
108
4.1.6.2.2.6 NICS TARE Data Interface .
108
4.1.6.2.2.7 CCIS/SCARS Data Interface
110
4.1.6.2.3 FORMAT HANDLER Interface .....
112
4.1.6.2.3.1 Process Oriented Interface
112
4.1.6.2.3.2 VDU Split Oriented
Interface ................
112
4.1.6.3 Sub-Package Interfaces ...........
122
4.1.6.3.1 FORMAT Handler to LTUX Handler
122
4.1.6.3.2 LTUX Handler - LTUX Functions
Subpackages Interfaces .......
123
4.1.6.3.3 LTU Handler - NICS TARE LTU
Functions Subpackages ........
126
4.1.6.3.4 LTU Handler - CCIS/SCARS LTU
Functions Subpackages ........
126
4.2.1 Format Handler Subpackage ............
127
4.2.1.1 Functional Specification .........
127
4.2.1.1.1 Functional Breakdown .........
127
4.2.1.1.2 Functional Description .......
136
4.2.1.2 Software Specification ...........
137
4.2.1.3 Data Flow and Control Logic ......
140
4.2.1.3.1 Overview .....................
140
4.2.1.3.2 Functional Control and Data
Flow .........................
144
4.2.1.3.3 Functional Routines Schedule
Flow .........................
148
4.2.1.3.4 Functional Routines HIPO
Charts .......................
155
4.2.1.4 Subpackage Data ..................
177
4.2.1.5 Subpackage Interface .............
181
4.2.2 LTUX Handler Subpackage ..............
182
4.2.2.1 Functional Specification .........
182
4.2.2.1.1 Functional Breakdown .........
182
4.2.2.1.2 Functional Description .......
209
4.2.2.2 Software Specification ...........
211
4.2.2.2.1 VDU Handler Software
Specification ................
211
4.2.2.2.2 OCR Handler Software
Specification ................
225
4.2.2.2.3 Low Speed Line Handler .......
235
4.2.2.3 Data Flow and Control Logic ......
244
4.2.2.3.1 VDU Handler Flow .............
244
4.2.2.3.2 OCR Handler Flow .............
293
4.2.2.3.3 Low Speed LIne Handler Flow ..
326
4.2.2.4 Subpackage Data ..................
356
4.2.2.4.1 VDU Handler Data .............
356
4.2.2.4.2 OCR Handler Data .............
359
4.2.2.4.3 Low Speed Line Handler Data ..
361
4.2.2.5 Subpackage Interfaces ............
363
4.2.2.5.1 VDU Handler Interface ........
363
4.2.2.5.2 OCR Handler Interface ........
369
4.2.2.5.3 Low Speed Line Handler
Interface ....................
372
4.2.3 LTU Handler Subpackage ...............
375
4.2.3.1 Functional Specification .........
375
4.2.3.1.1 Functional Breakdown .........
375
4.2.3.1.2 Functional Description .......
385
4.2.3.2 Software Specification ...........
385
4.2.3.3 Data Flow and Control Logic ......
391
4.2.3.3.1 NICS TARE Flow ...............
393
4.2.3.3.2 CCIS/SCARS Flow ..............
393
4.2.3.4 Subpackage Data ..................
394
4.2.3.5 Subpackage Interface .............
394
4.2.4 LTUX Functions Subpackage ............
395
4.2.4.1 Functional Specification .........
395
4.2.4.1.1 Functional Breakdown .........
395
4.2.4.2 Firmware Structure ...............
415
4.2.4.3 Data Flow and Control Logic ......
423
4.2.4.3.1 Data Item ....................
423
4.2.4.3.2 Control Logic ................
435
4.2.4.4 Subpackage Data ..................
438
4.2.4.5 Subpackage Interface .............
441
4.2.4.5.1 Interface to LTUX Handler ....
441
4.2.4.5.2 Interface to Statement Firm-
ware .........................
441
4.2.5 NICS TARE LTU Functions Subpackage ...
446
4.2.6 CCIS/SCARS LTU Functions Subpackage ..
446
4.2.7 SSC Interface Subpackage .............
446
4.2.7.1 Functional Description ...........
446
4.2.7.1.1 Functional Breakdown .........
446
4.2.7.1.2 Functional Description .......
454
4.2.7.2 Software Specification ...........
455
4.2.7.3 Data Flow and Control Logic ......
455
4.2.7.3.1 Watchdog Mode Flow ...........
455
4.2.7.3.2 Non Watchdog Mode Flow .......
465
4.2.7.4 Subpackage Data ..................
465
4.2.7.5 Subpackage Interface .............
465
4.2.8 PU-PU Handler Subpackage .............
467
4.2.8.1 Functional Specifications ........
467
4.2.8.1.1 Functional Breakdown .........
467
4.2.8.1.2 Functional Description .......
469
4.2.8.2 Software Specification ...........
469
4.2.8.3 Data Flow and Control Logic ......
471
4.2.8.4 Subpackage Data ..................
473
4.2.8.5 Subpackage Interfaces ............
473
4.3 MEMORY LAYOUT ............................
473
4.3.1 Format Handler Memory Layout .........
473
4.3.2 LTUX Handler Memory Layout ...........
475
4.3.3 LTU Handler Memory Layout ............
477
4.3.4 LTUX Functions Subpackage Memory
Layout ...............................
479
4.3.5 NICS TARE LTU Function Subpackage
Memory Layout ........................
479
4.3.6 CCIS/SCARS LTU Function Subpackage
Memory Layout ........................
479
4.3.7 SSC Interface Subpackage Memory Layout
479
4.3.8 PU-PU Handler Memory Layout ..........
481
1̲ ̲ ̲G̲E̲N̲E̲R̲A̲L̲
1.1 P̲U̲R̲P̲O̲S̲E̲ ̲A̲N̲D̲ ̲S̲C̲O̲P̲E̲
1.1.1 P̲u̲r̲p̲o̲s̲e̲
The Package Specification for the I/O Control package
of the CAMPS project is written to fulfil the following
objectives.
a) To provide detailed definition of the software
architecture of the I/O Control software.
b) To provide detailed definition of the CAMPS specific
I/O Control software.
c) To provide user, operational and development personnel
with details of the ongoing analysis.
d) To define in detail the interfaces with other packages
and to describe their facilities.
1.1.2 S̲c̲o̲p̲e̲
This document defines the CAMPS specific I/O Control
functions down to a level where all functions and algorithms
have been defined.
The detailed definition of data layout and details
of algorithm implementation is defined at detailed
design. Overview of the system is presented in the
CAMPS systems design.
1.2 A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲ ̲A̲N̲D̲ ̲P̲R̲O̲J̲E̲C̲T̲ ̲R̲E̲F̲E̲R̲E̲N̲C̲E̲S̲
1.2.1 A̲p̲p̲l̲i̲c̲a̲b̲l̲e̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲s̲
CAMPS System Requirements
CPS/210/SYS/0001
User Procedures and Associated Formats
CPS/230/ICD/0001
Supervisor Commands and Procedures
CPS/230/ICD/0002
NICS TARE Interface
CPS/ICD/004
SCARS II
CPS/ICD/005
ACE CCIS
CPS/ICD/006
TRC, POINT-TO-POINT CONNECTION
CPS/ICD/007
OCR Interface
CPS/ICD/008
1.2.2 P̲r̲o̲j̲e̲c̲t̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
CAMPS System Design Specification
CPS/SDS/001, issue I especially sections:
5.7 IOC Package
5.2 TDX Subsystem
5.1.5 I/O System
5.10 SSC Package
4.11 Error Handling
Reference manual for 7260T Video Display Terminal P/N
917M/00A000
1.3 T̲E̲R̲M̲S̲ ̲A̲N̲D̲ ̲A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
1.3.1 T̲e̲r̲m̲s̲
Access Control Control of specifically delegated
access rights before access is
allowed to an object.
Access Control List Structure associated with catalog
objects. Contains access rights
of user qroups to the objects.
Buffer List Element A descriptor of a data buffer
in memory. BLEs may be chained
to form a logically contiguous
buffer, which is not physically
contiguous.
Channel DAMOS term (TMS). Normally mapped
1 to 1 onto external electrical
channel.
Checkpoint Point from which restart/recovery
can take place.
Close-down Action taken to bring processing
within the system or a part there
of to a stop - can be either an
ordered sequence of steps or an
abrupt termination.
External Channel A channel in a telegraph circuit
or non telegraph circuit.
Field Area for input from/output to
terminal user.
File An unstructured, logically contiguos
part of a disk volume.
File Management Part of SFM handling Files
System
Initialization Brings the system from cold or
dead start into operational use.
No recovery actions are included.
Line Control Block Data item transferred within NICS
TARE.
Logical Line Multiplexed line in TDX system.
Low Speed Media Low speed teleprinter (PTP, PTR,
ROP), Point-to-point connection
and TRC.
Memory Segment Part of virtual memory. The memory
object to which security and access
control is applied.
Message Record Standard format used for CAMPS
Format internally.
Non Telegraph CCIS and SCARS.
Circuit
Operating System A process making high level decisions
about dynamic allocation of resources
to a set of descendant processes.
Priority An attribute of a process used
for scheduling purposes.
Procedure Special part of a program. It
must be called with a "procedure
call" instruction which automatically
saves the return point.
Process Execution of a specific program
operating on a specific set of
data. The active components of
the system to which security and
process control as well as resource
management is applied.
Program A sequence of instructions.
Protection The complete set of mechanisms
assuming that only the processes
authorized by security and access
control can access a given object.
Restart Reestablishes the dynamic behaviour
of the system based upon recovered
data.
Recovery Reestablishes continuity in memory
and file contents.
Security Control Control of classification and
special handling categories before
access allowed to an object.
Security Profile The data Type containing classification
and certain special handling categories
for an object.
Split Part of VDU screen separately
addressable.
Telegraph circuit NICS TARE, Point to point and
TRC.
Terminal VDU, Medium Speed Teleprinter,
Low Speed Teleprinter, Line Printer,
PTP/PTR and OCR.
In DAMOS TMS sense a Terminal
defines one connection on a shared
channel. An example is in the
X25 protocol a set of terminals
are multiplexed on one channel.
For VDUs one split is considered
to be two terminals, one for fields
input and output and one for function
keys.
User a) Person with responsibility
for input and output of messages.
b) Person located at the user
terminals in the staff cells.
The user is identical with the
term operator in the CPS/210/SYS/0001
and replaces it in CPS/SDS/001.
In DAMOS terms a USER is an application
process (see USER GROUP).
User Group A set of processes. A vehicle
for access control each process
belongs to exactly one user group.
User Group Unique identifier for a user group
Identification
1.3.2 A̲b̲b̲r̲e̲v̲i̲a̲t̲i̲o̲n̲s̲
ACP127 Allied Communication Procedures
No. 127
APPL Applications
BLE Buffer List Element
BPS Bit Per Second
CAMPS Computer Aided Message Processing
System
CC Completion Code
CCIS Command & Control Information
System
CCITT The International Telegraph and
Telephone Consultative Committee
CH Channel
CPU Central Processing Unit
CR Carriage Return
CRC Cyclic Redundancy Check
CSF In CPS/SDS/001 is the abbreviation
used to identify the CAMPS System
Functions.
CTC Counter Timer Circuit
DAMOS CR80D Advanced Multiprocessor
Operating System
DCB Device Control Block
DCE Data Circuit-terminating Equipment
DVM Device Management
DTE Data Terminal Equipment
EDC Error Detection and Correction
EOL End Of Line
EOLF End Of Line Function
ETC Et Cetera
FIFO First In, First Out
HDLC High Level Data Link Control
HW Hardware
ICD Interface Control Document
IF Interface
IFCB Interface Control Block
IO, I/O Input/Output
IOC Input/Output Control Package
IOS I/O System
ITA International Telegraph Alphabeth
LAPB Link Access Protocol B
LCB Line Control Block
LF Line Feed
LOG Log and Accountability Package
LSL Low Speed Line
LSLH Low Speed Line Handler
LTU Line Termination Unit
LTUX Line Termination Unit Wired to
the TDX bus
MAP Memory Mapping Unit
MSTP Medium Speed Tele Printer
MTBF Mean Time Between Failure
MTTR Mean Time To Repair
M&D Maintenance and Diagnostics
NA Not Applicable
NAK, NACK Negative Acknowledgement
NICS NATO Integrated Communication
System
OCR Optical Character Reader
OCH Operator Console Handler
OLP Off-line Software Package
PTCB Pending Transfer Control Block
PTP Paper Tape Puncher
PTR Paper Tape Reader
PU, P.U. Processor Unit
P-to-P, P-P Point to Point
RAM Random Access Memory
ROP Receive Only Printer
SCARS Status Control and Reporting System
SDS CAMPS System Design Specification
SEL Synchronization Element
SIO Serial Input/Output
SOCB System Operation Control Block
SOTF Start of Transmission Function
SRS System Requirements Specification
SSC System Status and Control
SSP Support Software Package
STI Supra-TDX Bus Interface
SW Software
TARE Telegraph Automatice Relay Equipment
TBD To Be Defined
TDX Telecommunication Data Exchange
TEMCO Terminal Monitoring and Control
THP Traffic Handling Package
TIA TDX Bus Interface Adapter
TMS Terminal Management System
TOS Time of Occurrence
TP Tele Printer
TRC Tape Relay Center
TTY Teletype
UGI User Group Identification
VDU Visual Display Unit
WDP Watchdog Processor
X25 Protocol Name
Z80 Zilog 80
2̲ ̲ ̲S̲U̲M̲M̲A̲R̲Y̲ ̲O̲F̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲
2.1 P̲A̲C̲K̲A̲G̲E̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
The I/O control SW package provides the interface between
CAMPS application software and terminals and lines.
The I/O control functions can be divided into two distinct
functions:
a) Line interface control
b) Device and line control
An overview of the I/O control SW with the two main
groups is shown in figure 2.1-1.
The I/O control software break down is shown in figure
2.1-2.
FIGURE 2.1-1
Figure 2.1-2
2.1.1 S̲u̲m̲m̲a̲r̲y̲ ̲o̲f̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
L̲i̲n̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
The Line Interface Control covers common software for
interface to lines via LTUXs and LTUs.
It is divided into:
T̲e̲r̲m̲i̲n̲a̲l̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲
The Terminal Management System controls logical
channels to LTUXs via the TDX system and logical
channels to the LTUs via a standard LTU handler.
The THS supports inclusion of device/line specific
handlers.
T̲D̲X̲ ̲S̲y̲s̲t̲e̲m̲
The TDX System provides communication on logical
lines from the TDX driver via the TDX Host Interface
to a number of LTUXs or other host interfaces.
The communication is controlled by the TDX controller
firmware.
S̲t̲a̲n̲d̲a̲r̲d̲ ̲L̲T̲U̲ ̲H̲a̲n̲d̲l̲e̲r̲
The standard LTU Handler provides the means for
the Terminal Handling System to interface to LTUs
on the IO BUS. One incarnation of the Standard
LTU handler serves one LTU with up to 16 communication
lines. The standard LTU Handler interfaces up to
16 device specific Handlers.
S̲t̲a̲n̲d̲a̲r̲d̲ ̲L̲T̲U̲ ̲M̲i̲c̲r̲o̲-̲P̲r̲o̲c̲e̲s̲s̲o̲r̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The Standard LTU micro-processor software supports
implementation of communication line protocol software
in the CR8066D LTU. It is the IO Bus interface
for data and control information input/output.
D̲e̲v̲i̲c̲e̲ ̲&̲ ̲L̲i̲n̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
The Device & Line Control consists of all line, channel
and device specific software and firmware.
It is divided into:
N̲I̲C̲S̲ ̲T̲A̲R̲E̲ ̲C̲o̲n̲t̲r̲o̲l̲
The TARE control implements the level 2 and 3 interface
of the TARE communication (i.e. the LITSYNC protocol
and handling of messages).
S̲C̲A̲R̲S̲ ̲C̲o̲n̲t̲r̲o̲l̲
The SCARS Control implements the level 2 and 3
interface of the SCARS communication (X25 protocol
and handling of messages).
C̲C̲I̲S̲ ̲C̲o̲n̲t̲r̲o̲l̲
The CCIS Control implements the level 2 and 3 interface
of the CCIS communication (As for SCARS Control).
T̲R̲C̲/̲T̲P̲ ̲C̲o̲n̲t̲r̲o̲l̲
The TRC/TP control implements the device interface
to TRC and Teleprinter lines. This includes conversion
to and from internal record format as well as character
sequence recognition. ITA2/ITA5 Conversion.
P̲T̲P̲/̲P̲T̲R̲ ̲C̲o̲n̲t̲r̲o̲l̲
The PTP/PTR Control implements the device interface
to PTP/PTR. This includes conversion to and from
internal record formats as well as character sequence
recognition. ITA2/ITA5 Conversion.
M̲e̲d̲i̲u̲m̲ ̲S̲p̲e̲e̲d̲ ̲T̲e̲l̲e̲p̲r̲i̲n̲t̲e̲r̲ ̲C̲o̲n̲t̲r̲o̲l̲
The Medium Speed Teleprinter control implements
the device interface to the MSTP including conversion
from internal record format.
O̲C̲R̲ ̲C̲o̲n̲t̲r̲o̲l̲
The OCR Control implements the device interface
to the OCR including generation of internal record
format.
V̲D̲U̲ ̲C̲o̲n̲t̲r̲o̲l̲
The VDU Control implements the device interface
for VDUs. It consists of the format handler, VDU
handler, and VDU LTUX firmware.
S̲o̲f̲t̲w̲a̲r̲e̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲V̲D̲U̲ ̲C̲o̲n̲t̲r̲o̲l̲
The Software Development VDU Control implements
the device interface for the software development
VDU.
L̲i̲n̲e̲ ̲P̲r̲i̲n̲t̲e̲r̲ ̲H̲a̲n̲d̲l̲e̲r̲
The Line Printer Handler provides the device interface
to the line printer.
P̲U̲-̲P̲U̲ ̲H̲a̲n̲d̲l̲e̲r̲
The PU-PU Handler provides the interface for the
PU-PU connection via TDX (For checkpoints).
S̲S̲C̲ ̲H̲a̲n̲d̲l̲e̲r̲
The SSC Driver provides the software interface
to the Memory MAP console interface in such a way
that communication with the SSC Computer is supported.
The SSC driver emulates a system console driver
concerning on-line standard system software.
2.1.2 S̲u̲m̲m̲a̲r̲y̲ ̲o̲f̲ ̲E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲ ̲(̲F̲i̲g̲.̲ ̲2̲.̲1̲.̲2̲-̲1̲)̲
The IO control SW interfaces to the following external
lines (see figure).
1) NICS TARE
2) CCIS
3) SCARS
5) TRC
FIGURE 2.1.2-1
and the following devices:
4) OCR
6) TP
7) VDU
8) PTP/PTR
9) MSTP (Medium Speed Teleprinter)
10) LINE PRINTER
11) SOFTWARE DEV VDU
2.2 P̲A̲C̲K̲A̲G̲E̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲S̲
2.2.1 M̲a̲i̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲(̲N̲o̲r̲m̲a̲l̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲)̲
2.2.1.1 L̲i̲n̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
The Line Interface Control Software interfaces the
device control software with the CR80D computer system.
It is the standard CR80 and microprocessor software
providing the interface from the application to the
line/device specific software.
For the Processor Unit, the Terminal Management System
performs the overall conversion from logical line names
to LTU or LTUX and line addresses.
The Standard LTU handlers perform the communication
with the LTUs located in the IO-crates and the TDX
driver performs the communication with the LTUX connected
to the TDX bus.
For the LTUs, a Z80 microprocessor operating system
and the CR80 interface software are common.
For the TDX, the Host interface firmware, the TDX controller
firmware, and the LTUX firmware interfacing to the
TDX bus are independent of actual devices.
Fig. 2.2.1.1-1 illustrates the Line Interface Control
Software/Firmware as distributed in a CR80D system
with LTUs on IO bus and LTUXs on the TDX bus.
Fig. 2.2.1.1-1
T̲e̲r̲m̲i̲n̲a̲l̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The Terminal Handling System hides the physical line
characteristics for the application. The application
accesses lines by name.
The SSC package defines the relationship between names
and physical addresses, the baud rate for the external
V24 lines, the logical linespeed, protocol/device type
and security classifications. Further, the SSC package
identifies the applications to the Terminal Handling
System (USER ON).
The TMS implements the security and access control
for LTU and LTUX connected lines. A request from the
application to OPEN line is validated against the capabilities
defined by SSC at the moment of USER ON.
The approach is shown in fig. 2.2.1.1-2.
Command exists for the SSC Package to define LTUs,
LTUXs, lines, and applications.
Command exists for the application to open and close
channels and to perform data transfer.
The TMS supports inclusion of device specific Handlers.
FIGURE 2.2.1.1-2
T̲D̲X̲ ̲S̲y̲s̲t̲e̲m̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
The TDX system performs multiplexed data transfers
(logical lines) between the two processor units and
between the processor units and up to 242 LTUXs. It
transfers up to 819200 bps. on max. 4096 logical lines.
The transmission on the TDX bus is controlled by the
TDX controller. In the processor unit the TDX Driver
is the interface to the TDX Host Interface.
Figure 2.2.1.1-3 illustrates the TDX system.
FIGURE 2.2.1.1-3
L̲T̲U̲X̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The LTUX is the standard interface between the TDX
Bus and terminals e.g. VDU, PTP, and OCR. At the TDX
side the TDX packet protocol is used for data transport.
The smallest unit, with which the unit works, is a
TDX frame. A frame contains one protocol byte, a three
bit sequence number, five bit byte counts and up to
sixteen data bytes. (Extended HDLC protocol with CRC
check). A TDX packet may contain several frames. The
frames are numbered contiguously (module 8) in order
to ensure correct transmission.
Each LTUX interfaces to four CCITT V24/V28 external
lines and is able to handle ITA no. 2 and no. 5. The
maximum transmission speed on the external lines are
4 x 2400 bps. or 1 x 9600 bps.
The TDX Controller multiplexes the data stream on the
TDX bus in a way to allow a logical line transmission
speed up to 819200 bps. (this number depends on the
firmware configuration in the LTUX).
Each LTUX is able to interface up to 16 logical lines
by multiplexing the data stream from/to the TDX bus.
A possible allocation of logical lines to physical
lines is shown in fig. 2.2.1.1-4 for VDUs.
T̲D̲X̲ ̲H̲o̲s̲t̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
All traffic between a processor unit and the TDX bus
passes by the TDX Host Interface.
The Host Interface is a high band width device that
interfaces directly to the CR80D main bus.
T̲D̲X̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲
The traffic on the TDX bus is controlled by the TDX
Controller.
The Controller receives all frames transmitted from
the Host Interface and LTUXs, executes CRC check and
retransmit the frames.
The main task for the TDX Controller is to control
the transmission speeds allocated by SSC for each TDX
device.
Fig. 2.2.1.1-4
T̲D̲X̲ ̲E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
All errors included CRC and missing frames will result
in rejection of the complete packet immediately, without
waiting for completion of the packet. The receiving
device then requests a retransmission by replying NAK
(Negative Acknowledgement). Also the acknowledgement
sent to the transmitting device is checked for errors.
A TDX system error and switch over is handled by the
IOC and SSC in common. The watchdog continuously checks
the TDX-Controller clock and advices SSC in case of
error.
S̲t̲a̲n̲d̲a̲r̲d̲ ̲L̲T̲U̲ ̲H̲a̲n̲d̲l̲e̲r̲s̲
The Standard LTU Handlers perform the communication
to the LTUs located on the IO BUS. One incarnation
of the Handler services one LTU.
The Handler interfaces to the terminal management system
receiving request herefrom. Figure 2.2.1.1-5 illustrates
the approach.
FIGURE 2.2.1.1-5
S̲t̲a̲n̲d̲a̲r̲d̲ ̲L̲T̲U̲ ̲M̲i̲c̲r̲o̲ ̲P̲r̲o̲c̲e̲s̲s̲o̲r̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The Standard LTU micro processor software provides
the environment for the protocol software.
a) it provides LTU initialization
b) it provides LTU on-line diagnostics
c) it provides a micro processor operating system
for executing protocol software
d) it provides pool management for buffers
e) it provides a standard queue interface to the CR80D
processor unit
f) it provides V24 drivers
The concept is shown in figure 2.2.1.1-6.
Figure 2.2.1.1-6
2.2.1.2 D̲e̲v̲i̲c̲e̲ ̲a̲n̲d̲ ̲L̲i̲n̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The Device and Line Control Functions are the functions
supporting specific devices and line protocols.
In this section the device/line functions are outlined
for each device/line. In fig. 2.2.1.2-1 through 3
an overview of interface, speed, alphabet and protocols
is presented. At the end of this section (in section
2.2.1.2.14) the Internal Message Record Format is shown.
2.2.1.2.1 N̲I̲C̲S̲ ̲T̲A̲R̲E̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
The control function implements the level 2 and 3 interface.
The CAMPS application (THP) sends and receives data
as a string of data in CAMPS internal message record
format. A message starts with a "Start of Message"
record and ends with an "End of Message" record.
The NICS TARE Control converts this format to the format
required for the NICS TARE line and transmits/receives
data under control of the LITSYNC protocol.
For interface details refer CPS/ICD/004.
2.2.1.2.2 S̲C̲A̲R̲S̲/̲C̲C̲I̲S̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
The control function implements the level 2 and 3 interface.
The CAMPS application (THP) sends and receives data
as a string of data in CAMPS internal message record
format. A message starts with a "Start of Message"
record and ends with an "End of Message" record.
The SCARS/CCIS Control converts this format to the
format required for the SCARS/CCIS line and transmits/receives
data under control of an X25 protocol.
The ACK/NAK of message is handled at the application
level.
For interface details refer CPS/ICD/005 and 006.
Figure 2.2.1.2-1
N̲o̲t̲e̲s̲ ̲t̲o̲ ̲F̲i̲g̲.̲ ̲2̲.̲2̲.̲1̲.̲2̲-̲1̲
1) EDC-Protocol As defined in CPS/ICD/004
2) LAP Protocol As defined in CPS/ICD/006
3) Baud Rate Underlined baud-rates shall
not be exceeded during
test.
4) Crypto I/F Interface to DOLCE as defined
in CPS/ICD/004.
5) 10 bit code Character-by-character
with odd parity. Start
bit, 7 data bit, parity
bit, and one stop bit.
6) 7 bit code Start bit, 5 data bits
and stop bit.
2.2.1.2-2
Figs. 2.2.1.2-3
2.2.1.2.3 T̲R̲C̲,̲ ̲P̲o̲i̲n̲t̲-̲t̲o̲-̲P̲o̲i̲n̲t̲ ̲C̲o̲n̲n̲e̲c̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
The control function implements the conversion to/from
CAMPS internal message record format from/to the format
required on the line. For specified lines ITA2-ITA5
conversion is performed as well.
For interface details refer to CPS/ICD/007.
2.2.1.2.4 O̲C̲R̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
The control function implements the OCR segment transmission
protocol.
Data input from the OCR is returned to the application
in CAMPS internal message record format starting with
a "Start of Message" type record and ending with an
"End of Message" type record.
The protocol is in effect in the following way: When
no application input request is present ACKs to the
OCR are withheld. This gives a maximum of 512 bytes
buffered in the IOC.
Details on the interface may be found in CPS/ICD/008.
2.2.1.2.5 T̲e̲l̲e̲p̲r̲i̲n̲t̲e̲r̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
Refer "TRC, Point-to-Point Connection" Control Function.
2.2.1.2.6 P̲T̲P̲/̲P̲T̲R̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
Refer "TRC, Point-to-Point Connection Control Function".
The PTR is equipped with a physical security key. The
activation of the key will asynchronously be reported
to the system software having initialized the PTR interface
(i.e. SSC).
2.2.1.2.7 M̲e̲d̲i̲u̲m̲ ̲S̲p̲e̲e̲d̲ ̲T̲e̲l̲e̲p̲r̲i̲n̲t̲e̲r̲ ̲(̲M̲S̲T̲P̲)̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
Refer "TRC, Point-to-Point Connection" Control Function.
The MSTP is equipped with a physical security key.
Any activation of this leads to an asynchronous report
to the system software (SSC) having initialized the
MSTP interface.
2.2.1.2.8 V̲D̲U̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
The communication method is block mode transmission.
The electrical interface is as specified in fig. 2.2.1.2-2.
Baud rates are 1200 and 2400 bps.
The VDU is equipped with a physical security key. Any
activation of this leads to an asynchroneous report
to the system software (SSC) having initialized the
VDU interface.
A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲t̲o̲ ̲V̲D̲U̲.
The application S/W interfaces to the VDU on split
basis.
The VDU screen is divided into three splits:
VDU system area - split #0
VDU header area - split #1
VDU format area - split #2
VDU Format Area
The format area consists of a number of lines. If the
number of lines is greater than the displayed format
area (22 lines) the user may page or scroll to see
the rest.
The maximum size of the split depends on space reserved
for this split. The VDU can in total accomodate approximately
20.000 characters.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
VDU SPLIT
----------------------------
PRESENT DISPLAYED VDU
FORMAT AREA SCREEN
----------------------------
SCROLL
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
SPLIT CONCEPT
A split consists of protected and unprotected fields
in any order. When the VDU is in format mode the user
is able to write and update within the unprotected
fields. On transmit request, only the contents of the
unprotected fields is sent to the application. The
application is able to select which fields to be transmitted
from the VDU.
Addressing
The fields in both splits are addressed by line type
numbers, incarnation numbers and field numbers. A group
of repeatable lines have the same line type number,
but different incarnation number.
Line type, Incarnation Field No.
1,1 1̲ ̲ 2̲ ̲ ̲ ̲ ̲ ̲ ̲ 3̲ ̲ ̲ ̲ ̲ ̲
1,2 1̲ ̲ 2̲ ̲ ̲ ̲ ̲ ̲ ̲ 3̲ ̲ ̲ ̲ ̲ ̲
2,1 1̲ ̲ 2̲ ̲ ̲ ̲ ̲ 3̲ ̲ ̲ 4̲ ̲ ̲ ̲
3,1 1̲ ̲ 2̲ ̲ ̲ ̲ ̲ ̲ ̲ 3̲ ̲ ̲ ̲ ̲ ̲
3,2 1̲ ̲ 2̲ ̲ ̲ ̲ ̲ ̲ ̲ 3̲ ̲ ̲ ̲ ̲ ̲
VDU SCREEN
LINE AND FIELD ADDRESSING
F̲o̲r̲m̲a̲t̲ ̲H̲a̲n̲d̲l̲e̲r̲
The Format Handler uses the format definitions to build
up empty or filled out standard formats on the VDU
screen.
The format definitions reside in a format file. They
are fixed at system generation and contain information
about the different standard formats used by CAMPS.
The format definitions are maintained by the Offline
Package at the CSSI site.
The Format Handler keeps track of the different types
of lines in the present format and the number of lines.
A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The application functions listed below are given names
relative to their function.
I̲n̲i̲t̲i̲a̲l̲i̲z̲e̲
This command defines to the Format Handler how many
VDU splits may be handled by the calling process and
the total memory available.
D̲e̲f̲i̲n̲e̲ ̲F̲o̲r̲m̲a̲t̲ ̲A̲r̲e̲a̲
This command defines the system format area to be used
in the VDU communication. The application may communicate
with more than one VDU and thus reserve more than one
format area.
The commands Initialize and Define Format area may
only be issued once per process/per split interface.
The following command may be reissued in order to redefine
the actual VDU split handled.
I̲n̲i̲t̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲
This command defines to the Format Handler which split
is actually handled via the above reserved format area.
R̲e̲m̲o̲v̲e̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲
Cancels definition of Terminal.
G̲e̲t̲ ̲F̲o̲r̲m̲a̲t̲
This command prepares the specified format for modification
by insert lines and delete lines below as well as output
by Output Format.
O̲u̲t̲p̲u̲t̲ ̲F̲o̲r̲m̲a̲t̲
This command outputs the format obtained by Get Format
and modified as of insert and delete line. The page
now contains the text in the format with all fields
blank.
F̲i̲e̲l̲d̲s̲ ̲O̲u̲t̲p̲u̲t̲
Fields are assumed to be organized as a consecutive
sequence of records in a buffer. In parallel a list
of field identifiers (line type, incarnation, field
number) shall be specified. The Field Output function
moves the first record to the first field in the list,
the second to the second, etc.
F̲i̲e̲l̲d̲s̲ ̲I̲n̲p̲u̲t̲
The Fields Input function inputs the requested number
of fields from and including the field specified as
the first. The field content is returned as fields
in the way that trailing blanks within the fields are
omitted. If the buffer specified is not sufficiently
long the input is terminated with error.
Note that fields are not input upon depression of ENTER,
or RETURN, but that these keys are returned to the
application, which will reserve a buffer and request
the transmission.
R̲e̲c̲e̲i̲v̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
Function keys destined for the application (All except
the key giving system attention) are received when
the Receive Control function is requested (pending
read).
S̲e̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲
Control of VDU is performed by this command. Input
specifies either "Bell" or "Clear split".
C̲h̲a̲n̲g̲e̲ ̲F̲i̲e̲l̲d̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲
If a field has been defined with changeable attributes,
they may be modified by this command. The attributes
are modified from the previous value to the specified
e.g. intensity change, flash.
I̲n̲s̲e̲r̲t̲ ̲L̲i̲n̲e̲s̲
This command inserts the specified number of lines
as incarnation of the specified line type. Calling
the specified incarnation N, the lines will be inserted
as incarnation N, N+1.... Insert Lines is allowed up
to the size of a split.
D̲e̲l̲e̲t̲e̲ ̲L̲i̲n̲e̲s̲
This command deletes the specified number of lines
from the incarnations of lines for the specified line
type calling the specified incarnation N incarnations
N, N+1.... will be deleted.
Insert Lines and Delete Lines have effect to redefine
the format obtained by Get Format and will have no
immediate effect on the VDU as long as Output Format
has not been executed. After Output Format the Insert
Lines imply an immediate shift-down of the lines on
the VDU and the Delete Lines an immediate shift-up
of lines on the VDU.
G̲e̲t̲ ̲C̲u̲r̲s̲o̲r̲ ̲P̲o̲s̲i̲t̲i̲o̲n̲
This function is used to obtain the cursor position
and the number within the split of the first displayed
line.
S̲e̲t̲ ̲C̲u̲r̲s̲o̲r̲ ̲P̲o̲s̲i̲t̲i̲o̲n̲
This function is used to set the first displayed line
and the cursor position.
2.2.1.2.9 S̲o̲f̲t̲w̲a̲r̲e̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲V̲D̲U̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
The Software Development VDU is interfaced according
to requirements from support software. The VDU communication
is TTY mode.
2.2.1.2.10 L̲i̲n̲e̲ ̲P̲r̲i̲n̲t̲e̲r̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
Refer "Software development VDU". The Line Printer
is as the Software development VDU interfaced via an
LTU.
2.2.1.2.11 P̲U̲-̲P̲U̲ ̲H̲a̲n̲d̲l̲e̲r̲
The PU-PU Handler handles the communication from PU
to PU via TDX.
2.2.1.2.12 S̲S̲C̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The SSC Handler operates in one of two modes.
When a Watchdog is attached it is initialized to operate
as a multi-channel interface to the Watchdog. One channel
for VDU, one for printer and one for PU to Watchdog
communication.
When no Watchdog is attached it may be initialized
either to handle a single TTY compatible device or
to interface to a VDU. The difference between the two
modes is, that in Watchdog mode channel control information
is included in the transferred data.
2.2.1.2.13 P̲h̲y̲s̲i̲c̲a̲l̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲K̲e̲y̲
On each VDU, medium speed teleprinter, and the PTR
is a physical locking key. A terminal is activated
by turning the locking key to "ON".
2.2.1.2.14 M̲e̲s̲s̲a̲g̲e̲ ̲R̲e̲c̲o̲r̲d̲ ̲F̲o̲r̲m̲a̲t̲
All incoming information is converted from the various
types of formats, used by the external equipment, to
a standard message record format. This record format
is again converted to the proper formats when information
is transmitted to the external equipment.
The ITA no. 5 code is used. The records are separated
by a record separator.
After the record separator is a character count byte.
The byte before the text string is used to identify
the type of information. The record format is presented
in figure 2.2.1.2-4.
Figure 2.2.1.2-4
2.2.2 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲R̲e̲s̲p̲o̲n̲s̲i̲b̲i̲l̲i̲t̲i̲e̲s̲
2.2.2.1 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲,̲ ̲C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲,̲ ̲a̲n̲d̲ ̲R̲e̲s̲t̲a̲r̲t̲
2.2.2.1.1 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
The IO Control software is initialized in several steps.
The PU resident software is loaded with the system
software at time of boot load.
The PU resident software is initialized as follows.
The SSC handler and protocol handlers when the channels
are created.
The format handler is initialized by the process in
which it logically resides (by each of the using processes).
The standard IOC software (TMS, TDX Handler) is initialized
at bootload.
The LTU microprocessor software is down-line loaded
by the PU system software and initialized for the standard
part at end of down line load, for the protocol part
when the channels are created.
The TDX firmware is initialized at power-up and when
the channels are created.
2.2.2.1.2 C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲
The IOC supports no general close-down but requires
individual close-down requests for each channel.
2.2.2.1.3 R̲e̲s̲t̲a̲r̲t̲
Refer initialization. IOC does not support restart
from a certain state but requires reinitialization
with parameters defining this state.
2.2.2.2 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲i̲n̲g̲ ̲a̲n̲d̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲
NA.
2.2.2.3 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̲
The IOC reports on
Access errors (see 2.2.2.6 Security)
Request Validation errors
External interface errors
The IOC is generally set up by the SSC on a per channel
basis. The initialization commands define the channel
type, LTU, LTUX address, speed and classification.
The possible errors detected within IOC depend on initialization
prior to the validation.
2.2.2.3.1 R̲e̲q̲u̲e̲s̲t̲ ̲V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲E̲r̲r̲o̲r̲s̲
During initialization, attempts to create more than
the maximum of channels of a type given at system generation,
attempts to create channels, where the software/firmware
is not configured, or attempts to classify channels
higher than maximum for the device, will be terminated
with error.
Application request to access terminals not properly
initialized will be terminated with error.
2.2.2.3.2 E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲E̲r̲r̲o̲r̲s̲
Errors in data, i.e. parity error or irrecoverable
protocol detected errors are reported to the requestor
of the data and in form of an asynchronous report to
the system software having initialized the channel.
Unexpected change of status of the external interface,
i.e. V24 line change or detection of key on/off (either
status line or character sequence) leads to a autonomous
close of the channel with report to the creator system
software (i.e. SSC).
2.2.2.4 I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲o̲f̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
All parameters specified by the application for data
transfer and specified by the SSC for initialization
will be verified for those impacting internal data.
Data transmitted on channels at set-up (e.g. VDU initialization)
will indirectly be verified at subsequent accesses.
Parameters obtained from DAMOS for the protocol handlers
or from the System Call Monitor for the Format Handler
will not be verifed since they are already verified
by DAMOS.
The handlers within IOC are integrated in the DAMOS
with a set of maximum privileges so any error within
these may cause a total system failure.
2.2.2.5 D̲a̲t̲a̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲ ̲(̲L̲o̲g̲,̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲,̲ ̲a̲n̲d̲ ̲R̲e̲p̲o̲r̲t̲s̲)̲
IOC does not interface directly with LOG, STP, however
for each channel statistics on the number of transferred
characters and the number of errors of protocol or
parity type are collected and become available on request.
2.2.2.6 S̲e̲c̲u̲r̲i̲t̲y̲
The Security measures within IOC can be sub-divided
into access control and other security measures.
2.2.2.6.1 A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲
The access control within IOC is handled by TMS. SSC
specifies for each terminal the access rights.
The application gains access in one of two ways.
1) By having access right and requesting OPEN.
2) By getting a terminal connection offered from a
process having access right.
2.2.2.6.2 O̲t̲h̲e̲r̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲M̲e̲a̲s̲u̲r̲e̲s̲
In order to minimize the probability that highly classified
information leaks out in case of hardware or software
errors, all data buffers for channels of a specified
classification shall be overwritten immediately after
use.
2.3 C̲H̲A̲R̲A̲C̲T̲E̲R̲I̲S̲T̲I̲C̲S̲
2.3.1 T̲i̲m̲i̲n̲g̲
In this section only timing for data transfer is discussed
since initialization commands do not impact normal
operation.
2.3.1.1 P̲U̲ ̲T̲i̲m̲i̲n̲g̲
In the timing given below is included the time to transfer
the request and the response via the Input/Output System.
N̲o̲n̲-̲F̲o̲r̲m̲a̲t̲ ̲h̲a̲n̲d̲l̲e̲r̲
Input or Output request 20ms
F̲o̲r̲m̲a̲t̲ ̲H̲a̲n̲d̲l̲e̲r̲
Timing depends on the size of format and the type of
operation.
O̲u̲t̲p̲u̲t̲ ̲F̲o̲r̲m̲a̲t̲
Per 512 bytes format length 1 disk access
Per 300 bytes format length 25ms
F̲o̲r̲ ̲F̲i̲e̲l̲d̲ ̲T̲r̲a̲n̲s̲f̲e̲r̲
Per consecutive group of
fields (either protected or
non-protected) 25ms
2.3.1.2 T̲D̲X̲ ̲T̲i̲m̲i̲n̲g̲
Input or output transfer of one line (one record in
internal format).
For VDU 200ms delay
For Lowspeed lines 2s delay
For OCR 100ms delay
For VDU a TDX baudwidth of 6400 baud, for Low Speed
lines 400 baud and for OCR at least 12.800 baud is
assumed.
2.3.1.3 L̲T̲U̲X̲ ̲a̲n̲d̲ ̲L̲T̲U̲ ̲T̲i̲m̲i̲n̲g̲
The LTU and LTUXs must be able to handle the prescribed
throughput.
2.3.1.4 T̲i̲m̲i̲n̲g̲ ̲E̲x̲a̲m̲p̲l̲e̲
For input of one VDU command (command line) with a
command size of 60 characters the timing will be
1. Transmission of "Return" key
to LTUX 8 characters ( 1200 baud) 66 ms
2. Transmission of function key report
to PU 15 ms
Maximum delay on TDX packed 20 ms
3. Format Handler delay receive function
key + request read 20 ms
4. Transmission of ARM to LTUX
( 20 chars) 30 ms
Max delay on TDX 20 ms
5. Transmission of ARM to VDU
1200 baud) 170 ms
6. Transmission of 60 chars to LTUX 500 ms
7. Transmission of 60 chars LTUX to PU 100 ms
Max. delay TDX 20 ms
8. Max. delay on response ̲2̲0̲ ̲m̲s̲
Total time before response starts 981 ms
Transmission time for command (60 chars) 500 ms
Assuming a transmission starts from the VDU immediately
after depression of "Return" the IOC contributes to
the response time in the sense of CPS/210/SYS/0001
section 3.4.1.6.3 by 481 ms.
2.3.2 T̲h̲r̲o̲u̲g̲h̲p̲u̲t̲
Refer CPS/210/SYS/0001 section 3.4.1.
2.3.3 F̲l̲e̲x̲i̲b̲i̲l̲i̲t̲y̲
At system generation a maximum number of LTUs, LTUXs,
Channels of each type (protocol software) is defined
together with a set of restrictions in the configuration.
This system generation definition conforms with the
expandability requirement for the site in question.
An on-line definition of channels and terminals as
well as reconfiguration is possible within these restrictions.
The requirement for maximum equipment configuration
is reflected within IOC in a way that makes it possible
to configure this maximum configuration at system generation.
2.3.4 A̲c̲c̲u̲r̲a̲c̲y̲
NA.
3̲ ̲ ̲E̲N̲V̲I̲R̲O̲N̲M̲E̲N̲T̲
3.1 E̲Q̲U̲I̲P̲M̲E̲N̲T̲
The IOC is the software that transforms the CR80D hardware
with CAMPS extensions to a standardized interface for
the application program. As such the IOC should be
seen as part of the environment for the application
program.
3.2 S̲O̲F̲T̲W̲A̲R̲E̲
3.2.1 S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The IOC consists of Standard System Software and the
CAMPS extensions for specific channel interfaces.
This implies that the CAMPS extensions run with the
same privileges of and the same strict requirements
to the system software in which it is integrated.
3.2.2 D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲S̲u̲p̲p̲o̲r̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The CR80D development environment for software.
The LTU/LTUX microprocessor software development on
a HP 64000 development and emulator system.
The Off-line Package FORMAT GENERATOR for Format Generation.
3.3 I̲N̲T̲E̲R̲F̲A̲C̲E̲S̲
3.3.1 E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
The IOC implements the external interfaces and as such
the interface is part of the functional specification,
refer section 2.2.1.2.
3.3.2 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
Requestors of IOC services are of one of two categories.
System Software (for CAMPS SSC) with privileges to
define CAMPS environment in form of channels and Application
Software, which is the software requesting data transfer.
As the task of the IOC is to provide a standard interface
to the environment any specific package interface shall
be found in the package specifications for packages
interfacing to IOC.
3.4 F̲U̲N̲C̲T̲I̲O̲N̲S̲ ̲M̲A̲I̲N̲T̲A̲I̲N̲E̲D̲ ̲B̲Y̲ ̲O̲T̲H̲E̲R̲ ̲P̲A̲C̲K̲A̲G̲E̲S̲
3.4.1 R̲e̲s̲t̲a̲r̲t̲
The IOC is in principle a cold start system so the
task to bring up IOC to a state reflecting a recovery
situation is left to the SSC package.
3.4.2 W̲a̲t̲c̲h̲d̲o̲g̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
IOC is based on the assumption that the Watchdog firmware
transmits/receives data to/from the MAP interface bringing
it from/sending it to the attached VDU width no modification
at all (i.e. respecting the data integrity required
by the VDU protocol).
