GDSX Manual

Overview of GDSX
Extended General Device Support (GDSX) Manual–134303
1-9
Direct Terminal Access
•
Intelligent devices such as personal computers, point-of-sale devices, ATMs,
communication lines, or Guardian processes, and the 6540 terminal operating as a
personal computer.
There is a wide variety of other general-purpose and special-purpose terminals in the
marketplace, and many of these terminals differ significantly from those that
Pathway/TS supports. Despite not being able to interface Pathway/TS to these
nonsupported terminals directly, many applications stand to benefit greatly from
NonStop TS/MP server class resource management and other features.
To widen the applicability of Pathway/TS, the GDSX product was developed to serve as
an intermediate process between Pathway/TS and an I/O process, handling the terminal
protocol on the I/O process side, and sometimes simulating a terminal supported by
Pathway/TS on the TCP side. (The Pathway/TS requester is usually configured for
Intelligent Device Support [IDS] mode, so that the program does not control how data
appears to the intelligent device, nor does it perform any other device-dependent
functions.)
Direct Terminal Access
In an application using Pathway/TS and GDSX, the Pathway/TS TCP simultaneously
supports multiple threads. Each thread is a continuing session with an I/O device,
typically a terminal. A SCREEN COBOL program controls data transmission with the
terminals. The terminals typically act as input devices for requests that are sent to server
classes for processing.
When an application using Pathway/TS and GDSX is started, the GDSX process is
started first. For example, the following TACL RUN command can be issued to run a
GDSX object named $GDS:
> RUN GDSE /NAME $GDS, NOWAIT/
Then, depending on the application design, SCF might or might not be used to configure
subdevices (SUs) and lines (LINEs) before Pathway/TS is started. For example, if a
GDSX application is designed to use SCF to preconfigure SUs T1 and T2 using devices
$T1 and $T2, the following commands could be issued:
-> SCF
-> ADD SU $GDS.#T1
-> ADD SU $GDS.#T2
Note how the device names $T1 and $T2 become #T1 and #T2, respectively, when
combined with the GDSX process name in these commands. When GDSX receives
these commands, it derives the proper device names but does not open the files until
receiving an open message from Pathway/TS.
Then, in the Pathway/TS command interpreter, PATHCOM, you configure terminals to
be opened through GDSX. In this example, if a Pathway/TS requester is to
communicate directly (without a LINE) with device $T2 through a GDSX process
named $GDS, the file name $GDS.#T2 is used in a series of PATHCOM commands:
= SET TERM TCP TCP-X
= SET TERM TYPE T16-6530:0
= SET TERM INITIAL LOGON-SCREEN