top - download
⟦b853facce⟧ Wang Wps File
Length: 70566 (0x113a6)
Types: Wang Wps File
Notes: Rovsing
Names: »1264V «
Derivation
└─⟦740f46985⟧ Bits:30006253 8" Wang WCS floppy, CR 0097K
└─⟦this⟧ »1264V «
WangText
…00……00……00……00… …0a……00……00… …0b… …0f… …00… …06… …07……1f……0c……1f……02……1e……08……1e……0e……1e……0f……1e……05……1d……0a……1d……0f……1d… …1c……08……1c……00……1c……06……1b……0b……1b……00……1b……05……1a……09……1a……0a……1a……0b……1a……0e……1a……02……1a……06……19……0a……19……0d……19……00……19……86…1 …02… …02… …02… …02…
CHAPTER 6
Page #
DOCUMENT III TECHNICAL PROPOSAL Apr. 29, 1982
6.7.3 U̲N̲I̲V̲A̲C̲ ̲h̲o̲s̲t̲ ̲i̲n̲t̲e̲r̲f̲a̲c̲e̲
…02…This chapter describes in detail the interface between
…02…the ACDN and UNIVAC 1100 hostcomputers. The following
…02…aspects are covered:
…02…- DCA
…02…- Protocols and software for new UNIVAC hosts
- The ACDN interface to VIA
…02…A functional overview is given in fig III 6.7.3 1.
6.7.3.1 D̲i̲s̲t̲r̲i̲b̲u̲t̲e̲d̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲s̲ ̲A̲r̲c̲h̲i̲t̲e̲c̲t̲u̲r̲e̲
o In this chapter the DCA will be presented to give
a
…02……02…background for the implementation proposed for new
…02……02…UNIVAC-host systems.
…02…This Chapter describes the DCA-protocol layers
…02… - End user (EU)
…02……02…- Communication Systems User (CSU)
…02……02…- Termination System (TS)
…02……02…- - Port Flow Control (PFC)
…02……02…- - Logical Port Multiplexor (LPM)
…02……02…- - TS/TN interface
…02……02…- Data Unit Control (DUC)
…02……02…- Remote Trunk Control (RTC)
…02……02…- Trunk Control (TC)
…02……02…- Sub Architectural Interface (SAI).
Fig. III 6.7.3.1
DCA is a conceptual way of describing the functionalities
of a network. DCA is not a specific implementation
of a network. DCA uses the ISO-model of layered protocols
implying, that a communication session from one user
to another via the network must confirm to a specific
set of protocols (or rules).
An overview of the DCA/Telcon implementation is given
in figure III 6.7.3.2.
E̲n̲d̲ ̲U̲s̲e̲r̲ ̲(̲E̲U̲)̲
A network user (also called an end user, EU) will always
be connected to another EU in the network via a system
session. The 2 EU's can as an example be, an interactive
terminal and a user program in the host computer.
The EU-to-EU protocol is in this case determined by
the user program.
C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲S̲y̲s̲t̲e̲m̲ ̲U̲s̲e̲r̲
An EU is always connected to the communications system
(CS) via a so called communications system user (CSU),
see fig. III 6.7.3.2.
The CSU's are interfacing the communication system
(CS) and is the pathway through which the EU connects
to CS. The CSU must always be paired with a (peer)
CSU in the other end of a system session. The paired
CSU's in the above mentioned example could be a virtual
terminal server in a host converting data from and
to the user program.
Fig. III 6.7.3.2
The CSU layer is very loosely defined in DCA terms
and depends fully on the specific implementation in
host and front-end.
In a following sub-chapter we will take a closer look
at the specific UNIVAC 1100 host implementation of
the CSU layer. Here it shall only be mentioned that
the CSU functions will be formatting of EU-data (so
called UDU - User Data Units), network monitoring and
EU-flow control. The term EU-flow control may cover
pacing control to and from an EU.
T̲e̲r̲m̲i̲n̲a̲t̲i̲o̲n̲ ̲S̲y̲s̲t̲e̲m̲ ̲(̲T̲S̲)̲
As mentioned above more EU's may share a logical port
session (fig. III 6.7.3.2). An LP-session is defined
as a communication path from a logical port to another
logical port. The total amount of logical ports in
a Telcon processor (host, nodal, Front End or Remote
Concentrator) is called a Termination System (TS).
Note that the CSU and the TS may be functionalities
in the same processor and that more than one CSU may
connect to the TS.
The TS routes the traffic generated by the CSU to the
Transport Network (TN). TS can be divided into 2 parts,
the Port Flow Control (PFC) and the Logical Port Multiplexor
(LPM).
P̲o̲r̲t̲ ̲F̲L̲o̲w̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲P̲F̲C̲)̲
The Port Flow Control provides for:
- Initialization of an LP-session
- Sequence numbering of data presented to the port
(Port Data Units (PDU's)).
- Acknowledging of PDU…0e…s received.
- Optional retransmission of PDU's for which negative
acknowledge has been received.
- Control of data flow on a LP-session basis.
For each LP-session there will exist a pair of PFC's
controlling the session by exchanging control information.
Data and control information is routed to the Transport
Network (TN) via the other part of the TS, the Logical
Port Multiplexor (LPM).
P̲o̲g̲i̲c̲a̲l̲ ̲P̲o̲r̲t̲ ̲M̲u̲l̲t̲i̲p̲l̲e̲x̲o̲r̲ ̲(̲L̲P̲M̲)̲
The LPM is not a part of the paired-ends concept and
does not exchange data or control messages to a paired
counterpart although LPM's always exist in both ends
of an in LP-session. The LPM is merely a standardized
interface that controls the access from the TS to the
TN.
T̲S̲/̲T̲N̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The functionality of this TS/TN interface is very similar
to the CCITT X.25/3 interface proposed for public data
networks. Apart from functions such as call-request
and call-clear the data and control
formats are similar to the corresponding X.25/3 formats
Since no-call-request packet is defined, the Transport
Network operates with fixed virtual circuits called
TN-sessions. Each session is identified at the TS/TN
level by its logical subchannel number. This number
does not need to be unique in the network since the
path is already established and the logical subchannel
number is only used to define the session at the TS/TN
level.
A number of TS's may be configured to a FEP or node,
in practice only one is internal to the processor whereas
the others are external TS's residing in external devices.
In this way, a FEP or node may have several LP-sessions
described by the same logical subchannel number distributed
on different TS's. Internally each session is defined
uniquely by a processor (node for FEP) number and an
LP-session number. The numbers may be considered as
a channel number and a logical subchannel is considered
full duplex And maps into two simplex internal TN-sessions.
D̲a̲t̲a̲ ̲U̲n̲i̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲
The TN that may consist of one or more processors has
a corresponding interface for the TS controlled by
the socalled Data Unit Control (DUC) layer. The DUC
converts received Port Data Unit|s (PDU's) to internal
transport network packets called Network Data Units
(NDU's) (if the paired receiver TS is connected to
another DUC in a remote processor).
R̲e̲m̲o̲t̲e̲ ̲T̲r̲u̲n̲k̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲R̲T̲C̲)̲ ̲a̲n̲d̲ ̲T̲r̲u̲n̲k̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲T̲C̲)̲
RTC and TC are the protocol layers in the Transport
Network (TN) that takes care of routing and queueing
of packages. The RTC-layer decides which physical
trunk to choose based upon information in the Network
Data Units (NDU) and the route table residing in the
node. The TC-layer gives or receives data-buffers
to/from the trunR-line-handlers or the DUC-level protocol.
S̲u̲b̲ ̲A̲r̲c̲h̲i̲t̲e̲c̲t̲u̲r̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲ ̲(̲S̲A̲I̲)̲
When data is to be transferred from one processor to
another, say a host and a FEP, a physical path is used
for the data transfer. In case of remote TS's attached
to a FEP or a node the Universal Data Link Control
(UDLC) procedure is used. X.25/2 lapb (link access
procedure balanced) is a subset of the link procedure
and is used in the Telcon implementation. The SAI interfaces
are not part of the DCA-concepts and depends upon the
implementation.
S̲u̲m̲m̲a̲r̲y̲ ̲o̲f̲ ̲D̲C̲A̲ ̲C̲o̲n̲t̲e̲p̲t̲s̲
DCA is a set of rules that builds the frames into which
the implementator, puts the suitable procedures and
data formats. Figure 6.7.3.3 shows how the protocol
layers are passed as a message is transferred from
one EU via a system-session to another EU.
Fig. III 6.7.3.3
The following steps apply to the figure: A terminal
signs on to the network via the line protocol handler.
The message goes to the Virtual To Real (VTR) and
gets formatted before the message is delivered to the
data management facility. The Data Management Facility
(DMF) sends the canned sign-on message back to the
terminnl when the necessary system resources become
available. Then, optionally an 'open' request is sent
to the paired DMF-port. The paired DMF Data may now
be sent. Data received from the EU is now multiplexed
to a logical port via the PFC layer. From this point
on the data, now called PDU's, is routed to the node
processor via an UDLC SAI. The PDU is split into packets
called Network Data Units (NDU's) by the DUC and is
delivered to Remote Trunk Control (RTC). RTC finds
the trunk through which the packet is to leave the
node. Trunk Control (TC) selects the physical channel
within the trunk and queues the packets to the Sub
Architectural Interface (UDLC). When the packets reach
the FEP, RTC selects the DUC and the DUC assembles
the NDU's into PDU's.
The full PDU is passed over to the host via a channel
(SAI) and is presented to the host's TS. Retransmission
of PDU's are supported at the PFC level. The PDU's
are converted into EU data, so called User Data Units
(UDU) by one of the host CSU's and presented to the
user program (TIP, Demand or Batch).
6.7.3.2 P̲r̲o̲t̲o̲c̲o̲l̲s̲ ̲a̲n̲d̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲f̲o̲r̲ ̲N̲e̲w̲ ̲U̲n̲i̲v̲a̲c̲ ̲H̲O̲S̲T̲S̲
This Chapter contains three parts describing the UNIVAC-dependent
protocols and their implementation in the ACDN.
- CMS1100 1R1
- Telcon 3R1B (4R1)
- ACDN implementation for new UNIVAC hosts
The Univac implementation of the DCA-concept is called
the TELCON-system and is implemented as the CMS 1100
module in the UNIVAC 1100 hosts and at the Telcon module
in the various UNIVAC DCP/40 that may be part of the
system.
C̲M̲S̲ ̲1̲1̲0̲0̲ ̲1̲R̲1̲
CMS 1100 implements the DCA-concept for the series
1100 hosts. It provides communications and network
capabilities for the operating system of the UNIVAC
1100 series hosts, called OS 1100.
CMS 1100 provides users with remote connections from
UNIVAC 1100 hosts to other hosts, interactive terminals,
and remote batch stations. The external devices supported
are:
- Distributed Communications Processor (DCP)
- General Communications Subsystem (GCS)
- Communications Terminal Module Controller (CTMC)
The DCP provides network conections to hosts, interactive
terminals, and remote batch stations. The currently
supported hosts are:
- UNIVAC 1100/XX
- DCP as remote concentrator
- V77 as DCA-terminals
The GCS and CTMC are UNIVAC's old front-end-processors
that provide connections to interactive terminals.
No further discussions of these external devices will
take place in this document.
The protocols covered by CMS 1100 are:
- Word channel Sub Architectural Interface (SAI)
- Termination System to Transport Network interface
(TS/TN)
- Port Flow Control (PFC)
- System Session Control (SSC)
- Interactive-1 (INT-1)
- Remote Batch (RB-2)
- Telcon Console Interface
These protocols will be described in detail in this
chapter.
C̲M̲S̲ ̲1̲1̲0̲0̲ ̲D̲C̲A̲ ̲R̲e̲l̲a̲t̲i̲o̲n̲s̲h̲i̲p̲
CMS 1100 supports those Distributed Communications
Architecture (DCA) layers that are not provided elsewhere
in the Series 1100 Operating System. That is, the
functionality of DCA is supported without duplication
of functions. CMS 1100 is structurally patterned after
the DCA architecture. The relationship of CMS 1100
and DCA is outlined below.
L̲o̲g̲i̲c̲a̲l̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The CMS 1100/DCA network consists of three main logical
elements:
- Termination System (TS)
- Applications Environment (AE)
- Transport Network (TN)
T̲e̲r̲m̲i̲n̲a̲t̲i̲o̲n̲ ̲S̲y̲s̲t̲e̲m̲
The Termination System (TS) comprises the interface
code which adapts data, address, and control formats
to and from the Communications System. It provides
the mechanism that permits paired Communications Systems
Users (CSUs) to communicate and regulate the flow of
information between the paired CSUs.
The TS consists of a Port Flow Control (PFC) and a
Logical Port Multiplexer (LPM). The Logical Ports
(LP) are the logical conduits through which users access
the Communications System. An LP provides the path
between the CSUs who in turn provide the sub-path to
individual terminals and applications. The sub-paths
are called "system sessions" or "sessions".
The functionality of an LP is provided by the Port
Flow Control (PFC) module. These functions may be
unique to each LP, common to one set of LPs used by
a CSU, or common to all CSUs within a termination environment
(the TS and its CSU).
DCA specifies a complete PFC protocol of which each
LP may use a subset, depending on its flow requirements.
An objective of the PFC is to regulate the flow of
information to and from the paired LPs so an efficient
throughput is maintained without saturating either
of the paired TSs. Thus, the use of the protocol will
depend on the availability of data to be sent by one
TS and the availability of the resources (memory and
processing) at the paired TS. The PFC has an end-to-end
acknowledgement on sets of Port Data Units (PDU) called
acknowledge sets (ACKSET). These data units are the
smallest recoverable entities in the cross-network
data flow.
The Termination System Control within the TS directs
the Port Data to the proper path; either another internal
CSU; or a Sub-Architectural Interface (SAI) to the
Telcon network.
A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲s̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲
Each Applications Environment (AE) consists of one
or more CSU's that interface with the Termination System.
These CSUs provide the control and applications addressing
structure for a number of program segments or for processes
(activities) with some commonality of behavior. These
processes are the End Users (EU).
An example of a CSU is a transaction-handling control
system under which specific application or transaction
segments are run. The transaction programs are the
EUs.
T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲N̲e̲t̲w̲o̲r̲k̲
The Transport Network (TN) is the hardware/software
required to transport the data units from TS to TS.
In the case of a Telcon Network the TN is comprised
of the DCP hardware family and the Telcon System.
W̲o̲r̲d̲ ̲c̲h̲a̲n̲n̲e̲l̲ ̲S̲u̲b̲ ̲A̲r̲c̲h̲i̲t̲e̲c̲t̲u̲r̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
I̲S̲I̲ ̲C̲h̲a̲n̲n̲e̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The ISI channel interface supports the distributed.communications
processor. This interface module called the standard
network channel handler (NCH) controls the channel
via an I/O device handler. This interface is a standard
that allows any computer to be utilized as a DCP if
the defined protocol is followed. The interface protocol
provides for error checking, recovery, and information
unit segmentation and reconstruction. Buffer acquisition
is made from the CMS 1100 Buffer Management Pool.
The I/O handler tables external and monitor interrupts
into a designated CMS 1100 area and gives control to
a specific interrupt activity defined by CMS 1100.
T̲h̲e̲ ̲p̲h̲y̲s̲i̲c̲a̲l̲ ̲S̲A̲I̲ ̲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 front-end can be regarded
as a sub-system.
O̲u̲t̲p̲u̲t̲ ̲C̲h̲a̲n̲n̲e̲l̲
The output channel contains the following control and
data lines:
o Subsystem clear (1 bit)
A control signal sent by the IOU (IOAU) to the
sub-system. The sub-system responds to this signal
by stoping all sub-systems activity, initiating
a master clear in the sub-system, and turning on
the ODR signal. This signal is not used by the
TELCON system.
o Output Data Reuest (ODR) (1bit)
A control signal sent by the subsystem to the IOU
(IOAU) to indicate that the sub-system is ready
to receive an output data word or function word.
When the sub-system turns on the ODR signal it
holds it on until after an output data word or
function word has been received.
o Output data word (36 data bits & 2 parity bits)
A
word
read
from
main
storage
by
the
IOU
(IOAU)
and
sent
to
the
sub-system
via
the
output
data
lines.
An
output
data
word
is
accompanied
by
an
OA
signal.
A
function
word
is
accompanied
by
an
EF
signal.
Each
half
word
is
accompanied
by
a
parity
bit,
the
parity
being
odd.
o Output Acknowledge (OA) (1bit)
A control signal from the IOU (IOAU) to indicate
to the sub-system that an output data word is on
the output data lines. The OA signal is a single
pulse.
o External Function (EF) (1bit)
A control signal from the IOU (IOAU) to indicate
to the sub-system 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:
o Input Data Request (IDR) (1bit)
A control signal to the IOU (IOAU) to indicate
that the sub-system is presenting an input data
word on the input word lines. When the sub-system
turns on the IDR signal it normally holds it on
until the Input Acknowledge (IA) signal is received
from the IOU (IOAU).
o Input Data Word (36 data bits + 2 parity bits)
A word sent by the sub-system to the IOU (IOAU)
via the input data lines. The IOU writes the word
into main storage. An input data word is accompanied
by an IDR signal. An input function sub-system
normally holds the word on the input data lines
until it receives an IA signal. Parity is the
same as in the output data word.
o Input Acknowledge (IA) (1bit)
A control signal sent by the IOU (IOAU) to indicate
that an input data word or status word has been
accepted. The IA signal is a single pulse.
o External Interrupt (EI) (1 bit)
A control signal to the IOU (IOAU) which indicates
that the sub-system is presenting a status word
on the input data lines. When the sub-system turns
on the EI signal it normally holds it on until
the Input Acknowledge signal is recieved 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 sub-system as 32 bit
words and to/from the channel as 36 bit words. The
mapping is done so that four sub-system 8-bit bytes
are put into their corresponding 9-bit channel quarter
words.
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.
L̲o̲g̲i̲c̲a̲l̲ ̲S̲A̲I̲ ̲L̲i̲n̲k̲
The SAI logical link between the DCP and the 1100 host
is based upon a cross-channel procedure.
Data to be transmitted via the channel is formatted
as PDUs (Port Data Units). The length of a PDU is
not fixed but depends upon the length of the Port
Data and other PDU-contained information. Each PDU
is broken down into SUB-PDUs. The maximum SUB-PDU
length is configurable and the default is 57 36-bit
words, giving 228 bytes including the SUB-PDU Header.
The SUB-PDU format is as seen in figure 6.7.3.3.
Each SUB-PDU contains a First (A) and Last (B) flag
if the SUB-PDU is the first or last part of the PDU.
The offset is the number of bytes following the checksum
before the start of significant PDU data bytes. CHECKSUM1
is an XOR of the odd numbered bytes and CHECKSUM2 is
an XOR of the even numbered bytes.
The logical SAI link is responsible for:
- Error detection
- Flow control
- Data acknowledgement
The protocol is a full duplex protocol. Flow control
is achieved via a window mechanism, the window size
being configuration dependent (default value is 7).
Error control is based upon checksum check and ACK/NAK
sequences.
Two types of data can be transferred via the channel:
- Normal data (SUB-PDUs)
- External Function codes (EFs)
The EF is transferred from the FEP as an external interrupt
and to the FEP as an external function. The format
of the EF is as seen in figure 6.7.3.4.
A=0 If and only if data preceded the EF across
the channel.
B=0 Normal acknowledge
1 Not used
2 Acknowledge but stop sending data
3 NAK (reason code in D)
4 SUP start up probe
5 ILB initial load block request
6 LOD ensuing load block requests for data
7 DMP dump block data or acknowledge
C= Next block number unless A=O in which case
it is the block number (rolls back to 0 after
reaching 7)
Fig. III 6.7.3.4
Fig. 6.7.3.5
D= Reason code for NAK
…02… 0= Not used
…02… 1= Data CMKSUM Error or EF word error
…02… 2= Bad control word field
…02… 3= Invalid message length
…02… 4= Facilities tight
…02… 5= Bad block number sent
E= Acknowledge number
This is = to the next send number expected from
the other side except with a SUP in
which case it indicates of first block
from SUP sending side. It acknowledges
all previous outstanding blocks.
F= Parity bit (set or not set to assure that an
odd number of the 18, excluding bit 9 and bit
18, bit fields will be set).
N/U= Not used
S̲t̲a̲r̲t̲ ̲u̲p̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲
The host sends SUP-EF's at regular intervals, until
the FEP answers by sending a SUP. The host will then
send an ACK that must be answered by ACK from the FEP
before normal data transfer may commence.
D̲a̲t̲a̲ ̲t̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲
Transmitted data blocks (SUB-PDUs) are always followed
by an EF. The EF includes A=0, B=0 or 2 C=next block
number to send and E=next block number to receive.
B=0 indicates a normal acknowledge.
B may be set equal to 2 to indicate that the sender
is unable to receive more data for the moment. A subsequent
ACK indicates that the sender is ready again.
NAK's and SUP's will always be sent without preceeding
data, i.e. as EF with A=1.
Upon reception of a NAK the sender will retransmit
SUP-PDUs starting with the specified ACK number.
R̲e̲s̲t̲a̲r̲t̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲
Either side may decide to re-start the link. Restart
is initiated by transmitting a SUP indicating the new
send sequence number in the E-field. The receiver
will then answer by sending SUP indicating its next
send sequence number. The sender and receiver will
then exchange ACKs and the link is re-established.
S̲h̲u̲t̲ ̲d̲o̲w̲n̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲
The link can only be shut down upon decision from the
host. The FEP will not be notified until the start-up
procedure is invoked.
P̲D̲U̲ ̲A̲s̲s̲e̲m̲b̲l̲y̲/̲d̲i̲s̲a̲s̲s̲m̲b̲l̲y̲
Received SUB-PDus are assembled into PDUs. The first
and last SUB-PDU are marked by the F/L flags in the
header. The valid data starts after the checksum
word indexed by the offset. PDUs are disassembled
accordingly.
T̲e̲r̲m̲i̲n̲a̲t̲i̲o̲n̲ ̲S̲y̲s̲t̲e̲m̲ ̲t̲o̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The TS/TN interface is an interface that
- controls the rate at which data flows between the
TS and the transport network control on logical
port sessions.
- identifies which logical port data is or coming
from
- initialized or re-initializes the TS.
- re-initializes the LP-session
- reports "undeliverable message" (UDM) in the network.
The interface is a subset of X.25/3 in the sense that
not all packet types are implemented, and that each
PDU is treated as one packet.
The following packet types exist:
- DATA
- RR
- RNR
- Reset request (indication) or confirmation
- Restart request (indication) or confirmation
- Switch reset
The TS/TN header is three or four octets long. In
the first word the first bit is an error bit, the next
three is a format identifier (fixed "001"), and the
last four bits contain in conjunction with the 2nd
octet a 12 bit logical sub-channel. The 3rd octet
contains a command field.
C̲o̲m̲m̲a̲n̲d̲ ̲f̲i̲e̲l̲d̲
3 types of command formats exist:
- Data format:
̲P̲(̲r̲)̲ ̲ ̲0̲ ̲ ̲P̲(̲s̲)̲ ̲ ̲0̲ ̲
P(S): Send sequence number of this PDU (three bits
mod 8)
P(R): Receive sequence number of first not-acknowledged
PDU (three bits mod 8).
Data format is always followed by data.
- Flow control format:
P̲(̲R̲)̲ ̲C̲O̲N̲T̲R̲O̲L̲ ̲(̲5̲ ̲b̲i̲t̲s̲)̲
Control values:
RR (Receive Ready): 00*01
RNR (Receive not Ready): 00101
Data will never follow this format.
- Command format:
C̲o̲m̲m̲a̲n̲d̲ ̲(̲8̲ ̲b̲i̲t̲s̲)̲
C̲a̲u̲s̲e̲ ̲(̲8̲ ̲b̲i̲t̲s̲)̲
The command field may have the following content:
Restart request: 11111011 (0373)
cause : 1 local procedure error
cause : 3 congestion
Restart confirmation: 11111111 (0377)
Reset request: 00011011 (033)
cause : 1 out of order
cause : 3 remote procedure error (UDM)
cause : 5 local procedure error
cause : 7 UDM clear
Reset confirmation: 00011111 (037)
Data will never follow this command.
T̲h̲e̲ ̲s̲t̲a̲r̲t̲ ̲u̲p̲/̲r̲e̲s̲t̲a̲r̲t̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲
When the 1100 or the HIP is loaded or initialized,
the TS/TN layer will send a restart request to the
other side of the link. The other side will initialize
its tables and send a restart confirmation. The two
commands are valid for all logical sub-channels on
the channel and the sub-channel must be equal to zero.
When a TS receives a restart its PFC will send a solicit
status on all logical port sessions configured to it.
A restart confirmation or a restart command is accepted
as reply to a reset command.
R̲e̲s̲e̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲
Used to reset a logical sub-channel when some problem
exists. P(R) and P(S) counters and cleared. A reset
command is sent if a PDU received contains illegal
P(S) or P(R) i.e. not within window or P(S) not next
expected (Cause is 5).
The HIP sends a reset with cause 5 (UDM) if problems
by routing the message to the destination.
Reset confirmation is the expected reply to a reset
command. A reset command will also be accepted as
reply to a reset command.
When the TS receives a RESET, the PFC will send a "solicit
status" to this paired PFC in order to re-initialize
the LP-session.
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲f̲o̲r̲ ̲D̲a̲t̲a̲ ̲T̲r̲a̲n̲s̲f̲e̲r̲
PDU's are transferred using a window mechanism. The
max. window size is 7 (default is 4). The receiver
may control the flow by using the RNR and RR flow control
commands. Retransmission of PDU's is not included
in the protocol. (The TS/TN protocol assumes that
the underlying SAI module can provide a safe transport.)
P̲o̲r̲t̲ ̲F̲l̲o̲w̲ ̲C̲o̲n̲t̲r̲o̲l̲
The PDU's received by the host at the TS/TN-level are
received by the "Logical Port Multiplexor" (LPM) and
delivered to the PFC. PFC analyses the PFC header and
performs the PFC protocol.
PFC provides for:
- Initialisation of a session.
- Sequence numbering of PDU's.
- Acknowledging of PDU's received.
- Optional retransmission of PDU's for which NAK
has been received.
- Control of data flow on a session basis.
A set of paired PFC's exists for each session. The
indidividual PFC may operate in various modes called
classes:
C̲l̲a̲s̲s̲ ̲1̲ ̲(̲B̲a̲s̲i̲c̲)̲
A class 1 PFC operates in "basic mode" which means
that it is unable to retransmit PDU's, i.e. the recieving
PFC must be able to accept PDU's within the current
window. PDU's received by a class 1 PFC will be acked
(if required) without End User (EU) significance, i.e.
the PDU may be acked before it is delivered to the
Port Presentation Service (PPS).
C̲l̲a̲s̲s̲ ̲2̲ ̲(̲R̲e̲c̲o̲v̲e̲r̲y̲)̲
A class 2 PFC operated in "recovery mode" which means
that it is able to hold and retransmit a number of
PDU's called an ACKSET.
C̲l̲a̲s̲s̲ ̲6̲ ̲(̲R̲e̲c̲o̲v̲e̲r̲y̲ ̲w̲i̲t̲h̲ ̲E̲U̲ ̲a̲c̲k̲)̲
A class 6 PFC operated as class 2 but ACK with EU significance
is sent if required.
P̲F̲C̲ ̲H̲e̲a̲d̲e̲r̲ ̲F̲o̲r̲m̲a̲t̲
The PFC header is positioned immediately following
the TS/TN header within the PDU. The PFC header is
defined in a 4-bit header information code (quartet
HIC) scheme. All PFC headers begin and end on octet
boundaries.
Four types HIC quartet code formats are defined:
00XX XXXX (variant) M format
01XX U format
10XX XXXX (length) S format
11XX XXXX XXXX (length) L format
The HIC code is followed by as many quartets as is
given in the length field.
The PFC header may contain more HIC's, the last MIC
being the "end-of-header" (EOH) HIC.
The following HIC's are defined:
H̲I̲C̲ ̲n̲a̲m̲e̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲H̲I̲C̲ ̲V̲a̲l̲u̲e̲ ̲V̲a̲r̲i̲a̲n̲t̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲ ̲ ̲ ̲ ̲ ̲U̲s̲a̲g̲e̲
̲ ̲ ̲ ̲
Minor page change 0000 New page number unused
Unassigned 0001 unused
Unassigned 0010 unused
Receive Ready 0011 0001
Receive not Ready 0011 0010
Resync Numbers 0011 0011
End of Header 0100
Space (pad) 0101
Unassigned 0110 unused
Retransmit 0111
.
Major Page Change 1000 0010 New page# (3 bits) unused
Send # 1001 0010 ssss ssss (PDU # ) unused
Send # 1001 0100 ssss ssss FLaa aaaa unused
Receive number 1010 0010 00aa aaaa (ACKSET #)
Credit Window 1011 0100 rrrr rrrr cccc cccc unused
Set Class 1 1100 0000 0010 0000 0001
Set Class 2 1100 0000 0010 0000 0010
Set Class 3 1100 0000 0010 0000 0011 unused
Set Class 4 1100 0000 0010 0000 0100 unused
Set Class 6 1100 0000 0010 0000 0110
Solicit Status 1101 0000 0000
U̲n̲a̲s̲s̲i̲g̲n̲e̲d̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲1̲1̲0̲0̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲u̲n̲u̲s̲e̲d̲
̲ ̲
ssss ssss is an 8-bit send PDU #
FL are first/last PDU of ACKSET flags
aa aaaa is 6-bit ACKSET#
cccc cccc is 8-bit PDU credit value
rrrr rrrr is 8-bit receive PDU #.
S̲e̲s̲s̲i̲o̲n̲ ̲S̲t̲a̲r̲t̲ ̲u̲p̲/̲R̲e̲s̲t̲a̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲
At system initialization or recovery the PFC modules
exchange start-up sequences for each active terminal
on the logical channel being initialized. The expected
HIC sequence from the initiating PFC is:
1101 0000 Solicit Status
0000 1100 Set Class
0000 0010
0000 0XXX XXX=001 or 110 if from FEP
XXX=0l0 if from host
0011 0011 Resync Number
1001 010* Send Numbers
ssss ssss (PDU #)
00aa aaaa (ACKSET #)
0011 00*1 Receive Ready
0111 0100 Retransmit, End of Header
The ordering of the HIC's within the header is optional
with the restriction that the first HIC must be the
Solicit Status.
The expected HIC response to the Solicit Sequence is:
0011 0011 Resync
110 0000 Set Class
0010 0000
00xx 1001 xx=class of sender: 01,10,11
0100 ssss Send Numbers
ssss (PDU #)
00aa (ACKSET #)
aaaa l0l0 Receive Number
00l0 00aa
aaaa 0011 Receive Ready
0001 0100 End of Header
Again the order of the HICs within the sequence is
optional with the restriction that either the Set Class
or Resync HIC must be the first HIC within the header.
When the initiating PFC receives a Solicit Response
the device should be properly initialized.
The Solicit Response is timed, if the timeout expires
before Solicit Response is received, the Solicit Status
will be repeated once.
In case of Solicit collision the paired PFCs recognize
that initialization is completed.
D̲a̲t̲a̲ ̲T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲
All data PDUs have an 8-bit sequence number that cycles
from 0 to 255. Additionally, when the sending PFC is
operating in recovery mode each ACKSET has a 6-bit
ACKSET number that cycles from 0 to 63. The data PFC
header HICs (without Acknowledge) can be of the following
formats:
(1) Basic procedure:
1001 0010 Send Number
ssss ssss (PDU#)
0101 0100 Space, End of Header
DATA
(2) If use of class 2 or 6:
1001 0010 Send Number
ssss ssss (PDU#)
FLaa aaaa (first & last flags + ACKSET#)
0101 0100 Space, End of Header
DATA
To provide for maximum line utilization a PFC may acknowledge
receipt of data trans-missions with a data PDU block.
This is described in the next section "Data Acknowledgement
Procedure".
D̲a̲t̲a̲ ̲A̲c̲k̲n̲o̲w̲l̲e̲d̲g̲e̲m̲e̲n̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲
The Receive Number HIC is used to acknowledge correctly
received ACKSETs. Since recovery is only possible on
an ACKSET basis, a receiving PFC must inform a sending
PFC that is operating in recovery mode when a retransmission
is necessary, and when the message is received correctly.
If the message is received correctly, then the sending
PFC can release its backup copy of the message and
allow another message to be selected. If a retransmission
is required, the sending PFC must requeue the message
and allow the message to be selected again.
The format of the data acknowledge HIC sequences are:
1010 0010 Receive Number
00aa aaaa (ACKSET #)
0101 0100 Space, End of Header.
More efficient line utilization may be obtained if
the Receive Number is included in the PFC header of
a data PDU going in the other direction.
The format of this HIC sequence is:
1001 0010 Send #
ssss ssss (SEQ #)
1010 0010 Receive #
00aa aaaa (ACKSET #)
0101 0100 Space, End of Header
or
1001 0100 Send #
ssss ssss (Seq #)
FLaa aaaa (ACKSET #)
1010 0010 Receive #
00aa aaaa (ACKSET #)
*
0101 0100 Space, End of Header
When acknowledge is being sent within a data buffer,
the Send Number HIC must be the initial PFC HIC in
the sequence.
R̲e̲t̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲
When an error is detected in any message received by
a receiving PFC, the PFC may obtain a retransmission
by returning a Retransmit HIC. In this case the Retransmit
HIC must be accompanied by a Receive Number HIC that
supplies the ACKSET Number of the last ACKSET correctly
received.
The format of the Retransmit HIC is:
0111 1010 Retransmit Receive No.
0010 00aa (Last ACKSET received OK)
aaaa 0100 End of Header
Upon receipt of the Retransmit HIC, the PFC starts
retransmission of the ACKSET, if any, following the
number specified in the Receive Number HIC. The PDU's
send numbers on the retransmitted ACKSET start with
the same send number as the ACKSET originally started
with.
N̲u̲m̲b̲e̲r̲ ̲R̲e̲s̲y̲n̲c̲.̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲
The Resync Number MIC provides number resynchronization
between the Send Number sent by the sending PFC and
the number expected by the receiving PFC. It is used
only as part of the Solicit sequence.
F̲l̲o̲w̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲
The Receive Ready and Receive not Ready HICs are provided
to permit a receiving PFC to inform a sending PFC that
it can/cannot receive data at this time. Receive Ready
and Receive not Ready operate in each direction of
the session path independently.
S̲y̲s̲t̲e̲m̲ ̲S̲e̲s̲s̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲S̲S̲C̲)̲
S̲y̲s̲t̲e̲m̲ ̲S̲e̲s̲s̲i̲o̲n̲
A System Session is defined as the logical connection
between two paired End Users (EU). Each EU is assigned
its own system session number. All messages that an
EU receives has its system session number included
in it. Multiple system sessions may be assigned to
a single Logical Port. CSUs associate a system session
number with a port.
C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲S̲y̲s̲t̲e̲m̲ ̲U̲s̲e̲r̲ ̲(̲C̲S̲U̲)̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The CSU is the user of the Communication System (CS)
and interfaces the TS|s services by means of an interface
protocol called the Data Management Facility (DMF).
The DMF protocol is not only an interface to the TS
but also a protocol between paired DMFs.
DMF-to-DMF sessions are called system-sessions. A
number of system-sessions may share an LP-session.
D̲M̲F̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲
The DMF protocol is implemented via the use of a DMF
header that is placed after the PFC header. The DMF
header is built of octet header information codes.
The DMF performs the following functions:
- Data flow control on a system session basis.
- Dynamic establishment of system sessions.
- Close-down of system session.
- End-to-end assurance of dat{ delivery.
- System session status check.
D̲M̲F̲ ̲H̲e̲a̲d̲e̲r̲ ̲I̲t̲e̲m̲s̲ ̲(̲c̲l̲a̲s̲s̲ ̲2̲)̲
VC HIC (0001) VARIANT (0001) PARAMETER (8bit
EU Number)
SUP HIC (1000) CONTROL (4 bits)
CONTROL NAME
0000 END
0010 RR
0011 RNR may not appear in data
headers
1011 ERROR
VC if omitted eu number 1 assumed
SUP(END) is required and must come last
SUP
(ERROR) sets UDM condition for a session UDM condition
cleared by any valid CSU header including a data header
SUP(RR)
If they appear in the same header the RNR is ignored
SUP(RNR)
PFC is informed by the transport network when a message
becomes undeliverable because:
- The remote TS is down
- A route in the network is down
PFC informs DMF via a HIC control message that the
logical port session is down.
*
End of header (END) HIC is always required and must
come last.
The above-mentioned HIC-codes are valid for fixed (=configured)
system-sessions (class 2 = basic flow control).
When CMS receives SUP(ERROR) output is marked in the
hold stste and any message is put upon the deferred
queue. Standard action occurs from here. Since there
is no acknowledge or recovery mechanism at this level,
there is a window where some messages may be in transit
when the ERROR is sent causing lost messages, unless
the FEP holds them for redelivery. Receiving a SUP(ERROR)
HIC does not abort the session because the session
is fixed.
To provide pacing the CSU level interfaces with the
next level, PFC. When the PFC level is unable to sent
data, it shuts off the CSU level preventing the CSU
level from sending data.
The normal data unit is in the form:
VC/SUP(END)/information field.
The Receive Not Ready or Receive Ready data units are
sent singly, i.e. without an information field, thus:
VC/SUP(ERROR)/SUP(END)
The error data unit is sent without an information
field and shuts off traffic in both directions. The
format is:
VC/SUP(ERROR)/SUP(END)
If the VC is sent, it must be the first HIC sent.
If it is not sent, session number 1 is assumed. Time-out
detection is not used since there is no acknowledge
protocol to time.
D̲M̲F̲ ̲H̲e̲a̲d̲e̲r̲ ̲I̲t̲e̲m̲s̲ ̲(̲c̲l̲a̲s̲s̲ ̲3̲)̲
VC
SUP(RR)
SUP(RNR)
SUP(END)
SUP(OPEN) HIC(1000) CONTROL(1001)
request the opening of a session
SUP(ACPT) HIC(1000) CONTROL(0110)
accept an open request
CLOSE(REQUEST) HIC(1110) CONDITION(0000)
request to close a session
CLOSE(CONFIRM) HIC(1110) CONDITION(0001)
sent by the receiver of a CLOSE(REQUEST) when he has
finished
CLOSE(REJECT) HIC(1110) CONDITION(1000) CODE 8
BITS
to reject an open request - code gives reason
e.g. EU not configured, OR BUSY, insufficient resources
etc.
CLOSE(ABORT) HIC(1110) CONDITION(1101) CODE 8
BITS
close session in error on detection of an abnormal
event
Note:
When a VC number is in the header - it must be first
MIC except fo
OPEN and OPEN ACCEPT.
The class 3 system session covers:
- dynamic establishment of system session
- orderly disestablishment of system session
- disestablishment of system sessions in error
- information flow control
- end-to-end assurance of information delivery
- information of system status
The system session class 3 cannot be used with PFC
class 6.
The Port Presentation Services (PPS) header is not
supported with system sesssion class 3, i.e. RB-2(SUP-1)
and INT-1(DPP-1) have to be used.
The class 3 system session covers:
- dynamic establishment of system session
- orderly disestablishment of system session
- disestablishment of system sessions in error
- information flow control
- end-to-end assurance of information delivery
- information of system status
The system session class 3 cannot be used with PFC
class 6.
The Port Presentation Services (PPS) header is not
supported with system sesssion class 3, i.e. RB-2(SUP-1)
and INT-1(DPP-1) have to be used.
The SSC control items will be found in Appendix U as:
Table Title
U-1 Header Item assignments
U-2 Close codes
U-3 SUP codes
The SSC is foreseen to be utilised in the following
manner:
Sign-on of an autoallocated system session:
Command Value
SUP(OPEN) 1000 1001
SS(id) 0001 0001
xxxxxxxx (ss #)
CREDIT(var) 1101 0010 (abs. cred)
00000001 (lgt.)
00000100 (4)
SUP(END) 1000 0000
Sign off:
CLOSE(ABORT) 1110 1001
00000001 (lgt.)
01000010 (end user)
SS(id) 0001 0001
xxxxxxxx (ss #)
SUP(END) 1000 0000
I̲n̲t̲e̲r̲a̲c̲t̲i̲v̲e̲-̲1̲ ̲(̲I̲N̲T̲-̲1̲)̲
The interactive support protocol (INT-1) is one of
UNIVAC's virtual terminal protocols. It is used to
support an interactive dialogue between paired Applications
Environments (AEs). INT-1 provides independency of
the host AE.
INT-1 may be used independently or dependently of devices.
INT-1 performs data control and device control functions.
The following is a (brief) description of the various
components of the INT-1 protocol.
THE UNITS of INFORMATION, i.e. the DATA CONTROL STRUCTURES,
consist of:
1. Records
2. Messages
3. Message group
To allow separation or addressing of a number of contiguous
messages.
THE MODES OF OPERATION FPR THE INT-1 PROTOCOL WILL
BE ACCORDING TO THE FOLLOWING SCHEME:
o set by zone parameters
1. INPUT
(a) DEVICE DEPENDENT
All display formatting control characters are left
as device dependent between STX and ETX and terminated
by EMI.
Device control sequences (XON XOFF THRU) are deleted
Data is converted to code specified by ZONE parameters
(b) MESSAGE (1)
Each input is considered a single message terminated
by EMI
All display control characters (including CR) are converted
to display control items (DCIs). Data is translated
to code as per ZP 1.
(c) MESSAGE (2)
As for (b) - except display control chars are deleted
(d) RECORD
Each line of input is considered as a separate IMAGE
or RECORD terminated by ERI.
Last RECORD is terminated BY ERI EMI.
2. OUTPUT (PRESENTATION)
(a) DEVICE DEPENDENT (1)
All display control info is imbedded in the text.
ZP1 code is converted to device dependent Terminated
by EMI.
Embedded line protocol sequences will be deleted prior
to processing for delivery to the addressed device.
(b) DEVICE DEPENDENT (2)
As for (a) but device control sequences (DC2, XON etc.)
are also embedded.
(c) MESSAGE MODE (1)
Each new message causes a NP (NEW PAGE)
Filling of ZONE causes pointer to go to origin.
Display formatting by DCIs.
(d) MESSAGE MODE (2)
As for (c) but new message does not cause NP. ZONE
pointer remains at same location as it was on last
EMI.
(E) RECORD MODES
(i) SCROLL (1)
Each new record causes default spacing.
IF the ZONE is filled - the entire contents of the
ZONE is rolled up or down and next record (or part
thereof) is placed on the last line.
(ii) SCROLL (2)
Some as (i) but when the ONE is filled - OUTPUT SUSPENDED
-sends "MESSAGE WAIT INDICATOR" When input is received
send to paired AE unless "MESSAGE WAIT" or "RESUME"
indicator was received and resumes output in all cases.
(iii) PAGE (1)
Each new record causes spacing.
When the ZONE is filled, the ZONE pointer is moved
to (1.1).
(iv) PAGE (2)
As for (iii) but when the ZONE is FILLED:-
SUSPEND output
Any input except "MESSAGE WAIT" or "RESUME INDICATOR"
is sent to the paired AE. Then perform NP and resume
output.
ZONE USAGE
ZONE (0) The EVENT ZONE is used to
Identify and control non-textual attention information.
e.g. BREAK or FUNCTION KEY
ZONE (1) The DISPLAY ZONE is used to allow addressing
of system type messages and allow them to be processed
separately from user data messages.
The following tables will be found in Appendix U describing
the INT-1 protocol in detail:
Table Title
U-4 Data Control Commands
U-5 Data Structure Items
U-6 Display Zone Parameters
U-7 Event Zone Parameters
U-8 Display Control Items
The following section contains a description of the
real devices supported by the INT-1 protocol
D̲e̲v̲i̲c̲e̲ ̲G̲r̲o̲u̲p̲
A device group is defined as:
A physical grouping of hardware devices sharing a common
and intelligent point of addressable control, e.g.
UTS400 CLUSTER, or U100 station.
D̲e̲v̲i̲c̲e̲ ̲G̲r̲o̲u̲p̲ ̲I̲d̲e̲n̲t̲i̲t̲y̲
The device group identity is defined as:
1 - 8 alpha-numeric characters, e.g. cluster symbolic
name - UTS400 terminal symbolic name U100/U200/DCT1K/DCT500
D̲e̲v̲i̲c̲e̲ ̲G̲r̲o̲u̲p̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
In addition to being uniquely named device groups are
defined by 2 device group parameters:
1. Type
2. octets describing
a) generic class (1 octet)
b) specific type of device group (1 octet)
2. Composition
6 octets - 1 per device category
each octet specifies the number of devices of that
particular category in the group.
The values of the device group parameter TYPE, i.e.
Generic Class and type of device group will be found
in Appendix U of table U-9.
D̲E̲V̲I̲C̲E̲
A device is defined as, a single self-contained piece
of hardware e.g. a printer, a card reader, card punch,
a CRT etc.
Devices are not named but identified by:
(i) device category
(ii) device number - devices of the same category
within a group are given a sequence number.
D̲e̲v̲i̲c̲e̲ ̲C̲a̲t̲e̲g̲o̲r̲i̲e̲s̲
The following device categories are recognized.
1. PRESENTATION - O/P only to non-stored media,
e.g.
aux
2. ACQUISTION - I/P " from " "
3. CONVERSATIONAL - I/P and O/P TO/FROM " "
4. STORAGE - O/P only to storage media, e.g.
CP, PTP
5. RETRIEVAL - I/P only from storage medium,
e.g.
CR, OCR
6. STORAGE/ - I/P and O/P FROM/TO storage media,
RETRIEVAL e.g. diskette, MT.
D̲e̲v̲i̲c̲e̲ ̲C̲l̲a̲s̲s̲
A device class is defined as, a set of devices within
a given category having a common set of functional
capabilities or attributes. Each class is defined by
a set of device independent parameters.
D̲e̲v̲i̲c̲e̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲
The device parameters are
- Used to obtain/modify device class operational
characteristics relating to information display.
- Parameters for a device class are numbered sequentially
starting at 1.
- A parameter offset = 0 addresses all parameters
for a class.
D̲e̲v̲i̲c̲e̲ ̲T̲y̲p̲e̲
The device type is the device attribute which indicates
the:
- category, i.e. presentation, coversational etc.
- generic class-, i.e. CONV1, CONV2, CONV3, CONV4
etc.
- specific product type- , i.e. TTY, U100, UTS400
etc.
Table U-10 in Appendix U defines the values of device
classes, their associated parameter lists, and specific
device types.
The following tables will be found in Appendix U:
Table Title
U-11 INT-1 Device Structure Items
U-12 Device Assignment Commands
U-13 Device Parameter Commands
U-14 Device Control Commands
R̲e̲m̲o̲t̲e̲ ̲B̲a̲t̲c̲h̲ ̲(̲R̲B̲-̲2̲)̲
The Remote Batch protocol (RB-2) is one of UNIVAC's…02…virtual
terminal protocols. It uses either the Data Presentation
Protocol (DPP-0) or the Supervisory protocol (SUP-1)
for the control-part of the protocol.
The following is a (brief) presentation of the components
of DPP-0.
Figure III 6.7.3.5 shows the three formats of the DPP-items.
Fig. III 6.7.3.5
D̲P̲P̲-̲O̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
1. OUT - HIC = (X'81')
To pass from/to CSU variable data to be output to the
addressed device.
Can be used for the display zone or the event zone.
2. WRTP - HIC = (X'8A') " write par{meter used only
to write zone parameters.
Note ZONE and ZP items must be included in the UDU.
3. WRT - HIC = (X'83' - write text . Used for the
console control protocol using zone 0.
4. STATUS - HIC (X'OF')
Returned to originating CSU when a command received
which must be acked or any command in error.
V1 - Variant contains general status
0 - preliminary accept
1 - intermediate accept
2 - final
8 - temporary reject
9 - final
length - 2
V2 - 1st octet intermediate status 2nd is detailed
status
0 - syntax
0 - command syntax
1 - argument -
2 - command not supported
3 - argument - -
4 - out of sequence
1 - data control
2 - device -
3 - data - exception
4 - device - -
1. ZONE = X'D2'
Used to address data
(a) ZONE(1) The normal text display zone used to guide
the display of data onto or from the device associated
with the system session.
(b) ZONE(0) The event or control zone used to address
or convey control information (SUP-0-1) on the supervisory
session.
May be conveyed in all UDUs
DEFAULT - if not specified assume ZONE(1) the data
Zone
OUT TEXT .... to ZONE(1)
OUT ZONE(O) TEXT SUP (control) INFO on
supervision or device session
2. ZP-ZONE PARAMETER = X|02| PARAM (4 bits) INFO Sets
of resets parameters for the display zone.
PARAM NAME DESCRIPTION
1 CODE 2 octets of info discribes the device
code and compression algorithm
octet 1 - code
- 0 - ASCII (7 bit)
- 1 - Column binary (6 bits per octet)
- 2 - fielddate (- - - -
)
octet 2 - compression
0 - no compression
1 - CMP-1
3 WIDTH 2 octets width of zone in octets
4 LENGTH 3 octets
2 octets - length of zone
3rd octet - density 6 or 8 lines per
inch.
ZP EXAMPLES
1. WRTP ZP P1(4) P2(L1) P3(L2) P4(D)
L1 L2 = page length
D = density
2. WRTP ZP P1(3) P2(W1) P3(W2)
W1 W2 page width
3. WRTP ZP P1(1) P2 = (code#)
character code change
CMP-1 compression algorithm
TEXT (HIC) n BC CC char....BC CC…0f…2…0e… char1.
TEXT,n Identifies the item as text and n the no. of
octets in the item (n X'FE')
BC - Blank count - no. of blanks supressed (X'3E')
CC - Character count (octets) in string that follows
before next BC or end of item CC X'3E'.
3. ERI = X'92' END OF RECORD INDICATOR Delimits a
record
(i) Sent of I/P when ITB detected from terminal
(ii) RXED - causes end or record function -
e.g. printer new line.
May have - 1 or more than 1 record in a UDU - record
may be segmented (SPAN 1 UDU)
4. EGI = X'94'
END OF GROUP INDICATOR indicates that this record
was the last in a message group (file)
5. ECI = X'95'
End of command indicator
6. END = X'90'
Marks the end of a UDU - must be in every UDU
1. TEXT = 'COV…0f…1…0e…V…0f…2…0e…' V…0f…1…0e…V…0f…2…0e… = 8 bit length. Used to
convey 1 or more text characters to be pressed
to/from a zone. Bidirectional.
2. SPACE = X'AV…0f…2…0e…' V…0f…1…0e… = 4 bit # lines to space no of
lines to be spaced - maximum 15
3. SPACEL = X'ET' Length (=1) PARAM
PARAM = no of lines to be spaced - maximum 255
4. NP(FF) = X'97'
Requests new page (and resets zone pointer to beginning
of the zone).
E̲X̲A̲M̲P̲L̲E̲S̲
1. OUT SPACE(0) TEXT(text) ERI ECI END
Single record including space item - spacing value
= 0
2. OUT TEXT(text) ERI EGI ECI END
Last record in a file
3. OUT TEXT(text) ERI TEXT(text) END
Several records - the last is incomplete
(continued in the next VDU).
4. STATUS(9)ECI
An error has been encountered.
Fig. III 6.7.3.6 shows a conversation between a
RB-2 terminal and an 1100-host.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲E̲N̲D̲ ̲E̲C̲I̲ ̲T̲E̲X̲T̲ ̲O̲U̲T̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲N̲O̲ ̲R̲E̲P̲L̲Y̲/̲S̲T̲A̲T̲U̲S̲ ̲E̲C̲I̲ ̲E̲N̲D̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲E̲N̲D̲ ̲E̲C̲I̲ ̲E̲R̲I̲ ̲T̲E̲X̲T̲ ̲X̲O̲N̲E̲ ̲W̲R̲T̲ ̲ ̲ ̲ ̲
̲ ̲ ̲N̲O̲ ̲R̲E̲P̲L̲Y̲/̲S̲T̲A̲T̲U̲S̲ ̲E̲C̲I̲ ̲E̲N̲D̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲E̲N̲D̲ ̲E̲C̲I̲ ̲Z̲P̲ ̲Z̲O̲N̲E̲ ̲W̲R̲T̲P̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲S̲T̲A̲T̲U̲S̲ ̲E̲C̲I̲ ̲E̲N̲D̲/̲N̲O̲ ̲R̲E̲P̲L̲Y̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
NOT SUPPORTED
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲C̲O̲M̲M̲A̲N̲D̲S̲/̲I̲T̲E̲M̲S̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲S̲T̲A̲T̲U̲S̲ ̲E̲C̲I̲ ̲E̲N̲D̲/̲N̲O̲ ̲R̲E̲P̲L̲Y̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲O̲U̲T̲ ̲T̲E̲X̲T̲ ̲E̲C̲I̲ ̲E̲N̲D̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲E̲N̲D̲ ̲E̲C̲I̲ ̲S̲T̲A̲T̲U̲S̲/̲N̲O̲ ̲R̲E̲P̲L̲Y̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲W̲R̲T̲ ̲Z̲O̲N̲E̲ ̲T̲E̲T̲ ̲E̲R̲I̲ ̲E̲C̲I̲ ̲E̲N̲D̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲N̲O̲ ̲R̲E̲P̲L̲Y̲/̲E̲N̲D̲ ̲E̲C̲I̲ ̲S̲T̲A̲T̲U̲S̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲W̲R̲T̲ ̲Z̲O̲N̲E̲ ̲Z̲P̲ ̲E̲C̲I̲ ̲E̲N̲D̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲E̲N̲D̲ ̲E̲C̲I̲ ̲S̲T̲A̲T̲U̲S̲/̲N̲O̲ ̲R̲E̲P̲L̲Y̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Fig. III 6.7.3.6 RB-2 Conversation
D̲P̲P̲-̲O̲ ̲D̲e̲v̲i̲c̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
Device group can consist of 1 or more devices from
categories:
Presentation
Storage
Retrieval
DPP-0 allows data to be conveyed to or from a device
without having to effect device control
Each device presents data in a defined default manner.
To modify the default presentation on a device, new
device parameters (DP) should be exchanged.
The following tables giving detailed values are found
in Appendix U.
Table Title
U-15 DPP-O Device Structure Items
U-16 DPP-O Device Categories
U-16 Storage Devices
U-16 Retrieval Devices
U-17 DPP-O Device Control Functions
The following is a summarisation of the contents of
the User Data Unit (UDU) and its usage for the NTR-protocol:
UDU: = command ̲sequence ... OUT incomplete ̲sequence
END
command ̲sequence:=out ̲seq wrt ̲seq wrtp ̲seq status ̲seq
smi ̲seq ECI
incomplete ̲sequence:= record .... incomplete ̲record
incomplete record:= TEXT PAD ... (on input)
record:= incomplete ̲record ERI
out ̲seq:= OUT record ... EGI
wrt ̲seq:= WRT ZONE(O) TEXT(6) TEXT(3) (on input)
wrt ̲seq:= WRT ZONE(O) TEXT(3) ERI (on output)
wrtp ̲seq:= WRTP ZP(1) (on input)
wrtp ̲seq:= WRTP ZP ... DP ... (on output)
status ̲seq:= STATUS
smi ̲seq:= SMI
Legend:
:= is defined as
choose one or none
choose one
at least one of the inner must choose one
choice separator
... may repeat choice indefinitely.
This expresses all valid UDUs in terms of basic RB-1-items.
Subscripted items are those whose range of valid parameters
is restricted in that context. These are as follows:
ZONE(0) used to identify the control zone only. The
display zone is assumed whenever no zone is specified.
TEXT(3) is a TEXT item containing NTR's message type,
device number and detail bytes. Since this is recognized
by its zone number (#0) and length of 3 text bytes,
it amounts to a pseudo item in RB-l.
TEXT(6) is a TEXT item containing an NTR site sign-on
message. Like the previous item, it is recognized by
its zone number (no.) and text length (6 bytes) and
thus amounts to an RB-1 pseudo item.
ZP(l) indicates Telcon,s ability to change display
zone parameter no. 1 only.
The incomplete sequence in an OUT command is used to
continue a record in the first command sequence of
the next UDU. This next command sequence MUST be of
the form:
OUT TEXT PAD ...ERI incomplete ̲sequence record
... EGI ECI
Note that the continued record must be completed in
the sub-sequent UDU i.e. a record may only be continued
across two UDUs, not more. The subsequent UDU may itself
end with the continuation of another record as normal.
This implementation is compatible with FDR to level
35 and NTR to level 2R2B. All NTR generated messages
are passed to the host except ACK/NAK messages and
the following service message types:
o Request output (MT=X'02')
o Initialize Device Alternate (MT=X'14')
o Illegal message (MT=X'37')
o Initialize Device (MT=X'3E', DN=X'OF')
The NTR messages that are passed to the host are thus
as follows:
o Terminate device (MT=X'04')
o Suspend device (MT=X'05')
o Resume device (MT=X'06')
o Lock and terminate (MT=X'07')
o Requeue (NT=X'08')
o Lock and requeue (MT=X'09')
o Reprint/repunch (MT=X'l0')
o Skip forward (MT=X'll')
o Display files (MT=X'l2')
o Display queue (MT=X'l3')
o Terminate site (MT=X'38')
o Unlock (MT=X'39')
o Complete active files and terminate (MT=X'3A')
o Complete queued files and terminate (MT=X'3B')
o Lockout (MT=X'3D')
o Display (MT=X'3F')
All FDR generated control messages will be transmitted
to Telcon in TEXT(3) items as indicated above, except
for the Transfer Load Code message (MT=X'36'), Suspend
Device (MT=X'5'), Resume Device (MT=X'6') and Initialize
Device (NT=X'3E'). Load code information is transmitted
to Telcon in a WRTP command sequence, specifying the
Font Device Parameter (#4). Suspend and Resume Device
are effected in the CSU header by sending Receive Not
Ready and Receive Ready items respectively. Initialize
Device is not transmitted in any form. The TEXT(3)
items transferred are:
o Terminate device (MT=4)
o Terminate site (MT=X'38')
o Initialize site (NT=X'3E', DN=X'OF')
o Display (MT=X'3F')
Instead of the DPP-O protocol, the SUP-1 protocol is
also available for supervision of the RB-2 protocol.
SUP-1 is the newest of the two supervisory protocols
and is most likely to be extended in the future. The
following is a (brief) presentation of the components
of SUP-l:
The SUP-l uses:
o The supervisory and device system session
o Event zone (zone(0))
T̲y̲p̲e̲s̲
o Supervisory commands/responses applicable to a
single device and conveyed on a device session.
o Supervisory commands for retrieving information
about l or more devices and conveyed on the supervisory
session.
N̲o̲t̲e̲
Displayable information to/from the site operator is
conveyed using zone(l) of DPP-0 on the supervisory
session.
Bidirectional-data transfer always terminated with
EGI.
S̲U̲P̲-̲1̲ ̲c̲o̲m̲m̲a̲n̲d̲s̲/̲R̲e̲s̲p̲o̲n̲s̲e̲s̲ ̲
Out Zone(0) Text (L,CMD,param)EGI
L - length (depends on command)
CMD - command (l octet)
param - parameter field
S̲u̲p̲ ̲L̲ ̲D̲e̲v̲i̲c̲e̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲S̲e̲s̲s̲i̲o̲n̲s̲
Command Function Parameter Sent
by
1 terminate current file NONE P-S
(other files or queue
for the device may be sent)
2 Requeue current file NONE
S
3 Reprint/repunch # pages/Cards
S
4 Skip forward pages/cards # pages/Cards-10
S
5 Manual action request 1-132
P
(primary requesting a
special actin to be per-
formed relative to the
device by the site operator.
6 Manual action complete NONE S
l0 Display active files l-6 chars the S
(requesting summary of unique logical
files on Q for device) device name
ll Display output queue As above S
63 Function not supported NONE
P
(primary indicating requested
function not supported)
T̲e̲l̲e̲c̲o̲n̲ ̲C̲o̲n̲s̲o̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Operator interfaces, purposes and function.
Unsolicited commands allow the operator to control
and monitor CMS ll00, its configuration and its network.
o A set of network management commands is provided
for externally controlling and monitoring the Telcon
network in accord with host resources. These commands
allow the operator to display or change the status
of network entities (FEPs FEP-paths, GROUPs, CSUs,
DEVICEs, TERMINALSs, CLUSTERSs, POLL-GROUPs, LINEs).
o A set of configuration commands allow the operator
to modify the configuration.
o A set of general CMS ll00 commands allow the operator
to control and monitor the operation of CMS 1100.
The commands provided are initiated by natural language
oriented syntax, i.e. special control symbols and cryptic
abbreviations are not required. Each command begins
with an English verb that indicates the type of action
to be performed.
C̲o̲m̲m̲a̲n̲d̲ ̲V̲e̲r̲b̲
A verb is an identifier which names a command and indicates
the action to be performed. These are:
o Network Commands:
UP
DOWN
SWITCH
STOP
START
STATUS
STATSON
STATSOFF
STATS
o Configuration Commands
ADD
DELETE
INCLUDE
VERIFY
o General System Commands
END
DUMP
TERN
ERROR
REINIT
RECOVR
BUGON
BUGOFF
SETBP
SNAP
CHANGE
INSPECT
BRKPT
TRACE
DELMSGS
ALROUTE
For a detailed description of the effect of the various
commands please refer to the current issue of UNIVAC|s
CNS-operators manual.
N̲e̲t̲w̲o̲r̲k̲ ̲A̲d̲m̲i̲n̲i̲s̲t̲r̲a̲t̲i̲o̲n̲ ̲S̲e̲s̲s̲i̲o̲n̲s̲.
The Network Administrator may enter the CMS ll00 network
commands from the host console or may SIGN-ON as CMS
ll00 Network Administrator at a terminal in the Telcon
network. Telcon network administration commands may
also be entered through this mechanism from the host
console.
In order to make a terminal a network console, it must
be configured as such, and be signed on. More than
one terminal may defined and signed on concurrently
as a network console.
In the case of terminal failure where the terminal
is also a network console, the host console is notified
and the connection with the "failed" terminal is broken.
All communication that is intended for the "host console"
is transmitted to the console with the communications
console class as configured on the INFO SCS.
For detail on operator keyin formats see UP-9336 section
2. (Current issue)
I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲G̲a̲t̲h̲e̲r̲i̲n̲g̲ ̲-̲ ̲S̲t̲a̲t̲u̲s̲ ̲L̲o̲g̲g̲i̲n̲g̲,̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲,̲
T̲r̲a̲i̲n̲i̲n̲g̲
CMS ll00 provides a package of information gathering
facilities which enable the operator to acquire information
about the operation of CMS ll00. This package provides
four levels of information which can be retrieved and
manipulated to determine the state or activity of the
system. The hierarchy of features which comprise this
package are:
Status A status keyin facility is provided which allows
the operator to determine the exact state of
an entity. The type of information provided
is UP/DOWN, ACTIVE etc.
Log A system log facility with an associated log
file is always active whenever CMS ll00 is
in operation. All system events are logged.
Statistics A facility is provided which allows
to obtain statistical information about
entities within the system. The statistic
facility will either make entries on
a periodic basis in the log file for
any entities with "stats" enabled
or it will retrieve and display on demand
the statistics for a specific entity.
Items such as number of messages in
and out, length of queues, number of
errors on a given line etc. are typical
statistical information.
Trace The TRACE facility is a debug facility
which is normally used only when tracking
an error condition. Nowever, it does
provide an accurate, detailed picture
of what is occurring by dumping out
tables, data buffers etc. to a trace
file while the system is operational.
T̲E̲L̲C̲O̲N̲ ̲3̲R̲1̲B̲ ̲(̲4̲R̲1̲)̲
This chapter contains a (very brief) description of
the protocol levels of the DCA-concept, which alone
are implemented in the DCP/40's of a Telcon network.
Thus the previously described DCA-layers will not be
covered.
This chapter covers:
o Sub Architectural Interface (SAI) - Channel - Trunk
(UDLC)
o Data Unit Control (DUC)
o Remote Trunk Control (RTC)
o Trunk Control (TC)
S̲A̲I̲
W̲o̲r̲d̲ ̲C̲h̲a̲n̲n̲e̲l̲ ̲H̲o̲s̲t̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲L̲i̲n̲e̲ ̲M̲o̲d̲u̲l̲e̲
The word-channel host interface line module (word-channel
line module) is used as an interface between the DCP/40
and a SPERRY UNIVAC ll00 series processor. Commands
and requests to and from the ll00 Series processor
are routed through the line module and its associated
port processor.
I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲C̲h̲a̲n̲n̲e̲l̲
Data transfers on the interface channel are full duplex.
Both input and output transfers are 32-bit words with
two parity bits. One parity bit is used to protect
each l6-bit half-word. Parity checking may be optionally
disabled on the input channel.
Function commands, acknowledge signals, and request
lines are included on both input and output channels.
These lines, in conjunction with the data lines, allow
the host processor to control data transfers on the
interface channels.
Communications through the word-channel line module
are controlled by instructions executed in the port
processor.
For further information on the DCP/40 - word channel
interface please refer to UP-8720.
U̲n̲i̲v̲e̲r̲s̲a̲l̲ ̲D̲a̲t̲a̲ ̲L̲i̲n̲k̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲
Universal data link control (UDLC) is available as
a microprogram selection for both medium speed and
high speed synchronous loadable line modules. UDLC
line transmission is discussed in UP-8554, "SPERRY
UNIVAC Universal Data Link Control General Description".
UDLC is a bit-oriented communications line discipline
that operates with high-level data link control (HDLC),
advanced data communications control procedure (ADCCP),
and IBM synchronous data link control (SDLC) as subsets.
For normal input and output operations, the UDLC frame
format is as shows in figure 6.7.3.7. Frame format
is controlled by the UDLC microprogram selection.
Start Address Control Information Frame
Check Ending
Flag Field Field Field Sequence
Flag
Figure III 6.7.3.7 UDLC-frame
For further information on the UDLC-implementation
in the DCP/40 please refer to UP-8720.
D̲U̲C̲,̲ ̲R̲T̲C̲,̲ ̲T̲C̲
Since the protocol layers DUC-RTC-TC are not a part
of the ACNC NAS as proposed (Host Access Subsystem)
a further study will be needed, if and when that is
the case.
A̲C̲D̲N̲ ̲I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲f̲o̲r̲ ̲n̲e̲w̲ ̲U̲N̲I̲V̲A̲C̲ ̲h̲o̲s̲t̲s̲
This chapter contains a description of the UNIVAC host
interface implementated in ACDN. The basis for the
description is the chapters of DCA, CMSll00 and Telcon.
Thus the description may be brief, as emphasis is put
upon the differences between the concept (DCA), the
implementations (CMSll00 and Telcon 3RlB) as described
by UNIVAC, and the implementation. The following items
will be described:
o Sub Architectural Interface (SAI)
- channel
- trunk (UDLC)
o Termination System (TS)
- Line Port Multiplexor (LPM)
- Port Flow TS/TN Control (PFC)
- Data Unit Control (DUC)
- Remote Trunk Control (RTC)
- Trunk Control (TC)
- Communications System User (CSU)
- Emulators
- RB2/NTR
- RB2/3780
- INTl/TTY
- INTl/3270
S̲A̲I̲
U̲n̲i̲v̲a̲c̲ ̲C̲h̲a̲n̲n̲e̲l̲ ̲H̲a̲n̲d̲l̲e̲r̲
The channel to the UNIVAC ll00/xx host is based upon
the CR8037D UNIVAC I/F as described in CSD/005/PSP/052
and CR8079D
