From:	CSBVAX::CSBVAX::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 27-FEB-1989 13:26
To:	MRGATE::"ARISIA::EVERHART"
Subj:	DECwindows goodie


Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Thu, 23 FEB 89 22:32:44 PDT
Received: from CUNYVM.CUNY.EDU by KL.SRI.COM with TCP; Thu, 23 Feb 89 22:16:41 PST
Received: from YMIR.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 7093; Fri, 24 Feb 89 01:16:04 EST
Received: from FRIDAY.A-T.COM by YMIR.BITNET; Thu, 23 Feb 89 20:13 PST
Date: Thu, 23 Feb 89 20:07 PDT
Message-id: <00920D308EB0D2A020404A49@YMIR.BITNET>
From: "Kevin V. Carosso" <@YMIR.BITNET:KVC%FRIDAY.A-T.COM@CUNYVM.CUNY.EDU>
Subject: DECwindows goodie
To: info-vax@kl.sri.com
X-VMS-To: in%"info-vax@kl.sri.com", kvc

Well, now that V5.1 and DECwindows is out lets get some VMS DECwindows
related goodies onto this list!

To start things rolling, here's a little hack to allow non workstation hosts,
generally large, multiuser VAXen, to create a DECwindows (DW from now on, my
fingers are tired of that!) LOGINOUT screen on a workstation running just the
server.

Our little development cluster here at Ashton-Tate consists of a fairly hefty
MicroVAX 3600 with a couple of GPX workstations (till our PVAXen show up :-).
We all like running on the 3600 and it's a pain to login on the GPX and then
use SET HOST to get your terminal windows onto the faster machine.  Also,
things like DW MAIL and DW TPU are kinda slow to start up and the 3600 makes a
difference.

When DW starts up it determines if it is running on a workstation or not. If
not, it simply does the things that need to be done on a client-only machine,
not much, and exits.  On a workstation it goes on to start the server and then
create a DW LOGINOUT process which throws up the wonderful "|D|i|g|i|t|a|l|"
logo and the "Username/Password" dialog box.

What we do here is create the DW LOGINOUT on the client-only machine and not on
the workstation.  When you login your session manager, window manager,
DECterm controller, etc. processes are all running on the client-only
machine with all windows directed, by default, to the workstation over
the network.

This sort of configuration is also useful for VAXstations, like the 2000,
which might not have enough memory or CPU to handle the DW X server as
well as all your DECterm sessions and DW applications.  By running the
server only, it may well be possible to get acceptable DW performance out
of a VAXstation 2000 with only 4 Mb of memory.  I have not tried it, but
I suspect this is a good way to breathe some new life into such a system.
I do know that my 16 Mb VAXstation II/GPXs make fine DW server-only
machines...

By the way, you can have multiple LOGINOUT dialog boxes on a workstation and
you can even login through all of them, creating an interesting jumble of
session managers, icon boxes, etc!  Of course the LOGINOUT dialog boxes are
always created at the same screen coordinate so you only see one on the screen
until you satisfy it, uncovering the next one.  Interesting, but not terribly
useful.

Anyway, back to the topic at hand...

To get this to work, you need to do the following:

Step 1:
-------
You have to modify the DW startup slightly to allow for the site-dependent
DECW_LOGIN_SATELLITES.COM procedure to be invoked. Unfortunately this mod is to
a Digital-distributed DCL command procedure, DECW$STARTAPPS.COM, which may be
replaced in future releases.  It is a simple change but keep in mind that you
may have to check and reapply it later.  DECW_LOGIN_SATELLITES.COM should be
modified for your configuration and placed in SYS$COMMON:[SYSMGR].  It is meant
to be executed by all members of a cluster.  A DIFFERENCES listing of my
DECW$STARTAPPS.COM with the standard VMS V5.1 version appears at the end
of this message.

DECW_LOGIN_SATELLITES.COM is called by all systems at startup and is solely
responsible for creating DW LOGINOUT processes for a client on the appropriate
satellite workstations.  Note that the workstations run this as well, but if
they don't have an entry they won't start a DW LOGINOUT on themselves.  They
could, if you so choose, or they could create one on another satellite
workstation.  That might be appropriate if you have a big fast workstation and
want to allow another user from a small VAXstation 2000 onto the big
workstation.  Keep in mind that the two-user license limit for workstations and
VAXservers will be enforced with DW LOGINOUT.

