top - download
⟦d22860171⟧ Wang Wps File
Length: 32997 (0x80e5)
Types: Wang Wps File
Notes: AIR CANADA PROPOSAL
Names: »2071A «
Derivation
└─⟦378e273b7⟧ Bits:30006252 8" Wang WCS floppy, CR 0096K
└─ ⟦this⟧ »2071A «
WangText
%…06…%…07…$…0a…$…0b…$…0e…$…0f…$…05…$…06……86…1
…02… …02…
…02… …02…
CHAPTER
6
Page
#
DOCUMENT
III
TECHNICAL
PROPOSAL
Apr.
29, 1982
6.7.3.3 T̲h̲e̲ ̲A̲C̲D̲N̲ ̲i̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲t̲o̲ ̲V̲I̲A̲
This chapter describes the interface between the ACDN
and the VIA-host (UNIVAC 1110).
The software residing in the host will have to be modified
so that an extra PIU may be recognized. Apart from
this, the basic concept of the interface is, that no
changes will have to take place in the UNIVAC 1110
host software.
The functional components supporting the VIA -host
are shown in fig.III 6.7.3.12.
fig. 6.7.3.12…86…1 …02… …02… …02… …02…
The protocols used to support the VIA-host will apply
to the ISO-OSI model in the manner described in fig.
III 6.7.3.13.
It is obvious that the ISO-OSI framework does not apply
very well to the existing VIA-interface as the layered
approach did not exist when the interface was designed
and implemented.
As the basic idea of this interface is that as few
changes as possible will have to take place in the
VIA-host, the design will have to reflect the current
systems structure. This means that not only will the
used buffer formats have to be the same, but also the
logical structure of the terminal network must appear
the same as in the current system.
fig. 6.7.3.13
The current network seen from the VIA host is shown
in fig III 6.7.3.14 (taken from RFT, part 4, chapter
3, page 3).
The network is a pure star network with a number of
terminal-line concentrators connected to a front-end
processor system. the front-end processor system consists
of a number of PCTG's (based upon DEC's PDP11/05),
the Collins Radio C8816A-2 Processor Interface Units
(PIU) linking the ISI channel of UNIVAC 1110 to the
Collins time division exchange.
The channel appears for the VIA-host system as a pool
of individually addressable, buffered I/O devices.
Fig III6.7.3.14…86…1 …02… …02… …02… …02…
T̲h̲e̲ ̲P̲I̲U̲ ̲
The processor interface unit provides the electrical
and logical interface to connect an 1110 input/output
channel to the C-System time division exchange. The
processor interface unit occupies one 1110 input/output
channel and one party line address of a time division
exchange channel in the C-System. It recognizes 16
separate device addresses and is thus operationally
equivalent to 16 buffered I/O devices operating from
the single 1110 input/output channel. An I/O command
for each of the 16 device addresses can be stored in
the processor interface unit, which in effect provides
16 separate and independent transmission channels.
Each transmission channel can be assigned to a particular
communication function such as control input, common
system input, or C-System processor output. These
channels may be assigned according to type and priority
to traffic. Refer to fig. III 6.7.3.15.
The processor interface unit operates in the internally
specified index (ISI) mode and adheres to the standard
signal sequences defined for the Univac input/output
channel. Data is transmitted at a rate up to 2 megabits
per second in variable block sizes.
The 1110 input/output channel sees the processor interface
unit as a controller that accepts and decodes commands.
Message segments are transferred to core memory in
the ISI mode.…86…1 …02… …02… …02… …02…
fig. III 6.7.3.15…86…1 …02… …02… …02… …02…
O̲p̲e̲r̲a̲t̲i̲o̲n̲
Buffered I/O operation requires two 1110 channel instructions
for each read or write operation and allows release
of the 1110 channel between the two instructions.
The first instruction transfer the preparatory function
code that enables the processor interface unit and
readies it for the matching C-System command. Immediate
release of the 1110 channel frees it for other work.
Upon receipt of a matching C-System command, the processor
interface unit causes an external interrupt in the
1110 and transfers a status word that contains the
preparatory function code and the device address on
which the match occurred. The 1110 then executes the
second instruction (load-output-channel or load-input-channel
instruction), which starts the data transfer.
If the 1110 desires information from the C-System,
the 1110 begins by issuing a read function code to
the processor interface unit. The processor interface
unit stores the read code in its address register and
causes the 1110 channel to deactivate by returning
an output data request signal. When the C-System processor
subsequently issues a matching write command to the
processor interface unit, specifying the same processor
interface unit device address, the processor interface
unit sends an external interrupt to the 1110 processor
and transfers a status word containing the 1110 read
code and its processor interface unit device address.
The 1110 services the interrupt and executes a second
instruction (load-input-channel instruction) to start
data transfer. Data transfer then takes place with
the processor interface unit transferring 32-bit words
from the C-System to the 1110 processor one word at
a time with each 8-bit ASCII byte translated in to
9-bit ASCII quarter word with the high order bit set
to zero. The transaction terminates with the transfer
of status information to both processors…86…1 …02…
…02… …02… …02…
When the 1110 desires to transmit information to the
C-System rather than request information, the operation
is essentially the same. The 1110 issues an initial
write function code to a particular address. The C-System
subsequently issues a read command to the same address,
resulting in a command match and issuance of a second
instruction (load-output-channel instruction) by the
1110 processor. Data transfer takes place and the
transaction terminates with the transmission of status
information to both processors.
In the VIA-host all PIU ports are assigned a Port Index
(PIX). Each of the two PIU's have a PIU number (10
and 1).
The current PIX-values, PIU-numbers and port numbers
association with usage is shown in table III 6.7.3.1.…86…1
…02… …02… …02… …02…
PIU Port
P̲I̲X̲ N̲u̲m̲b̲e̲r̲ N̲u̲m̲b̲e̲r̲ N̲e̲t̲w̲o̲r̲k̲ U̲s̲a̲g̲e̲
1 0 0 Y Input Control
2 1 0 Y "
3 0 8 G "
4 1 8 G "
5 0 2 Y C/S input
6 1 2 Y "
7 0 10 G "
10 8 1 10 G "
11 9 0 3 Y "
12 10 1 3 Y "
13 11 0 11 G "
14 12 1 11 G "
15 13 0 4 Y S/F input
16 14 1 4 Y "
17 15 0 12 G "
20 16 1 12 G "
21 17 0 1 Y Output Control
22 18 1 1 Y "
23 19 0 9 G "
24 20 1 9 G "
25 21 0 6 Y C/S Output
26 22 1 6 Y "
27 23 0 14 G "
30 24 1 14 G "
31 25 0 7 Y S/F Output
32 26 1 7 Y "
33 27 0 15 G "
34 28 1 15 G "
Table III 6.7.3.1
Two types of traffic exist as seen from the VIA-host.
C/S input/output that is the core stored fast type
of traffic, and S/F input/output that is the store
and forward, i.e. slow, type of traffic.
Three queue types exist in the host to take care of
output:
- one covering the C/S type and control
- one covering the S/F type called TDP
- one covering the S/F type called TTY
TDP and TTY output is divided into three priority classes.
The implementation of this queue structure is reflected
in table III 6 7.3.2
PIU
Q̲u̲e̲u̲e̲ N̲e̲t̲w̲o̲r̲k̲ T̲y̲p̲e̲ P̲r̲i̲o̲r̲i̲t̲y̲
POQCLY Y Control all
POQCSY Y C/S all
POQSFY Y TDP 0,1
" Y TDP 2
POQSFY1 Y S/F 0,1
" Y S/F 2
POQCLG G Control all
POQCSG G C/S all
POQSFG G TDP 0,1
" G S/F 0,1
POQSFG1 G S/F 0,1
Table III 6.7.3.2
T̲h̲e̲ ̲c̲o̲n̲c̲e̲p̲t̲ ̲o̲f̲ ̲t̲h̲e̲ ̲V̲I̲A̲-̲i̲n̲t̲e̲r̲f̲a̲c̲e̲
To reflect the structure briefly quoted above, the
implementation of the VIA-host-network interface is
covered as shown in fig. III 6.7.3.16 and III 6.7.3.17
Fig. III 6.7.3.16
Fig. III 6.7.3.17
The conceptual overview of the VIA-interface in the
HAS (fig. III 6.7.3.16) consists of the main elements
called CHN. HDL., which is the channel handler in the
HAS and the EUP, which is the end user process in the
HAS.
Apart from the shown items, a physical ISI word channel
exists. The following will give more details on the
three main items:
- physical word channel
- channel handler
- end user process
T̲h̲e̲ ̲P̲h̲y̲s̲i̲c̲a̲l̲ ̲W̲o̲r̲d̲ ̲C̲h̲a̲n̲n̲e̲l̲ ̲L̲i̲n̲k̲
The 1100 interface is channel based and consists of
one UNIVAC word channel pair, one channel for input
and one for output. The protocol is full duplex.
A channel connects the UNIVAC IOU (IOAU) to a controller
called a subsystem. The HAS can be regarded as a subsystem.
O̲u̲t̲p̲u̲t̲ ̲C̲h̲a̲n̲n̲e̲l̲
The output channel contains the following control and
data lines:
- Subsystem clear (1 bit)
A control signal sent by the IOU (IOAU) to the
subsystem. The subsystem responds to this signal
by stopping all subsystems activity, initiating
a master clear in the subsystem, and turning on
the ODR signal.
- Output Data Request (ODR) (1bit)
A control signal sent by the subsystem to the IOU
(IOAU) to indicate that the subsystem is ready
to receive an output data word or function word.
When the subsystem turns on the ODR signal it
holds it on until after an output data word or
function word has been received.
- Output data word (36 data bits + 2 parity bits)
A word read from main storage by the IOU (IOAU)
and sent to the subsystem via the output data lines.
An output data word is accompanies by an OA signal.
A function word is accompanies by an EF signal.
Each half word is accompanied by a parity bit,
the parity being odd.
- Output Acknowledge (OA) (1bit)
A control signal from the IOU (IOAU) to indicate
to the subsystem that an output data word is on
the output data lines. The OA signal is a single
pulse.
- External Function (EF) (1 bit)
A control signal from the IOU (IOAU) to indicate
to the subsystem that a function word is on the
output data lines. The EF signal is a single pulse.
I̲n̲p̲u̲t̲ ̲C̲h̲a̲n̲n̲e̲l̲
The input channel contains the following control and
data lines:
- Input Data Request (IDR) (1 bit)
A control signal to the IOU (IOAU) to indicate
that the subsystem is presenting an input data
word on the input word lines. When the subsystem
turns on the IDR signal, it normally holds it on
until the Input Acknowledge (IA) signal is received
from the IOU (IOAU).
- Input Data Word (36 data bits + 2 parity bits)
A word sent by the subsystem to the IOU (IOAU)
via the input data lines. The IOU (IOAU) writes
the word into main storage. An input data word
is accompanied by an IDR signal. An input function
word is accompanied by an EI signal. The subsystem
normally holds the word on the input data lines
until it receives the IA signal. Parity is the
same as in the output data word.
- Input Acknowledge (IA) (1 bit)
A control signal sent by the IOU (IOAU) to indicate
than an input data word or status word has been
accepted. The IA signal is a single pulse.
- External Interrupt (EI) (1 bit)
A control signal to the IOU (IOAU) which indicates
that the subsystem is presenting a status word
on the input data lines. When the subsystem turns
on the EI signal, it normally holds it on until
the Input Acknowledge signal is received from the
IOU (IOAU).
D̲a̲t̲a̲/̲F̲u̲n̲c̲t̲i̲o̲n̲/̲S̲t̲a̲t̲u̲s̲ ̲T̲r̲a̲n̲s̲f̲e̲r̲s̲
Data is transferred to/from the subsystem as 32 bit
words and to/from the channel as 36 bit words. The
mapping is done so that four subsystems 8 bit bytes
are put into their corresponding 9 bit channel quarter
words.
This applies for all but certains words used to contain
address images in the logical protocol (AIRCAM)
Function words are presented in the same way as data
but only the 2 least significant bytes are used in
the 32 bit parallel transfer.
Each word channel module contains 4 word channels.
The maximum data transfer rate is 500 K words per
second per channel module, each word containing 4 9
bit bytes.
T̲h̲e̲ ̲C̲h̲a̲n̲n̲e̲l̲ ̲H̲a̲n̲d̲l̲e̲r̲
The channel handler shown in fig. III 6.7.3.16 is the
program that controls the flow between the physical
channel (CR8037D UNIVAC interface) and the EUP.
The work of the CHN is based upon the same philosophy
as the PIU. It maintains a number of command registers,
one per device address recognized in the system. These
command registers are the base for the operation of
the channel handler telling it what to do.
The command registers may be updated either from the
VIA-host or from an ASI-task (Application Services
Interface) in the EUP.
The CHN.HDL. decodes and uses six function codes from
the 1110 processor. Functions and corresponding codes
are shown in figure III 6.7.3.18. The read and write
functions are used to initiate data transfers.
The control function code is sent to the ASI-task in
a status word by the CHN HDL on the next read or write
command issued by the ASI to the matching device address.
An exception to the above is the use of a stop function
to signal the end of an 1110 write transaction.
FUNCTION BIT POSITION
7 6 5 4 3 2 1 0
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
CLEAR 0 0 0 0 0 0 0 0
SENSE 0 0 0 0 0 1 0 0
WRITE 0 0 0 0 C C 0 1
READ 0 0 0 0 0 0 1 0
CONTROL X X X X X X 1 1
STOP 1 1 1 1 1 1 1 1
Notes:
1. X may be 1 or 0 (all x must not be 1)
2. CC control bits for code conversion (not used)
00 Translator converts 9 bits to 8 bit ASCII
01 Translator converts field data to 8 bit
ASCII (Optional Feature)
11 Undefined
10 Transparent Data Mode
Figure III 6.7.3.18…01…1110 Function Codes
A sense function is issued by the 1110 when the status
of a particular device address is required. The channel
handler responds with an external interrupt and a status
word. The status word contains the required information.
The sense function also may be issued to gain detailed
status information on the channel handler. Receipt
of a sense function by the channel handler will cause
18 bits from the device status word register in the
channel handler to be sent to the 1110. The device
status word register contains current status information
and error indications that are also available to the
ASI in response to its status command. The 1110 sense
function does not involve the ASI and is completed
entirely by the channel handler and the 1110 channel.
The clear function is used to clear the channel handler
of preparatory functions. The processor interface
unit address register specified in the function word
is set to zero. Simultaneous clearing of all device
addresses is provided by the 1110 master clear control
line, which is under operator control or by an INITIALIZE
command from the ASI.
The function codes along with the corresponding device
addresses are presented to the channel handler in the
following function format:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
0 FUNCTION ADR 0
6 8 4
18
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
35 BITS
0
ASI Commands
The ASI issues write, read, status, initialize, diagnostic
status, and dual status command to the channel handler.
The device command word is the first word transmitted
to the channel handler by the ASI and has the following
format:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
PIU ADDR COMMAND DEV ADDR CONTROL
BYTE
8 8 8 8
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
0 BITS 31
The processor interface unit address field (PIU ADDR)
is not used. The device address field (DEV ADDR) specifies
the 1110 device address that is used to check for a
matching command from the 1110.
The control byte field is not used for the read, write,
initialize, status, and diagnostic status commands.
For the dual status command, this field will contain
control data for transfer to the 1110 as part of the
1110 status word.
The command filed with command coding is shown in fig.
III 6.7.3.19.
An ASI write command is sent to the channel handler
and, if a matching 1110 read function is not found
at the specified address, the channel handler will
terminate the transaction with a device status word
to the ASI. If a matching 1110 read function is found
at the specified address, the channel handler will
request a file segment from the ASI (a word at a time)
and transfer it to the 1110. Upon termination of data
transfer, the channel handler will return a device
status word to both the ASI and 1110 processors.
COMMAND BIT POSITION
8 9 10 11 12 13 14
15
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
WRITE 1 0 1 C C 0 0
0
READ 0 1 1 0 0 0 0
0
STATUS 1 1 0 0 0 0 0
0
INITIALIZE…02…1 1 0 0 0 0 0 0
DIAGNOSTIC STATUS 0 0 0 0 0 0 0
0
DUAL STATUS 1 1 0 0 0 0 1
1
NOTES:
1. 1 is idle bit, when Logic 1, the interface unit
sets summary error bit (bit 18) of device status
if the interface unit is idle.
2. CC control bits for code conversion
00 Translator converts 8 bit to 9 bit ASCII
01 Translator converts 8 bit ASCII to Fieldata
(Optional Feature)
11 Undefined
10 Transparent Data Mode
Fig. III 6.7.3.19 ASI Commands
An ASI read command operates in the same manner as
the write command except that the file segment will
pass from the 1110 via the specified device address
to the requesting ASI.
The ASI status command is used to request a device
status word from the channel handler via the specified
1110 device address. No change will be made to the
channel handler control registers except to return
a device status word. The device status word will
contain the 1110 function code, if any, present in
the device register.
The ASI initialize command restores the channel handler
to an idle state and causes a device status word to
be returned to the ASI and to the 1110.
The ASI diagnostic status command causes the channel
handler to return a 32 bit diagnostic status word to
the ASI.
The ASI dual status command causes the channel handler
to present as status to the 1110 the control byte contained
in the command word from the ASI. This byte becomes
the rightmost 8 bits of the 36 bits 1110 word.
T̲h̲e̲ ̲A̲S̲I̲ ̲(̲A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲S̲e̲r̲v̲i̲c̲e̲s̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲)̲
Apart from the functions mentioned above the ASI has
the task to route data to the various TAS' of the network.
This is done by maintaining a table of the LID to
TAS relation. This relation gives an address to a
TSU (Transport Station User) that is one end of a path
to a specific TAS.
T̲h̲e̲ ̲T̲A̲S̲ ̲E̲U̲P̲
The TAS EUP (ref. fig. III 6.7.3.17) contains the necessary
tasks to carry the traffic to the VIA-host. These
are:
- TSU (Transport System User)
- EM (Emulator)
The TSU and the EMulators are covered elsewhere in
this tender document, but the specific functions needed
to support the VIA-host will be briefly explained here.
The TSU of the TAS-VIA-host interface is different
from the simple one shown in the HAS and most commonly
used in other network implementation. The TAS-EUP-TSU
maintains a table giving the relation between a specific
LID and an EMulator address in the EUP. This is done
to minimise the transport network resource usage.
The EMulators used by the VIA-host interface will issue
the data buffers to the TSU with the header format
shown in fig. III 6.7.3.20.
Fig. III 6.7.3.20
Type Code O/60 X'70 single segment or no text.
0/64 X'74 first segment
0170 X'78 intermediate segment.
0174 X'7C last segment.
FC Filler count - location of the last character
in the last word
0 = Q4, 1 = Q3, 2 = Q2, and 3 = Q1.
PIU PIU number 0 - 3
Port Port number over which the message is being
transmitted.
MSN/BSN The message sequence number for Type Codes
0160 and 0164, and the block sequence number
for Type Codes 0170 and 0174. MSN's start
at one and go to 023420 = 9999 before wrapping
to one again.
LID The LID including the network identifier.
PT Printer type.
Burn Time Burn time of output messages.
CM CRT mode.
O for 64 characters per line.
1 for 80 characters per line.
TM Test mode indicator (not used for output).
Pri Message priority.
6.7.4 H̲o̲n̲e̲y̲w̲e̲l̲l̲ ̲H̲o̲s̲t̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
6.7.4.1 D̲i̲s̲t̲r̲i̲b̲u̲t̲e̲d̲ ̲S̲y̲s̲t̲e̲m̲s̲ ̲A̲r̲c̲h̲i̲t̲e̲c̲t̲u̲r̲e̲ ̲(̲D̲S̲A̲)̲
6.7.4.1.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
Honeywell's master plan - Distributed Systems Environment
(DSE) sets up concepts for distributed processing.
One of the elements in this master plan is Distributed
Systems Architecture (DSA) expressing Honeywell's commitment
to ISO's model for Open Systems Interconnections (OSI).
Being in accordance with the ISO model means that DSA
utilizes the HDLC protocol with LAP-B for interprocessor
links.
DSA is an architecture which implies that the functions
and protocols can be implemented in various ways as
long as it adheres to the DSA rules.
DSA being compliant with ISO's OSI model makes it very
convenient to interface to this architecture in ACDN.
6.7.4.1.2 D̲S̲A̲ ̲L̲a̲y̲e̲r̲s̲ ̲a̲n̲d̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲s̲
The DSA architecture is divided in the following seven
layers. (See fig. III 6.7.4.1).
fig. III 6.7.4.1
- A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲L̲a̲y̲e̲r̲
This layer is divided in applications management
(dealing with the programs) and device management
(dealing with the devices). Application management
is the responsibility of the user, where device
management normally will be a part of the system
software.
- P̲r̲e̲s̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲L̲a̲y̲e̲r̲
Reformats or transforms the data as necessary so
it can be transmitted through subsequent DSA layers
and understood by the destination program or device.
The functions can be implemented by any of the
separate protocols:
- Standard Device Protocol
- Transparent Protocol
- Data Description Protocol
- S̲e̲s̲s̲i̲o̲n̲ ̲L̲a̲y̲e̲r̲
This layer takes care of synchronization of two
systems involved in a communication. The functions
are handled by:
- Connection Protocol
- Dialogue Protocol
The Presentation Layer and the Session Layer form together
the Message Management of the DSA architecture. The
four following layers form the Communication Management
and take care of the transport of data between different
sites. Together the four following layers provide
for total end-to-end control of the physical data communication
process:
- T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲L̲a̲y̲e̲r̲
This layer prepares the logical connection set
up by the Session Layer for routing in the physical
network. The Transport Layer performs furthermore
the multiplexing function.
- R̲o̲u̲t̲i̲n̲g̲ ̲L̲a̲y̲e̲r̲
This layer routes network traffic into the correct
links of the physical network. Any of four link
types may be used to complete the connection:
- A dedicated line
- Point-to point communications line
- An X.21 circuit-switched path
- An X.25 packet-switched path with support for
datagram and virtual circuit.
DSA is compatible with all the major public data
networks (e.g. Datapac in Canada).
- D̲a̲t̲a̲ ̲L̲i̲n̲k̲ ̲L̲a̲y̲e̲r̲
The Data Link Layer uses the HDLC protocol of the
X.25 standard and the LAP-B access method.
- P̲h̲y̲s̲i̲c̲a̲l̲ ̲L̲a̲y̲e̲r̲
Honeywell supports various types of interfaces
including RS-232C, RS-449, V.24 and V.25 and connection
to X.21 circuit-switched networks.
Between the various layers there exists standard rules
for passing control information. Some of the more
prominent characteristics of these layer-to-layer routines
include directory based addressing, multiplexing and
multiple connections between two layers, fragmentation
and reassembly of user data, error checking and recovery
schemes and credit based flow control.
6.7.4.1.3 N̲e̲t̲w̲o̲r̲k̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Host systems supporting DSA include DPS 8 with the
operating systems GCOS 8 or GCOS III. If GCOS III
is the operating system, a software gateway is needed
to make the front-end appear as running a GRTS DSE
communication program.
Datanet 8 is the only front-end supplied by Honeywell
with support for DSA. The Distributed Network Supervisor
(DNS) is used as the Datanet's operating system.
Honeywell implements two kinds of networks. The primary
network conforming to the protocols of DSA and the
secondary network with support for TTY, VIP, IBM BSC
and HDLC.
6.7.4.2 I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲D̲S̲A̲
This chapter will describe how Honeywell has implemented
DSA in the DPS 8 product line of processors and how
DSA is implemented in the network.
6.7.4.2.1 I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲i̲n̲ ̲t̲h̲e̲ ̲D̲P̲S̲ ̲8̲/̲7̲0̲
The DPS 8 system is one of the elements in the DSE
master plan. However, the DPS 8 is designed together
with Honeywell's new operating system GCOS 8. GCOS
8 has only been released to a limited number of customers,
meaning that the operating system used on a DPS 8 is
GCOS III.
GCOS III has been designed for use for the Level 66
product line and has no DSA support. This implies that
there must exist a gateway to make the network appear
to GCOS III as something known.
In GCOS III it is possible to execute Master Mode Entry
(MME) instructions putting the processor in master
mode and executing the master mode instructions. Access
of a GRTS or NPS network is done by issuing a MME GEROUT
instruction. But as DNS is not known to GCOS III,
the gateway is doing the mapping so DNS looks like
GRTS to GCOS III.
A user program executing in the direct program access
(DAC) mode uses the MME GEROUT instructions for the
following types of functions:
- Send output to and receive input from a terminal
- Identify a terminal by station identification
- Request a line status or a line disconnect
- Switch Operating Modes
Each MME GEROUT function is identified by a unique
operation code that must be specified in the MME GEROUT
calling sequence.
Fig. III 6.7.4.2 shows the setup with a user program
in DAC mode accessing the DNS network via the GCOS
III Gateway.
When GCOS 8 is commercially available, there will be
a direct support of DNS without a software gateway.
fig. III 6.7.4.2
6.7.4.2.2 I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲i̲n̲ ̲t̲h̲e̲ ̲N̲e̲t̲w̲o̲r̲k̲
Honeywell uses the Datanet 8 as front-end, concentrator
and switch in the DSA network. The Datanet uses the
Distributed Network Supervisor (DNS) as operating system.
DSA support will not be available on older models
of the Datanet.
DNS supports the four layers of the Communications
Management. Furthermore, a number of administrative
routines are performed by DNS, including:
- Network monitoring
- Software loading
- Dumping
- Data logging for statistics
- Billing
- Maintenance
- Online diagnostic testing
- Software generation
These network management functions are distributed
throughout the DSA layers and are available in any
DSA node or front-end.
Three programs facilitate network management in a DSA
network:
- Network Operator Interface (NOI)
- Network Administration Storage Facility (NASF)
- Node Administrator (NAD)
NOI provides operators with access to the network administration
functions. NASF is responsible for collecting records
on network activities and operations, statistics, error
information, network and node configuration parameters
and access control tables. NAD is an application program
that is required in every DSA node. It executes various
supervisory and control functions under the command
of the NOI. While NOI and NAD will reside in the nodes
of the network, NASF will normally reside in the host.
The intention with NASF is to distribute it out in
the network, but this facility is not supported for
the moment.
The DSA network is divided into a primary network (pure
DSA interprocessor network) and a secondary network
with terminal support. In the secondary network, there
is support for all the major Honeywell protocols and
for IBM 3270 BSC.
Fig. III 6.7.4.3 shows the functions performed by the
Datanet 8 and the DPS 8/70. Please note that there
are no communication management functions in the DPS
8/70 host.
fig III 6.7.4.3
6.7.4.3 M̲a̲p̲p̲i̲n̲g̲ ̲A̲C̲D̲N̲ ̲o̲n̲t̲o̲ ̲D̲S̲A̲
6.7.4.3.1 -̲F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
ACDN can be mapped onto DSA in three various ways:
- Connection of the Datanet 8 to HAS
- DIA channel connection to HAS
- PSIA channel connection to HAS
The reason for having the first alternative is that
there exists no transport control facilities in the
host that complies with the ISO OSI reference model.
Therefore it is more feasible to interface to the
Datanet 8, because end-to-end control is implemented
in the Transport Layer of the Communication Management.
The DIA connection is the normal way Honeywell will
attach a Datanet to the host system. The MME GEROUT
instructions are used when accessing the network operating
system in the front-end.
The PSIA connection is used by Honeywell to attach
peripheral subsystems to the host. CR has developed
a connection for an EAI 640 hybrid computer at ESTEC
in Holland using this interface.
6.7.4.3.2 D̲a̲t̲a̲n̲e̲t̲ ̲8̲ ̲c̲o̲n̲n̲e̲c̲t̲i̲o̲n̲ ̲t̲o̲ ̲H̲A̲S̲
The peer-to-peer connection is from the Transport Layer
of the Communications Management residing in the Datanet
8 and in the Host Access System (HAS) of the ACDN network.
Fig. III 6.7.4.4 shows the functional implementation.
Since the Transport Layer implemented in the Datanet
8 has a clean interface, it is rather convenient to
do the interfacing in the HAS.
6.7.4.3.3 D̲I̲A̲ ̲c̲h̲a̲n̲n̲e̲l̲ ̲c̲o̲n̲n̲e̲c̲t̲i̲o̲n̲ ̲t̲o̲ ̲H̲A̲S̲
The second alternative will connect the HAS system
directly to the Input Output Multiplexor (IOM) of the
DS 8/70 via its Direct Channel.
In order to do this, a channel interface board must
be developed and the necessary software to support
this interface must be developed.
The HAS software depends on whether GCOS 8 or GCOS
III should be the future operating system of the DPS
8/70 host.
Fig. III 6.7.4.5 shows the functional implementation
of the channel interfaced solution.
fig. III 6.7.4.4
fig III 6.7.4.5
The Application Services Interface is the one that
responds to the network access of the host system,
making the HAS appear as the DNS operating system to
the DPS 8/70 host.
