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

versiondate comments
2 10/12/89converted to wordstar 5


1.0 - Introduction

DSP2 - an overview - by Martin Baker

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.

What is DSP2 ?

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.


CNM - Communications Network Management

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.


Telenet Software

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