[comp.os.vms] VAX GKS, VT330/VT340 and SSU.

ZWARTS@HGRRUG51.BITNET.UUCP (09/30/87)

Hello,

We have a large collection of interactive command driven programs. Up to a few
months ago all graphics in these programs went through a private library of
routines, which supported only one graphics terminal type.

We now want to convert to GKS. We have written a few device handlers for some
of the terminals we have. And we have bought a few VT330s and a VT340, all with
a mouse.

The problem is that GKS leaves the terminal in Regis mode in between
calls to GKS. This means that the interactive conversation of the program and
its user will be interpreted by the terminal as Regis commands. When we ordered
the terminals GKS did not yet support them, but we assumed that GKS would treat
them in a way similar to the VT240, which it does not leave in Regis mode. So,
we are somewhat disappointed.

However, maybe there is a solution if we use the dual session features of the
VT330/VT340. We tried already to use two physical connections between a
terminal and the Vax and indeed, in this way we can separate the Graphics I/O
from the Command I/O, having them in separate windows.

The next problem is that we do not want to use two terminal ports for each
terminal (We do not even have enough ports). A solution for this problem could
be the SSU software, which would enable dual sessions using a single physical
connection. We do not have SSU ourselves and we could not yet find someone with
enough experience to answer the following question:
Can SSU be used to solve our problem, i.e. is it possible to use SSU to start
one session on the Vax and then let the application on the Vax start the other
session, so that the application can send its graphics I/O to one window and its
text i/o to the second window?
Is there someone who has actually tried this? Or does someone have a better
solution for our problem?

From DEC we got the impression that it would not be possible to open a session
from the Vax, but only from the terminal. Is it true that DEC did not learn a
lesson from similar problems with the first releases of the LAT software?


        F. Zwarts                               Phone:          (+31)50-633619
        Kernfysisch Versneller Instituut        Bitnet/Earn:    ZWARTS@HGRRUG51
        Zernikelaan 25                          Surfnet:        KVIANA::ZWARTS
        9747 AA  Groningen                      Telefax:        (+31)50-634003
        The Netherlands