|
In this diagram, any SAM used for remote access
would be replaced with a DT-4000.These DT-4000
are used as standalones.That is, they are multi-
protocol IP terminal servers without any direct
connectivity to any Datakit node. The data is provided
connectivity by mediation in the UMI module.
All Datakit nodes, except for the single node at the host
site, are no longer required.Transport of data will now
occur on the IP infrastructure. These nodes may be
removed from service if they have no other function.
The UTM, or any other Datakit Trunk which can be
used to access the SAM, is replaced with a UMI
module to provide URP to TCP/IP meditation
services.This allows complete connectivity to all
endpoints through a single module.
A DT-4000 is provided locally to the node to
terminate the Bisync printer lines from the BTIM.
These connections are then PPD'd through the IP
infrastructure to another DT-4000 port on which the
printers are actually resident.This allows all DSUs and
other dedicated line equipment to be removed in
their entirety.
The Control Computer Complex console, and the
UMI console, are connected to ports on the DT-4000.
This allows IP/TCP/telnet access to all configuration
points of the interface.
User procedures are the same as before. A user at an
asynchronous terminal would dial the address of the
AtoB application at the DT-4000 Destination prompt.
This would connect the DT-4000 to the UMI module.
The UMI would then set up a call to the AtoB DKAP
application.The data transport from this point
forward is identical to the preconversion scenario.
An asynchronous printer would reside on a DT-4000
user port. When the DKAP AtoB application makes its
PDD to the UMI, the UMI will in turn make a PDD to
|
|
the DT-4000 port on which the printer resides.This
operation is identical to the original preconversion
deployment.The difference is that the AtoB PDD now
resides as a UMI mediation session.The data
transport from this point forward is identical to the
preconversion scenario.
A BiSynchronous printer would have its link
connected directly to a port on the DT-4000
configured for either EBCDIC Bisync ar ASCII BiSync
as necessary. The DT-4000 port would be PPD'd to
another DT-4000 port at the host site configured
identically. The host site DT-4000 port is then
connected to the BTIM port for that printer. The data
transport from this point forward is identical to the
pre-conversion scenario.
A TN3270 client would access the IP infrastructure
directly to the UMI.The UMI would then connect the
TN3270 client to the TN3270 DKAP application.The
TN3270 DKAP application works identically to the
AtoB DKAP application except for a specialized client
set instead of a generic terminal.
If connectivity to another operations system is
required (e.g. MLT, Craft Access, etc.), this connectivity
is also completely provided by the IP infrastructure.
On a per virtual circuit basis, the LMOS host would
make a Datakit call to the UMI as if it were an
endpoint on a Datakit network.The UMI will mediate
that Datakit call onto the IP infrastructure and make a
TCP/IP call to the destination endpoint. If the
destination endpoint is also a Datakit based
operations system, the TCP/IP call will terminate on a
second UMI.That second UMI would then make a
Datakit call setup to the operations system. Neither
UMI is required to be local to the operations system
they support.
new stuff
|
