Conference bulova::decw_jan-89_to_nov-90

    VWSLAT, at least the version we run internally, supports DECwindows -
    I use it every day.  I am unsure if the version in ASSETS has the
    DECwindows support.  Ask in the VSG::VWSLAT conference.
    
    				Steve

I got my copy of VWSLAT from:

Directory PRNSYS""::SYS$SYSROOT:[SYSEXE]

VWSLAT.EXE;41            103  30-JAN-1989 15:28:16.00
VWSLAT.EXE;40            105  22-NOV-1988 11:22:20.00

Total of 2 files, 208 blocks.

Directory PRNSYS""::SYS$SYSROOT:[SYSHLP]

VWSLAT.HLB;8              42   6-JUN-1988 11:33:32.00

Total of 1 file, 42 blocks.

Grand total of 2 directories, 3 files, 250 blocks.

On a related note, is there a VWSSSU that will work on DECwindows V1 ?

								-Jeff

    
    Steve 
    
    	Thanks for your input, I dont seem to be able to access
    VSG::VWSLAT, do you know the node address for VSG, I get two different
    addresses depending on which of my nodes I use.
    
    Thanks Ken DC

    VSG's node address is 55.563 (VSG).  Its off the air at the moment, but
    I was using this address successfully last evening.

                 Dave

1. VWSLAT for DECWindows can indeed be obtained FOR INTERNAL USE ONLY from
PRNSYS, as shown in the earlier notes.  Just copy to your SYS$SYSTEM and
SYS$HELP areas, TURN OFF INCOMING LAT WITH LATCP STOP COMMAND, run
VWSLAT and say HELP.

2. The DECWindows capable version of VWSLAT is NOT currently available
from ASSETS, and therefore cannot yet be given to customers.  A
submission has been made - but it is NOT yet available for customers. 
It will be.  Contact Bill Ziminsky to find out if there is a schedule
yet.

3. VWSSSU IS available for DECWindows. (Again, for internal use only.)
PRNSYS::DUA1:[LOMICKAJ.VWSSSU]VWSSSU.EXE, dated 3-Feb-1989, works on
both VWS and DECWindows, VMS V4.7 or V5.  Note that, since it's not
linked against any DECWindows libraries, the old one works fine too.
VWSSSU allows you to connect multiple sessions to a remote host that
has VMS SSU, over a simple serial (terminal) line.  It tends to be a
little quirky, but some people like it.

