Conference bulova::decw_jan-89_to_nov-90

VSG::VWSLAT is the conference.  However, your problem is that you cannot have
LAT enabled when running VWSLAT.  Do a LATCP STOP NODE first.

You should also look at LATMASTER, conference TOOK::LATMASTER.  It allows
bidirectional LAT, but lacks VWSLAT's window interface.

		Steve

I pitched VWSLAT completely when V5.3 came out with the CREATE TERMINAL command.
I generally do a SET HOST, create a terminal and log off.  Alternately, I make a
small batch procedure to do it, on systems where I have a DECnet proxy, and
create terminals by executing it with SUBMIT/REMOTE (in one case, from my
DECW$LOGIN.COM):

$ set display/create/node=artful::
$ create/terminal/detached-
        /window=(x=185,y=322,-
                 title="DCL on ''F$edit(F$getsyi("scsnode"),"TRIM")'",-
                 icon ="DCL on ''F$edit(F$getsyi("scsnode"),"TRIM")'")-
        /insert

Enjoy.

    CREATE/TERMINAL is not a replacement for VWSLAT.  LAT is a much
    more efficient remote session protocol than is CTERM (SET HOST).
    
    Since I had last looked in the LATMASTER conference, a DECwindows
    "click and connect" interface called DDE was announced there.  I
    haven't used it yet.
    
    				Steve

re Note 2481.3 by QUARK::LIONEL:

>     CREATE/TERMINAL is not a replacement for VWSLAT.  LAT is a much
>     more efficient remote session protocol than is CTERM (SET HOST).
  
        I think that .2 was saying that SET HOST was just used to
        create a detached terminal back on the originating
        workstation's display.

        This created terminal is using neither CTERM nor LAT for its
        network link;  rather it is using the X Windows protocol
        over (presumably) a DECnet transport.  How does THAT compare
        with LAT?

        Bob

CREATE/TERMINAL runs the DECwindows terminal emulator through the X
server/client connection.  CTERM doesn't come into it.  Its use of CPU time on
the server is neglible.  However, I've done some casual experimentation and have
found that you pay somewhat more on the client (where DECTERM is actually
running).  A similiar hit is taken on the machine where you're running VWSLAT.
For me, VWSLAT loses because you have to maintain a separate window for it
and because it prevents the use of incoming LAT on your workstation.

I posted earlier version of these somwhere, but I forget where.  Here
are the three command files I use to setup terminals and other clients
on remote nodes.

  1) DECW$START_REMOTE.COM -- This is used on the workstation side to
activate a remote terminal on the node of your choice.  I typically set
up a symbol like this: ``RSTART :== @DECW$USER_DEFAULTS:DECW$START_REMOTE''.

  2) DECW$RST.COM -- This is used on the remote node to accept the
incomming connection, and to execute the next command file which is used
to setup the desired clients, such as a dec term.

  3) DECW$REMOTE_LOGIN.COM -- This is used to start whatever clients you
desire to have running on the remote node.  I use this to start several 
clients on some nodes, and just a terminal on others.  I assume that
the DECW$DISPLAY logical is already setup properly.

-=-=-=-=-=-=-=-=-=-=-
$! DECW$START_REMOTE.COM -- Start up a remote node's apps.
$!   Requires the existance of DECW$RST.COM in the
$!   root directory of the target node
$!
$! P1 = node where DECW$RST lives
$!
$ set noon
$ if p1 .nes. ""
$  then
$    type 'p1'::"0=decw$rst"
$    exit %x10000001
$  else
$    write sys$output "Remote node not specified"
$    exit %x10000002
$ endif
-=-=-=-=-=-=-=-=-=-=
$! DECW$RST.COM -- Start up applications to display on a remote workstation.
$!
$! NOTE: This file must be in the login directory.
$!
$       open/write net_file sys$net
$       close net_file
$!
$! Execute users decw$remote_login.com if there is a valid display.
$!
$       if "''f$trnlnm(""DECW$DISPLAY"")'" .eqs. "" then exit
$       if f$search("decw$user_defaults:decw$remote_login.com") .nes. "" then -
        @decw$user_defaults:decw$remote_login.com
