Title: DSP2
Author: Martin Baker
Date: 11 December 1989
Doc ref:
Version 2
Authorised by:
not authorised yet - this document for review only
TABLE OF CONTENTS
0.1 - Scope
0.2 - Document History
version | date | comments |
2 | 10/12/89 | converted to wordstar 5 |
In the next month or so we will start trialing a new enhancement
to the IBM service for Mercantile Credit.
D S P II
---------
coming to a TP3 near you.
It allows Bi-Sync terminals to call SNA hosts or SNA terminals
to call Bi-Sync hosts, or any of the combinations shown below,
Terminal Host
-------- ----
Bisync <---> Bisync
Bisync <---> SNA
SNA <---> Bisync
SNA <---> SNA
The Bisync end is just an upgrade to the current BPAD service,
the only difference being a couple more options on the Menu page.
The SNA end is completly new software, it allows the terminal
to be given a menu and to switch to the host required, it works
by dismantling all the layers of the SNA protocol and converting
it to the simple DSP protocol which sits on top of X.25 and carries
the information across PSS.
DSP stands for Display System Protocol.
The system allows:
1) a control unit believe that it is in communication with one
single host while, it is in fact possible for each device on the
controller to be in communication with multiple hosts. The SNA
DSP pad achieves this by emulating some of the functions of the
host at the control unit and establishing communications to another
SNA DSP pad when application data is to be passed to a host.
2) to make an IBM host system believe that it is in communication
with a control unit with multiple devices while in fact the devices
are not really present, but in fact can be geographically anywhere
on the PDN on a SNA DSP terminal pad and when a VC is established
between SNA DSP pads then the host is again made to believe that
a device has just been powered on.
In both the cases of the terminal and the host pads, the IBM equipment
is made to believe that somthing which is not true is the truth.
The PDN and pads masks the real CU configuration from the IBM
network and
substitutes a traditional SNA configuration. The terminal user
on the other hand is now given the flexibility of a more dynamic
and flexible network where the choice and selection of application
is with the terminal user.
The SNA host may think it is controlling one Control Unit. Where
in fact it is communicating with several devices.
CNM solicits statistics and other data from a CU; this data can
be generated by the PDN devices, the SNA DSP pads; or this data
can in turn be solicited from the real CU's on the network.
It is not possible for the pads to generate any meaningful statistics
and data for CNM, especially response statistics; therefore the
only alternative is for the statistics and data to originate from
the real IBM control units.
The Configuration software provides for this by allowing a 'dummy'
CNM device to be defined with a device address of 00.
DSP2 is only supported by Network release 3.31 (which means we
have to use the OSI machine for now)
It runs on TP3s and it uses the following code modules,
SNA Term PAD CN661G
SNA Host PAD CN660G
BSC Term PAD CN622O
BSC Host PAD CN620P
It uses the following PGP templates:
BSC: csyspr58
cthdsp42
cdprof44
cdev55
cfac68
SNA: csyspr58
cdprof44
cdev55
chpadl44 - defines line (may have progressed to chpadl48)
cfac68
chpadd53 - defines devices