The latest versions of CHILD (release 12), VWSSSU (Today's), and VWSLAT
(Today's) all now support a better version of the /CUSTOMIZE option, in
that you can now say
"/CUSTOM=("resource:value","resource:value","resource:value"...)".

(There is a bug in the 30-Jan-1989 version of VWSLAT that prevents
specifying more than one element in the /CUSTOM list.  Today's version
fixes that.)

I'm a bit confused as to what VWSLAT and VWSSSU buys you that you can't get 
directly from DECwindows? The only reason for using VWSLAT is to get easy access
to non-workstation systems. DECwindows does this today simply by starting the
terminal controller directly on the non-workstation client, creating a terminal
using something like DECW$MAIL_CREATEDECTERM.EXE and logging in directly to 
the remote system. Also this configuration has one very significant benifit, the
terminal emulator runs on the remote client, while the graphics is done on the 
workstation. The net benefit is that the resources are better utilized. 

Take for example a configuration where you have a VS-II front-ending an 8800.
Using VWSLAT, both the terminal emulator and the graphics must be processed on
the VS-II effectively dividing the 1 mips machine in two. Thus for a single 
threaded job on the 8800 the available CPU is 1 8000 class processor for the 
user program and 1 VS-II spread between the DECterm and the server.

Contrasting the DECwindows only solution (starting the terminal emulator on
the 8800), the resources get divided significantly differently. You get 1 8000
class processor for the user job, 1 8000 class processor for the terminal 
emulator and the full MV-II for the server. The difference in performance is
noticable and impressive.

Why don't we start using the distributed capability that DECwindows offers?

James

P.S. To illustrate the point, I running NOTES on a system sitting in ZK-2 but
displaying this on and sitting in front of a system in ZK-1 basement. Let's use
DECwindows to it's fullest capability! 

DECwindows uses DECnet links.  I can use LAT to start a session on a remote node
even if all its links are taken up copying kits out to elsewhere on the net
(as is currently the case on PAGODA, for example).

--PSW

My interest in VWSSSU was so that I could sit at home on a minimal decwindows
workstation, establish an asynch connection to a node at the office, and use
VWSSSU to multiplex multiple (terminal) windows at home to multiple processes 
at the office.

I'd really rather use the X protocol, but since X over asynch decnet at 2400
baud is said to be a dog-ola, and since there isn't yet (?) an async-X
protocol, this is the next best thing.

							-Jeff

       
       
       	VWSLAT also allows you the wonderful feature of re-connecting to
       disconnected processes when the net goes >burp<.. CTERM doesn't.
       Nor does X.
       
       							mike

>      	VWSLAT also allows you the wonderful feature of re-connecting to
>       disconnected processes when the net goes >burp<.. CTERM doesn't.
>       Nor does X.
    
    "X" doesn't, but DECterm can easily be made to.  The trick is that you
    must explicitely login.  Use CHILD/NOCOMMAND to get yourself a terminal
    that you can hit <CR> in to get the login prompt.  This will be a
    disconnectable process.
    
    Regards,
    
    Marios

    Another reason.  I'm in the Portland Oregon office.  We have DECnet
    access to Seattle over a 9600 baud line.  LAT access is over a 56K
    baud line.  Anytime someone copies a file, or some other large decnet
    job, my response goes to heck. (Unfortunately, most of the compute
    resources I need are in Seattle.) 
    
    I am about to turn my GPX in for a VT330 so I can get some response
    time!  (There are times when using WPSplus that I get 1 or 2 second
    response time,  between characters.  Verrrry slow.)
    
    David

RE: .12

>    Another reason.  I'm in the Portland Oregon office.  We have DECnet
>    access to Seattle over a 9600 baud line.  LAT access is over a 56K
>    baud line.  Anytime someone copies a file, or some other large decnet

Huh??  I thought LAT was an ethernet-only protocol.

--PSW

    He's talking about the lines connecting the bridges.
    
    It is common to configure two bridges and dedicate one to LAT traffic.
    
    -fjp

    That sort of configuration is quite common in the field.
    
    It also reflects that terminal to centrally located timesharing
    computer connectivity is viewed as mainstream and business-oriented and
    merits first class 56KB circuits.  DECNET traffic is for "hacking" and
    gets second class 9.6 KB circuits.  (With the probable result of having
    lightly loaded LAT circuits and saturated DECNET circuits) 
    
    But that has nothing to do with the merits of LAT vs. DECNET
    connectivity in a DECwindows context.  VWSLAT was never released to
    customers.  Is there something about DECwindows that creates a customer
    requirement for LAT for terminal connectivity?
                                                  

    
    Pat,
    
    VWSLAT is in ASSETS, so in a sense it has been released to customers
    in a limited way.
    
    

    First off, thanks to those of you who pointed me in the right
    direction.
    
    Next, why I want to use VWSLAT and am not using the full potential of
    DECWindows. I am putting together a demo for the afore mentioned
    IT conferance, when I use the term conferance it conjures up images
    of a plush hotel, the location is infact portacabins supplied by
    the customer who wanted to dangle an async line in though the window
    so that we could connect to the IBM via a gateway therefore VWSLAT.
    
    Once again thanks
    
    Ken DC  

For me, where ALL of these options are available (SET HOST, VWSSSU,
VWSLAT, DECWindows remote windows with CHILD), VWSLAT wins on the following:

- Ease of use.  I start one process on my workstation, and I can
connect to any nearby "big" computer with a single command to the VWSLAT
processes.

- Performance.  VWSLAT appears TO ME to run faster than the
alternatives, when going to the same node.

SET HOST requires that I log in a new session, or at least spawn a
subprocess with CHILD, which takes longer.

DECWindows provides no convienent and reliable method for initiating
sessions on remote notes.

>Note 70.15              VWS LAT EQUIVALENCE IN DECWINDOWS               15 of 15
>CALL::SWEENEY "Patrick Sweeney"                      13 lines   5-FEB-1989 20:14
>--------------------------------------------------------------------------------
>    
>    connectivity in a DECwindows context.  VWSLAT was never released to
>    customers.  Is there something about DECwindows that creates a customer
>                                                  
	VWSLAT is available to customers, via the ASSETS mechanism.  I've
	yet to see the need for this type of connectivity for most customers.

Mark

Can anyone give me a pointer to the VWSLAT kit?

Helena

I think you'll find what you need at TMCUK2::SYS$KITS:[VMS.LAT] - its' not
a kit but there's only a couple of files. I got mine from there and it's
fine.

Martin

The "latest" DECWindows version of VWSLAT is always:

PRNSYS::SYS$SYSTEM:VWSLAT.EXE ---move to your own---> SYS$SYSTEM:
PRNSYS::SYS$HELP:VWSLAT.HLB   ---move to your own---> SYS$HELP:

that's it.

	I copied the VWSLAT software and tried to run it. I get the following
error.


%DCL-W-ACTIMAGE, error activating image VAXCRTL
-CLI-E-IMGNAME, image file $1$DUA0:[SYS0.SYSCOMMON.][SYSLIB]VAXCRTL.EXE
-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image

     Here is an extract from the VAXCRTL.EXE ana/image.
	
	Image Identification Information

		image name: "VAXCRTL"
		image file identification: "V05-001"
		link date/time:  8-APR-1988 10:04:10.22
		linker identification: "04-92"


     We are running VMS V5.1

     Does VWSLAT.EXE need to be relinked ?

				Joe

    It was probably linked against the newer VAX C 3.0 RTL.  It seems to
    work fine on a 5.2/5.3 system.  If you want an older version of VWSLAT,
    send me mail.  I've saved about 8 generations of the .EXE dating back
    to 11/88.

                Dave

Yes, I've been using VAXC V3 for a while.  If you can't get a V5.1
version, let me know and I'll link one up.

(It's a real pain trying to distribute software from an VMS FT V5.3 system.) 

Uhhh... The  version  of  VAX  C has nothing to do with the version of the C
RTL.  The C RTL ships with VMS, not the compiler. Talking about the V3.0 RTL
dosn't make any sense.  Refer to RTL's by the VMS version...

- Brad

    We are having a major problem implementing VWSLAT on DECwindow'ed
    VS2000's with 6 meg. memory.  The problem is that the first session
    connects properly to whatever node, but the second attempt at
    connecting to another node "craps out" with the basic stack dump, at
    which point the first session gets disconnected (window goes away) and
    LAT, of course, is dead.
    
    We have the "latest" version of VWSLAT (taken from PRNSYS::) and
    also the "latest" version of CHILD (also from PRNSYS::).  We have tried
    implementing VWSLAT from SYS$MANAGER:DECW$SYLOGIN.COM, from the user's
    DECW$LOGIN.COM, OR from entering commands directly in an existing
    DECterm window.  (All three work on VSII's and VAXstation 3100's with
    varying amounts of memory - but it ALWAYS fails on second connect on
    VS2000's).
    
    Here are the commands we have used which worked, or didn't, as stated
    above:
    
    1) CHILD/SHRINK/PAGE=24/PROC="LAT"/itit="some icon"/tit="some
       title"/decterm/line/insert "RUN SYS$SYSTEM:VWSLAT"
    
    2) CHILD/IMAGE=SYS$SYSTEM:LOGINOUT.EXE/NOPASSWORD/PRIV/INPUT=STARTLAT.COM 
       /DETACH/PAUSE=5/SHRINK/DECTERM/LINE/INSERT/PROC="process
       name"/itit="icon title"/tit="some title"
    
       where STARTLAT.COM is:
            $define/user sys$input sys$output:
            $run sys$system:vwslat
            $logout
    
    Please assume that the above commands are either on a single command
    line or are properly continued on the next line (hyphenated).
    
    My question is basically this:  Why does this work on a VSII (one with
    only 5 Meg memory) or a VS3100 (8 meg minimum), but NOT on a "standard"
    VS2000 with 6 meg?
    
    Does anyone have recommendation(s)?  Are there SYSGEN parameters that
    may be recommended that we are overlooking?  Working set parameters?
    Job limits or quotas?  We are mildly frustrated and confused (!) and 
    would GREATLY APPRECIATE ANY HELP AND SUGGESTIONS.   We anxiously await
    any replies.    Thanks,  David

	I would check the revision levels of both the CPU boards and the
Ethernet controller boards in the 2000s.  I've seen weird problems with 2000s
on a busy Ethernet.  It wouldn't surprise me that this might just be a similar
situation, with VWSLAT enabling multicasts and the controller not being able to
keep up...

VS IIs and 3100s work because that have a slightly different Ethernet
controller, although the 3100 not that different from the 2000.

Mark

    I've seen this posted in at least three places (spread over two
    conferences I think).  I just suggested something wherever I saw
    it last.

              Dave