I run my client hosts and my workstations all in one homogeneous LAVC.  Since
DW only requires a network connection between client and server, the client
and the satellite do not have to be in the same cluster.  You will need
to keep an appropriate copy of DECW_LOGIN_SATELLITES.COM on each, however.

My DECW_LOGIN_SATELLITES.COM appears at the end of this message.

Step 2.
-------

When the DW server starts up, it maintains a list of hosts which are allowed to
make network connections to the server.  There are, apparently, two categories
of access: "trusted" and "allowed".  I have not experimented much with this,
but I believe "allowed" means that the incoming host may create windows and do
other typical X functions while "trusted" would also permit the incoming host
to perform such privileged functions as modifying the list of allowed hosts.

By default, the DW server considers only itself to be "allowed" and "trusted".
Once you have logged into the session manager, the list of hosts with "allowed"
access is modified to those you specified in your security customization.  When
you logout the list reverts to the local host only (this was not true in FT
DW -- your access list stuck around after you logged out.  I'm glad they fixed
it before final release.).

To modify this behaviour the server reads, at startup time, files called
DECW$SERVER_ACCESS_TRUSTED and DECW$SERVER_ACCESS_ALLOWED using
SYS$MANAGER:.DAT as the default file specification.  This action, as well
as the format of these files, is not documented anywhere that I could find.
I did, however, figure out all I needed to know about the process.  These
files consist of entries, one per line, of three fields separated by
whitespace.  The fields are: PROTOCOL-NAME SYSTEM-NAME USER-NAME.
An asterisk, "*", may be used as a wildcard match.  The default is
equivalent to DECW$SERVER_ACCESS_TRUSTED.DAT containing the line:

        * 0 SYSTEM

meaning trusted access is granted to any protocol connection, from myself
(host 0), with username SYSTEM.

Since the session manager needs to modify the list of allowed hosts when you
login to DW, I assumed that "trusted" access is required for my remote
login trick and didn't experiment with DECW$SERVER_ACCESS_ALLOWED at all.

My DECW$SERVER_ACCESS_TRUSTED file contains an entry specifying all
protocols, username "SYSTEM", for the local host and then for each member
of the cluster for whom I may want to allow DW LOGINOUT to run.  Since
DW LOGINOUT runs as "SYSTEM" that is the only username that needs to be
specified.  Other users and hosts may be specified in your session manager
security customization just as before.

Here's mine:

        * 0 SYSTEM
        * FRIDAY SYSTEM
        * MARDI SYSTEM
        * LUNDI SYSTEM

Step 3.
-------

Edit DECW_LOGIN_SATELLITES.COM to your configuration. Basically you define, for
each client host that you wish to start a login process, what workstations to
use.  The comments and examples in the file should be sufficient to get you
started.

Step 4.
-------

You have to restart the DW server to make it read DECW$SERVER_ACCESS_TRUSTED.
Log in from a LAT terminal or to the console port or over the network as
SYSTEM and restart the server with:

         $ @DECW$STARTUP RESTART

This takes awhile, but eventually things will stabilize.  You may end up with
a login dialog on the screen or not, depending on whether the restart used
your new DECW_LOGIN_SATELLITES.COM procedure.  If you do get a login dialog
you must kill its process.  Hunt down and kill the process with the
characteristics:

                    Phys                    Base Process         Image
     PID    Term    Term Username     State Prio Name            Name
-------- ------- ------- ------------ ----- ---- --------------- --------------
20E0013F                 <login>      lef      4 _WSA2:          *Loginout

(this is output from our NAMES utility.  You'll have to look for something
 similar with SHOW SYSTEM).

The login dialog should disappear, leaving the workstation screen blank.

The login to the client hosts and execute DECW_LOGIN_SATELLITES.COM on
each one.  You should see the appropriate dialogs start up on your
worstations.

Caveats:
--------

There are some minor problems.  Since the DW LOGINOUT process is meant to
be robust to errors from the server, it will kill itself and create a new
process if anything goes wrong.  This can make your client host look
pretty busy if it's trying desperately to create a login dialog on a
workstation that has gone south.  You can kill the process (type fast!, those
PIDs increment fairly rapidly!) and restart it later (using
DECW_LOGIN_SATELLITES.COM or by hand if that would affect other logins
that are working ok and create duplicates!)

I have rebooted the client machines and the workstations individually with this
but I have not rebooted everyone at once.  I think it will work then, but
don't know for sure.

There may be other problems I don't know about.