$       exit
-=-=-=-=-=-=-=-=-=-=-=
$! DECW$REMOTE_LOGIN.COM -- Start up the tasks I care about...
$!
$! Now, Start up a decterm for this node
$!
$       create/term/detach/logged/window=(initial=icon)
$!
$! Thats all
$!
$       exit

Remote DECterms are nice in that they don't tie up local resources but they do
require a substantial chunk of memory on the client side.... VWSLAT is much
more efficient from the perpesctive of the host you are connecting too...

			Pete

RE: .7

That chunk of memory has to be somewhere--VWSLAT is also creating a DECterm.
You can either have it on your hosts or on your workstations (or whereever it is
that you run VWSLAT).  All the host systems I use have 64 to 128 Mb of main
memory--I don't feel too bad about taking a chunk for a DECterm or two.

    Agreed but our poor host machines err on the 64 Kb side and everybody
    running remotely (the DECterm and it's controller process)  soon adds
    up to quite a big hit! We encourage users to vwslat in (and use local
    WS resources instead of host resources which are strained by other
    things). 
    
    		pete

Create/terminal does not create virtual terminals.  If the network should drop
between the client and server, your process on the client gets logged out. 
VWSLAT creates virtual terminals which allow you to connect to the process
after the network drops.  You are much better off using VWSLAT.

Tracy

RE: .10

	?? I thought DECterms were disconnectable..

					mike

RE: .11

DECterms are not disconnectable.  See QAR 3684 in the DECWINDOWS-IFT database
on TRIFID for the reason why.

Tracy

Re: .12

I haven't had a chance to investigate that QAR yet, but can't you just
SET TERM/NODISCONNECT in the DECterm windows, so DECterm won't log youout
if you lose your connection to the server?

				-- Bob

Re: .13

Actually, /NODISCONNECT would say "this terminal is not capable of being
disconnected, so log it out if it 'hangs up'".  To be able to be
disconnected (thus allowing a later reconnection), you must be set up
as a virtual terminal.  DECterms and SET HOST sessions don't do this.
LAT sessions can.

				Steve

Re: .14

OK, thanks for the explanation.  (I always wondered how that worked...)

				-- Bob

    DECterms are *definitly* disconnectable, if they are started the right
    way. Several things are required to get disconnectable terminals:
    	- virtual terminals are enabled 
          (mc sysgen connect vta0/noadap/driv=ttdriver)
        - disconnect is part of the *default* characteristics of your
          terminals (check out sysgen's TTY_DEFCHAR[2])
    	- the user account is correctly defined in SYSUAF (flags). Usually,
          the default is alright.
    	- and finally, the last but not least, the virtual terminal needs
          to be created.
    
    When starting a decterm, the simplest way is something like
    CREATE/TERMINAL[/DETACH]. What requires a virtual terminal to be
    created is an \unsollicited/ terminal input on the TTDRIVER. It's in
    there that the virtual terminal is created and linked to the physical
    terminal. Therefore, to be able to have the process created by an
    unsollicited input, you must do something like CREATE/TERMINAL/NOPROCES, 
    then, hit return (this is *why* VWSLAT is having virtual terminals),
    and the log in. 
    
    I tried it a minute ago on my VS and it works like a charm. 
    
    It is possible, but you have to login. You can't benefit from any
    automatic process creation. It must go first of all thru the terminal
    driver.
    
    As of creating virtual terminals � la TTDRIVER, this is another story ...
    
    
    Pierre.

DDE is definitely in prototype stage...

It requires that you be willing and able to replace the standard VMS LAT
software with field test LAT software scheduled for Hickory.

It is not commited for product status or support.  I'd like to see it
extended to support CTERM, X.29, DTE, etc. and included as an OOTB application.

See note 110 in the LATMASTER conference.