top - download
⟦37f89f2dd⟧ Wang Wps File
Length: 30952 (0x78e8)
Types: Wang Wps File
Notes: Air Canada
Names: »2064A «
Derivation
└─⟦9a531dff6⟧ Bits:30006257 8" Wang WCS floppy, CR 0157A
└─ ⟦this⟧ »2064A «
WangText
.…08….…09….…00….…06…-…0b…-
,…09…,…0a…,…86…1
…02… …02…
…02… …02…
CHAPTER
6
Page
#
DOCUMENT
III
TECHNICAL
PROPOSAL
Apr.
29, 1982
6.6 T̲e̲r̲m̲i̲n̲a̲l̲ ̲A̲c̲c̲e̲s̲s̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The scope of this section is to present the functions
supported by the Terminal Access Software and to indicate
the underlying structure of the software package.
The description in this section indicates data flow,
protocols, and control sequences that can be associated
with individual software components.
6.6.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The Terminal Access Software is interfaced to the nodal
switch software (NSS). The interface can be either
with the Datagram services of the NSS or the virtual
transport services of the NSS.
The basic components of the TAS are Line handlers,
device handlers, emulators, connection allocation services,
and Node logical unit services. External Resources
Manager, Configuration Manager and Status Reporter,
and Node Session Manager.
For the sole purpose of description in this chapter,
the basic components referenced above are equalled
to "tasks". The software packaging method employed
combines the tasks into appropriate processes. Fig.
6.6.-1 shows the typical software package.
Fig. 6.6-1…01…Framework Package for Terminal Access Software
6.6.2 L̲i̲n̲e̲ ̲H̲a̲n̲d̲l̲e̲r̲s̲
The TAS provides support for one asynchronous and two
synchronous line protocols. These protocols may work
in several modes.
6.6.2.1 A̲s̲y̲n̲c̲h̲r̲o̲n̲o̲u̲s̲ ̲S̲t̲a̲r̲t̲/̲S̲t̲o̲p̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲s̲
This protocol collects a string of characters from
the line and forwards it to the device handler, or
it receives a string of characters from the device
handler and outputs it, character by character on the
line.
The following characteristics apply:
o The line speed can be selected among one of the
speeds mentioned above in the range from
300 - 4800 bps.
o The number of bits per character can be specified
between 5 and 8. Characters are forwarded to the
device handler in 8-bit bytes, with the significant
bits in the low order positions, and the remaining
bits set to zero.
o Even, odd, or no parity can be specified. Parity
errors are signalled to the device handler and
all bits in the erroneous byte are set to one.
o The stop bit can have a length of 1, 1 1/2, or
2 normal bits.
o When characters are received, they may or may not
be echoed back on the transmitting circuit.
o A time out value can be specified. When time out
occurs, any received characters are forwarded to
the device handler.
o A data forwarding character can be specified.
When this character is encountered, all received
characters are sent to the device handler.
o The numbers of nulls to be sent as time fill characters
after a carriage return can be specified.
o The break condition, defines as the signal being
low min. 150 ms, can both be received and transmitted.
The above parameter specification facilities are exploited
to realize the necessary implementations for ACDN.
6.6.2.2 B̲S̲C̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲
The synchronous character oriented BSC protocol is
supported as defined in: the IBM publication General
Information - Binary Synchronous Communications, GA27-3004,
with the following provisions:
o Among the speeds mentioned above, the line speed
can be selected in the range from 1200 to 9600
bps.
o The pad character used for line turn around can
be specified.
o The protocol can or cannot be in transparent mode,
i.e. all control characters being preceded by a
DLE character.
o Point-to-point or multipoint line discipline is
maintained. On a multipoint line, the line handler
acts as a master.
o The character set used is EBCDIC.
o The following parameters which have a direct impact
of the BSC protocol operation can be specified:
- the number of consecutive negative responses
to polling which are accepted before scanning
continues,
- the number of retries performed when a text
block is negatively acknowledged,
o The following parameters can be specified to manage
the traffic mix on a line:
- the poll time interval for devices not in sessions,
- service order for devices on the line,
- number of devices on the line which are considered
in each scan.
These parameters may be changed by the NCC operator
during normal operation.
6.6.2.3 S̲D̲L̲C̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲
The synchronous bit oriented SDLC protocol is supported
as defined in: IBM SDLC General Information GA27-3093,
with the following provisions:
o Among the speeds mentioned above, the line speed
can be selected in the range from 1200 to 19200
bps.
o The line handler acts as the master.
6.6.2.4 H̲D̲L̲C̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲
The synchronous bit oriented protocol is supported
as defined in CCITT recommendations Yellow book (1980).
6.6.3 D̲e̲v̲i̲c̲e̲ ̲H̲a̲n̲d̲l̲e̲r̲s̲
The device handlers are individual tasks provided to
support attachment of different terminal types to the
ACDN. The device handlers are concerned with providing
the necessary device control functions and are not
concerned with presentation control and protocol functions
for a particular device. The following descriptions
of the device support for TTY presents the baseline
facilities for TTY with the following assumption:
o TTY terminals appear as IBM3767 terminals for IBM
host access.
o TTY terminals appear as conversational devices
(category 3, Buffered printing (class 2), DCT1000
terminals for Univac host access.
6.6.3.1 T̲T̲Y̲ ̲S̲u̲p̲p̲o̲r̲t̲
The TTY device handler has the following characteristics:
o The 7 bit ASCII character set is used.
o Two modes are supported: system mode and normal
mode.
o Device characteristics may be changed by commands.
The terminal is initially in system mode. When a Log
on has been carried out, the terminal enters normal
mode. As long as the terminal is engaged in a session,
it is possible to switch between the two modes by pressing
the DLE key as first input character.
In normal mode, data is passed between the emulator
and the terminal according to the current setting of
the device characteristics which are explained below.
Device handler commands are used either to signal special
conditions to the emulator, or to change presentation
service functions. The following commands are defined:
*TTY Parameter-1: value-1, ...parameter-n: value-n,
where a combination of the parameters in table
6.6-1 are allowed.
*TAB Set tabulator. The device handler will display
a line showing the current input tabulator
setting, if any. Each tabulator stop is indicated
by a non-blank character. If the user wants
to change the tabulator setting, he can input
a line where non-blank characters will define
the tabulator stops.
E̲x̲a̲m̲p̲l̲e̲:
DLE
*TAB
x X (old set of tab stops)
x x x (new set of tab stops)
DLE
Tabulator stops can only be set by the user not from
the host. The tabulator function is performed when
the HT character is received from the terminal. The
HT character becomes part of the input string and,
if a tabulator stop is defined to the right of the
current input position, a sufficient number of spaces
are output to reach the tabulator stop position. HT
characters received from the host do not cause special
processing.
P̲a̲r̲a̲m̲e̲t̲e̲r̲ F̲u̲n̲c̲t̲i̲o̲n̲ D̲e̲f̲a̲u̲l̲t̲ V̲a̲l̲u̲e̲
E Echo.
1
=
Echo
on,
=
echo
off
1 0/1
C Character
delete.
The
previous
character
is
deleted
and
if
echo
is
on,
BS-SP-BS
is
echoed.
DEL character
L Line
delete.
The
input
line
is
discarded
and
if
echo
is
on,
-X-CR-LF
is
echoed.
CAN character
P Page
length
24 1
number
100
W Output
page
width
80 1
number
256
I Maximum
input
line
length
80 1
number
256
R Roll/scroll
mode.
0=roll,
1=scroll roll 0/1
In
scroll
mode,
output
is
halted
when
a
whole
page
has
been
received.
Output
is
resumed
when
the
data
for-
warding
character
is
input.
S Solicit.
Indication
of
ready
for
input
conduction
id
LF-solicit
character. character
T Data
forwarding
character.
This
character
terminates
the
input
line
and
causes
it
to
be
forwarded
to
the
emulator. CR character
D Padding
after
carriage
return 0 0
number
7
Number
of
NUL
characters
send
after
carriage
return.
X XON
(DC1)
and
XOFF
(DC3)
control 0 0/1
1
=
used,
0
=
not
used
Note:
A
parameter
value
which
is
a
character
can
either
be
specified
directly,
or
by
its
decimal
or
octal
ASCII
value.
Octal
values
are
preceded
by
the
letter
0.
Table 6.6.-1
Fig. 6.6-2…01…Example of TTY Device Handler and Emulator Operations
T̲e̲l̲e̲t̲y̲p̲e̲ ̲o̲n̲ ̲I̲B̲M̲
The IBM 3767 emulator accepts a BIND SNA-request for
a type 1 session with the same restrictions as a proper
IBM 3767. This means:
o Function Management (FM) profile must be 3.
o Transmission Subsystem (TS) profile must be 3.
o No FM headers are allowed.
Input data is always sent as an Only-In-Chain Request
Unit, whereas output RUs may be chained.
If the BREAK key is depressed, an SNA SIGNAL request
is transmitted to the host.
Figure 6.6-2 shows a sequence of typical operations
on the terminal, the corresponding states of the device
handler and the SNA requests sent and received by the
emulator.
T̲e̲l̲e̲t̲y̲p̲e̲ ̲o̲f̲ ̲U̲N̲I̲V̲A̲C̲
Sessions between Teletypes and UNIVAC hosts are fully
supported via the INT-1 protocol.
Teletype devices are defined to the host as:
o Conversational Devices
(Category 3)
o Buffered, Printing
(Class 2)
o Type: DCT1000 (Type 1)
The support given by the device handler is as described
in section 6.7.3. In addition, the emulator will recognize
a TTY commands and set line handler parameters accordingly.
PF6 NETWORK used to toggle between network control
mode and data mode.
PA1 is used as break key.
6.6.3.2 V̲D̲U̲ ̲S̲u̲p̲p̲o̲r̲t̲
In support of interactive host access IBM 3270 BSC,
IBM 3270 SNA, U100, U200, UTS 4000 running under UNISCOPE
line discipline device handlers are provided.
6.6.3.2.1 I̲B̲M̲ ̲3̲2̲7̲0̲
The IBM 3270 Information Display System consists of
a variety of cluster controllers, display stations
and printers.
ACDN supports the models which are specified for remote
attachment according to the following classification.
IBM 3270 BSC
o 3271 control unit, model 2
o 3274 control unit, model 1c
o 3275 control unit, model 2
o 3276 control unit, model 2
o associated 3277 display stations
o associated printers
IBM 3270 SNA
o 3274 Control Unit, model 1C
o 3276 Control Unit, model 12
o associated 3278 display stations,
o associated printers
All devices are given an SNA appearance. Control units
are represented by a Physical Unit and their attached
display stations and printers appear as associated
Logical Units.
I̲B̲M̲ ̲3̲2̲7̲0̲ ̲S̲N̲A̲
Since these device follow truly, the SNA protocols,
no special support needs to be given. Control Units
attach as PU.T2, display stations as LU.T2, and printers
as LU.T1 or LU.T3, depending on whether they must support
SNA Character String (SCS) control codes or 3270 data
streams.
6.6.3.3 B̲a̲t̲c̲h̲ ̲D̲e̲v̲i̲c̲e̲ ̲S̲u̲p̲p̲o̲r̲t̲
Batch mode access for the purposes of description in
this chapter is defined as an access procedure in which
bulk data transfer is initiated.
The type of terminals that are supported by the batch
access procedure are IBM 3780, IBM 2780, S/3 qualifying
for HASP work station support and the UNIVAC NTR.
From the IBM application program point of view, the
IBM 2780, 3780 and HASP work stations are supported
by ACDN through the appearance of IBM 3790.
From the Univac application program point of view,
the NTR and IBM 2780 are supported by ACDN for batch
access through RB2 protocol.
Minicomputers with installed emulators are supported
for batch access as long as they provide the standard
HASP work station multileaving protocol or the Univac
NTR protocol.
Application to application file transfer between IBM
Univac hosts or between two IBM hosts is supported
by the above batch access procedures.
6.6.3.3.1 I̲B̲M̲ ̲2̲7̲8̲0̲ ̲a̲n̲d̲ ̲3̲7̲8̲0̲ ̲B̲S̲C̲
BSC batch devices can only be supported by SNA if they
are given the appearance of the SNA batch terminal
IBM 3790. JES3 is able to support an SNA work station
with the following characteristics:
o Physical Unit PU.T2
o plus up to 5 LU.T1s, each consisting of:
- zero or more console devices,
- up to 15 reader devices,
- up to 15 printer devices
- up to 15 punch devices
o each logical unit may contain up to 15 consoles,
readers and printers/punches, where at any time,
only one can be active (i.e. selected by a Function
Management Header type 1 (FMH1)).
o supports for SNA character string (SCS)
NL (new line)
CR (carriage return)
FF (form feed)
IRS (inter record separator)
SVF (set vertical form)
SEL (select)
TRN (transparent)
o FM Profile is 3
o TS Profile is 3
Only Point to Point is implemented, but multipoint
may be installed, if required. Consoles for 2780,
3780 are supported in two ways:
1) Shared on the same device (console input in reader
stream, output on printer) as currently supported
by JES3 for BSC-devices and
2) Shared console on another different device (TTY,
3270 or another batch station). Each 2780/3780
must be assigned to a shared console.
6.6.3.3.2 I̲B̲M̲ ̲S̲/̲3̲ ̲H̲A̲S̲P̲ ̲W̲o̲r̲k̲ ̲S̲t̲a̲t̲i̲o̲n̲ ̲B̲S̲C̲
A HASP work station is supported by the HASP multi
leaving BSC protocol where the device handler in the
TAS plays the role of a central HASP station.
6.6.3.3.4 U̲n̲i̲v̲a̲c̲ ̲N̲T̲R̲ ̲W̲o̲r̲k̲ ̲S̲t̲a̲t̲i̲o̲n̲
The network supports sessions between a UNIVAC host
and the following devices:
o Univac NTR (Nine Thousand Remote)
o IBM 2780/3780
The devices are presented to the UNIVAC host as NTR
stations via the RB-2 protocol.
The following modules are involved:
(see fig. 6.6-3)
o NTR Line Handler + Device Handler
Responsible for controlling the line to the NTR
station.
o 2780/3780 Line Handler + Device Handler
Responsible for line control, packing/unpacking
and ASC11/EBCDIC translation.
o RB-2 Emulator
Used to map NTR and 2780/3780 device specific functions
into the RB-2 protocol.
The network will give the NTR station support for commands
defined in the NTR protocol, thus giving the NTR station
full support.
To enable the 2780/3780 site operator to issue NTR-equivalent
commands, input card images from these stations are
scanned for cards starting with SS. The following
commands are defined:
Fig. 6.6.3
Logical Flow of UNIVAC Batch Terminal Messages
SSTERM PRINTER terminate current printer
file
SSLOCK PRINTER AND REQUEUE lock out printer, requeue
current file
SSLOCK PRINTER AND TERMINATE lock out printer, terminate
current file
SSLOCK PRINTER complete current file,
lock printer
SSUNLOCK PRINTER printer is unlocked
SSRESUME PRINTER resume printer output
(f.eks. after forms change)
SSREQUEUE requeue current output
file
SSREPRINT nn reprint nn pages
SSDISPLAY QUEUE display number of files
queued
SSDISPLAY FILES display files queued for
printer
6.6.4 E̲m̲u̲l̲a̲t̲o̲r̲s̲
The emulators are crucial part of the TAS in as much
as they provide the protocol conversion facilities
between different terminal types. The protocol conversion
that is implemented by the emulators is designed to
keep the integrity of the end to end provisions of
native IBM or Univac protocols. The following description
provides a series of data flow and/or sequence diagrams
illustrating the operation of the device types described
in 6.6.3.
6.6.4.1 I̲B̲M̲ ̲3̲2̲7̲0̲ ̲B̲S̲C̲
The 3270 BSC devices support a restricted SNA protocol
with control units attached as PU.T1 and display stations
and printers as LU.TO, with the following profiles:
o FM profile is 2
o TS profile is 2
The only parameter which can be varied in the session
bind, is the specification of bracket usage. If brackets
are used, the 3270 BSC to 3270 SNA emulator will provide
a function to handle a Begin Bracket situation. (Normally
referred to as a Pseudo Bid).
If brackets are not used, then the end users must ensure
half duplex operation on the full duplex protocol.
It may be necessary to segment inbound PIUs since the
maximum block length supported by the 3270 BSC is 256
characters.
Fig. 6.6-4 shows the emulation of the pseudo bid command.
An information PIU with Begin Bracket indicator is
received. The device selection fails either with a
busy condition (WACK) or, a status pending condition
(RVI).
In the first case, a negative response to the bid is
sent immediately. In the latter case the status information
is read by a specific poll and appropriate error recovery
is performed. If error recovery is not possible, a
negative response to the bid is returned to the host.
The bid may also fail because an input operation is
being performed in which case, the negative response
is followed by a bracket initiation plus data from
the device.
Fig. 6.6.4
E̲m̲u̲l̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲P̲s̲e̲u̲d̲o̲ ̲B̲i̲d̲ ̲(̲N̲e̲g̲a̲t̲i̲v̲e̲ ̲R̲e̲s̲p̲o̲n̲s̲e̲)̲
Fig. 6.6-5
R̲e̲a̲d̲ ̲f̲r̲o̲m̲ ̲3̲2̲7̲0̲ ̲B̲S̲C̲
Fig. 6.6-6…01…R̲e̲a̲d̲ ̲B̲y̲ ̲P̲o̲l̲l̲i̲n̲g̲ ̲(̲3̲2̲7̲0̲ ̲B̲S̲C̲)̲
Fig. 6.6-7…01…W̲r̲i̲t̲e̲ ̲t̲o̲ ̲3̲2̲7̲0̲ ̲B̲S̲C̲
Figure 6.6-5 shows a successful bracket initiation,
causing data to be read. Note that data cannot be
forwarded before the EOT is received because, the data
block might only be a segment of the message.
Figure 6.6-6 shows a polled read where 2 data segments
are combined into a single PIU before sent to the host.
Figure 6.6-7 is an example of a write operation in
a session where brackets are not used.
BSC sense codes are translated as closely as possible
into equivalent SNA sense codes.
6.6.4.2 I̲B̲M̲ ̲2̲7̲8̲0̲ ̲&̲ ̲3̲7̲8̲0̲ ̲B̲S̲C̲
Figure 6.6-8 shows the command sequences for a complete
session between JES3 and the LU of a 3780 device.
There are three phases: connection, data transfer
disconnect. The emulator is capable of generating
and responding to the elaborate SNA command sequences
used with the session profiles. Note also the use
of Function Management Header 1 to select the reader
as the active subunit. At the BSC side, it may be
noted how WACK-NAK sequences must be used when a block
acknowledge must be delayed due to SNA protocol operations.
The traffic shown can be interleaved by traffic between
JES3 and other devices as specified by the generalmulti
drop BSC protocol.
Figure 6.6-9 gives a similar example of a session with
a printer. Of course, both reader and printer can be
selected interchangeably within the same session, if
the remote device supports this operating mode.
Fig. 6.6-8…01…E̲x̲a̲m̲p̲l̲e̲ ̲o̲f̲ ̲S̲e̲s̲s̲i̲o̲n̲ ̲w̲i̲t̲h̲ ̲a̲ ̲R̲e̲a̲d̲e̲r̲
Fig. 6.6-9 …01…E̲x̲a̲m̲p̲l̲e̲ ̲o̲f̲ ̲S̲e̲s̲s̲i̲o̲n̲ ̲w̲i̲t̲h̲ ̲P̲r̲i̲n̲t̲e̲r̲
6.6.4.3 H̲A̲S̲P̲ ̲W̲o̲r̲k̲ ̲S̲t̲a̲t̲i̲o̲n̲ ̲B̲S̲C̲
The HASP multileaving protocol uses a data format as
shown on figure 6.6-10. This supports a layered protocol
with the following characteristics:
o B̲S̲C̲ ̲l̲i̲n̲e̲ ̲l̲e̲v̲e̲l̲
A BSC line protocol.
o H̲A̲S̲P̲ ̲t̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲l̲e̲v̲e̲l̲
Provides additional flow and error control through
use of the Block Control Byte which includes a
block sequence number.
o F̲u̲n̲c̲t̲i̲o̲n̲ ̲L̲e̲v̲e̲l̲
Uses the Function Control Sequence (FCS) to manage
the flow of the individual streams.
The protocol supports:
- one console steam,
- up to 7 readers,
- up to 7 printers or punchers
Fig. 6.6-10…01…H̲A̲S̲P̲/̲R̲J̲E̲ ̲-̲ ̲M̲u̲l̲t̲i̲l̲e̲a̲v̲i̲n̲g̲ ̲D̲a̲t̲a̲ ̲B̲l̲o̲c̲k̲ ̲F̲o̲r̲m̲a̲t̲
o B̲l̲o̲c̲k̲ ̲L̲e̲v̲e̲l̲
Consists of a sequence of records from the active
streams.
o R̲e̲c̲o̲r̲d̲ ̲L̲e̲v̲e̲l̲
Identifies through use of the Record Control Byte
(RCB) and the Subrecord Control Byte (SRCB), the
stream owing the record and the type of data within
the record.,
Data in the record may be compressed through the
use of String Control Bytes (SCB). This SCB differs
slightly from the SCB used in SNA and supported
by JES3 and therefore, full advantage can only
be achieved when compressing blanks, but in all
cases, the emulator will resolve the incompatabilities.
Fig. 6.6.-11 and 6.6.-12 show flow examples for
a HASP-MULTILEAVING station.
Fig. 6.6-11…01…D̲a̲t̲a̲f̲l̲o̲w̲ ̲H̲A̲S̲P̲ ̲-̲ ̲S̲N̲A̲…01…R̲e̲a̲d̲e̲r̲f̲l̲o̲w̲ ̲w̲i̲t̲h̲ ̲C̲o̲n̲n̲e̲c̲t̲/̲d̲i̲s̲c̲o̲n̲n̲e̲c̲t̲
Fig. 6.6-12…01…D̲a̲t̲a̲f̲l̲o̲w̲ ̲H̲A̲S̲P̲ ̲-̲ ̲S̲N̲A̲…01…P̲r̲i̲n̲t̲e̲r̲f̲l̲o̲w̲ ̲w̲i̲t̲h̲ ̲C̲o̲n̲n̲e̲c̲t̲/̲d̲i̲s̲c̲o̲n̲n̲e̲c̲t̲
6.6.4.4 I̲B̲M̲ ̲S̲N̲A̲ ̲P̲U̲.̲T̲1̲
The nodes contain support for attachment of devices
of Physical Unit Type 1 (PU.T1). Architecturally speaking,
this support is given via the boundary function in
the node, which itself is considered a PU.T4.
The boundary functions are:
o Translation of outbound Path Information Units
of type 1 (FID1 PIU) into units of type 3 (FID3
PIU). This translation consists of:
- mapping the global addresses in the Transmission
Header (TH) into a local device identifier
and a session identifier.
- possibly segmenting the PIU into several smaller
PIUs.
o Inverse translation for inbound traffic.
o Checking and generating sequence numbers in FID1
PIUs.
o Flow management by generation of pacing responses
according to host considerations and reception
of pacing responses according to device considerations
as specified in the BIND request.
The profiles supported by the boundary functions are:
o Function Management profile 2 or 3
o Transmission Subsystem profile 2 or 3
o No function Management Headers
Some restricted SNA devices do not fully qualify as
PU.T1. Such devices must qualify as Logical Unit Type
0 (LU.T0) and must have full PU.T1 support and some
logical unit support provided by the node. Physical
unit support consists of proper processing of the session
control commands:
o Activate Physical Unit (ACTPU)
o Deactivate Physical Unit (DACTPU)
o Activate Logical Unit (ACTLU)
o Deactivate Logical Unit (DACTLU)
Logical Unit support is device dependent.
ACDN provides general boundary functions for PU.T1
and PU.T1 support for IBM 3270 BSC devices as explained.
Non-SNA devices which appear as PU.T1 through emulators
will utilize boundary functions and physical unit support
built into the emulators.
6.6.4.5 I̲B̲M̲ ̲S̲N̲A̲ ̲P̲U̲.̲T̲2̲
Architecturally support for attachment of devices of
Physical Unit Type 2 (PU.T2) is given through boundary
functions in the node in a way similar to the support
given to PU.T1s described in the previous section.
PU.T2 boundary functions are:
o Translation of outbound FID1 PIUs into FID2 PIUs
by compression of address fields.
o Inverse translation of inbound PIUs.
o Flow management as explained in the previous section.
ACDN provides general PU.T2 boundary functions supporting:
o Function Management profile 3 or 4
o Transmission Subsystem Profile 3 or 4
6.6.4.6 T̲r̲a̲n̲s̲p̲a̲r̲e̲n̲t̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Non standard devices can be connected to ACDN through
a transparent transmission interface.
The requirements for such a device are the following:
o It must use one of the available line interfaces
and line protocols specified in Section 6.6.2.
o If the asynchronous interface is used, a time out
value can be given to be able to determine an end
of message condition instead of a specific data
forwarding character.
o If a character oriented synchronous line protocol
is used, the synchronisation and termination characters
must be specified. ACDN is then able to accept
and send blocks of data to the device, but all
line protocol functions must be performed by the
remote user. This may prove difficult if the protocol
is strongly timing dependent.
o Maximum bandwidth must be specified. When normally
loaded, ACDN will be able to accept and deliver
data at this rate, but not higher. If it must
be guaranteed that the specified bandwidth is always
available, then trunks dedicated for this type
of traffic must be included.
o Either the device must be permanently connected
to another user, or the network operator must log
the device onto this other user before transmission
can commence.
o No recovery facilities at the end user level are
provided for by ACDN.
In addition the following must be specified:
o Linespeed and an external clock of X1, X16, X32
or X64 must be supplied.
o Number of bits; 5, 6, 7, and 8 per character
o Even, odd or no parity
o An 8 - or 16 bit sync. character
o One - or a list of stop characters
o A time-out value
The data will be transferred as a block betweem the
synch-character and a stop-character or until time-out.
Note that if the remote user controlling the non-standard
device resides in a host, it may not be feasible due
to host operating system restrictions to establish
connections through the front end processor.
6.6.4.7 T̲e̲r̲m̲i̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲S̲u̲p̲p̲o̲r̲t̲ ̲S̲u̲m̲m̲a̲r̲y̲
The preceding description sets out the current facilities
available. ACDN requirements for the existing terminals
CRT(405, 406, 407, 408), Flight Information Display
System Terminals, Printers, ASTAC, MAC, IBM 3278, IBM
2780, IBM 3777 are fulfilled based on a minimum of
customisation for the above- device handlers and emulators.
It is proposed to implement the customization in the
form of a Virtual Terminal facility.
Requirements for future terminal types Graphics, Portable
readres, Barcode readers, Interactive terminal, CRT
based work stations, clustered terminals involves incorporation
of new device handlers and incorporation of a virtual
terminal emulator. The choice of the facilities of
the level of the virtual terminal definition are to
be decided upon during specification phase.
Requirements for voice input/output Mobile Radio-land
mobile, Air/ground terminals involn addition of new
hardware and software at individual node sites.
6.6.5 E̲x̲t̲e̲r̲n̲a̲l̲ ̲r̲e̲s̲o̲u̲r̲c̲e̲s̲ ̲M̲a̲n̲a̲g̲e̲r̲
The ERM is conceived as a generalized component that
monitors the availability and status of all external
resources connected to a node. In the context of TAS
the ERM has the following functions:
o Initialize line
o Initialize cluster
o Initialize device
o Reset
o Request status
o Request loop test
o Report status change
o Activate/deactivate traces and statistics collection.
6.6.6 N̲o̲d̲e̲ ̲L̲o̲g̲i̲c̲a̲l̲ ̲U̲n̲i̲t̲ ̲S̲e̲r̲v̲i̲c̲e̲s̲ (NLUS)
This task manages all data flow on network control
sessions from any logical unit to the US in the NCC.
Data passed to the NCC are converted into a device
independent presentation form supporting:
o ASCII character set
o New line control character
o Transparent control sequence
o Erase presentation surface control
Inbound data from devices not yet included are rejected.
Inbound data from devices not data session are passed
from the device handler to Node Logival Unit Sensing,
converted and forwarded to US.
Outbound data from User Servicing are passed on to
the device handler.
Inbound data from devices in data session, but currently
switched to network control session, are passed from
the EM via CAS to NLUS, converted and forwarded to
US. Outbound data from US are passed back to EM.
6.6.7 N̲o̲d̲e̲ ̲S̲e̲s̲s̲i̲o̲n̲ ̲M̲a̲n̲a̲g̲e̲r̲
This task controls the session initiation and termination
for all logical units. Associated with this it performs
the overall resource management concerning the node
itself.
NSM receives session requests either from the SS in
the NCC or from a CAS in the NEUP's:
o Validate session request
o Check status of logical unit
o Select the interface to datagram or Virtual transport
facility in the NSS.
o Acknowledge session request indicating type of
the emulator to be created and connected to NSS.
Force session termination in case of:
o Command from SS
o Exclusion of resource.
6.6.8 C̲o̲n̲n̲e̲c̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲A̲l̲l̲o̲c̲a̲t̲i̲o̲n̲ ̲S̲e̲r̲v̲i̲c̲e̲s̲
The main function of the connection allocation services
is to manage the interface to the nodal switch software.
Based on information from the node session manager
(session requests) CAS creates NLU rasks and make them
connect to the Emulators).
CAS provides the necessary buffer control to interface
to the NSS.
6.6.9 C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲M̲a̲n̲a̲g̲e̲r̲ ̲a̲n̲d̲ ̲S̲t̲a̲t̲u̲s̲ ̲R̲e̲p̲o̲r̲t̲e̲r̲
This task is in support of the management of the terminals
and other resources under the scope of TAS. The main
functions are:
- Receive definition of external resources
- Receive and distribute include & exclude commands
for external resources
- Maintain status table
- Transmit status of external resources when it changes
or on request from network control function.