Please let me know if you enhance this thing.  I will try to help if you have
trouble but I'm pretty busy these days.  I am looking at other interesting
DW tricks and hacks and hope that others out there are as well!


        /Kevin Carosso                        kvc@friday.a-t.com
         Innosoft International Inc.          kvc@ymir.bitnet

Attachments follow:

Difference listing of DECW$STARTAPPS.COM:
------------------------------------------------------------------------------
************
File SYS$COMMON:[SYSMGR]DECW$STARTAPPS.COM;4
   78   $ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
   !!!!!!!
   79   $ !
   80   $ ! Local modification to allow our workstations to function as X "satel
   lite"
   81   $ ! nodes and login to the larger members of the cluster.   /Kevin Caros
   so
   82   $ !
   83   $ if f$search("SYS$MANAGER:DECW_LOGIN_SATELLITES.COM") .nes. ""
   84   $ then
   85   $       @sys$manager:decw_login_satellites
   86   $       goto apps_done
   87   $ endif
   88   $ !
   89   $ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
   !!!!!!!
   90   $
   91   $ ! If we are not on a workstation, then we are now done.
******
File SYS$COMMON:[SYSMGR]DECW$STARTAPPS.COM_ORIGINAL;1
   78   $ ! If we are not on a workstation, then we are now done.
************

Number of difference sections found: 1
Number of difference records found: 13

DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=D0:[KVC]Z.Z;6-
    SYS$COMMON:[SYSMGR]DECW$STARTAPPS.COM;4-
    SYS$COMMON:[SYSMGR]DECW$STARTAPPS.COM_ORIGINAL;1
------------------------------------------------------------------------------

Listing of DECW_LOGIN_SATELLITES.COM:
------------------------------------------------------------------------------
$ ! DECW_LOGIN_SATELLITES.COM
$ !     - written by Kevin Carosso @ Innosoft, 16-FEB-1989
$ !
$ ! This locally modifiable command procedure is invoked by a slightly
$ ! modified DECW$STARTAPPS.COM.  Instead of checking to see if we are
$ ! a workstation and then starting one DECwindows LOGINOUT process, we
$ ! have a list of "satellite" workstations for each host.  The host will
$ ! start up one DECwindows LOGINOUT process for each of it's designated
$ ! satellites.  A host may have itself as a satellite.  The LOCAL transport
$ ! will be used if the host and the satellite are the same, the DECnet
$ ! transport will be used otherwise.
$ !
$ ! Note that we cannot start up a LOGINOUT on a remote workstation unless
$ ! we are authorized by an entry in DECW$SERVER_ACCESS_ALLOWED.DAT or
$ ! DECW$SERVER_ACCESS_TRUSTED.DAT for that workstation.
$ !
$ ! The point of this is to make it easy for workstations to be used as
$ ! display-only X servers when necessary.
$ !
$ ! The HOST <-> SATELLITE relationships are defined by symbols of the form:
$ !
$ !     HOSTNAME_satellites = comma separated list of satellite names...
$ ! e.g.
$ !     BIGVAX_satellites = "VS2000,GPX1,GPX2,PMAX1"
$ !     PVAX1_satellites = "PVAX1,GPX3"
$ !
$ ! Note that the second host, PVAX1, is a studly workstation and logs into
$ ! himself as well as allowing "GPX3" to log into him.
$ !
$ ! Put your host/satellite symbol definitions here:
$ !
$       FRIDAY_satellites = "MONDAY,JEUDI"
$!!!!   MARDI_satellites = "JEUDI"
$ !
$       node_name = F$EDIT(F$GETSYI("SCSNODE"),"TRIM")
$       if F$TYPE('node_name'_satellites) .eqs. "" then exit
$ !
$ !   Start the appropriate session validation
$ !
$       n = 0
$ loop:
$       workstation = F$ELEMENT(n, ",", 'node_name'_satellites)
$       if workstation .eqs. "," then goto done
$       n = n + 1
$ !
$ ! determine the transport to use
$ !
$       if (workstation .eqs. "0") .or. (workstation .eqs. node_name)
$       then
$               transport = "LOCAL"
$       else
$               transport = "DECNET"
$       endif
$ !
$ ! Now create the display, this will define DECW$DISPLAY which is then
$ ! used by DECW$STARTLOGIN.
$ !
$       set display/create/perm -
                /transport = 'transport' -
                /node = 'workstation'
$       RUN sys$system:decw$startlogin
$       deass DECW$DISPLAY
$       goto loop
$ !
$ done:
$       exit
------------------------------------------------------------------------------


