From:	SMTP%"eychaner@SUNCUB.BBSO.CALTECH.EDU"  9-APR-1994 10:44:16.77
To:	EVERHART
CC:	
Subj:	DECW: Remote Session Manager II part 2

From: eychaner@SUNCUB.BBSO.CALTECH.EDU ("Channel Energy")
X-Newsgroups: comp.os.vms
Subject: DECW: Remote Session Manager II part 2
Date: 7 Apr 1994 05:16:07 GMT
Organization: Big Bear Solar Observatory, Caltech
Lines: 91
Message-Id: <2o04un$5qs@gap.cco.caltech.edu>
Reply-To: eychaner@SUNCUB.BBSO.CALTECH.EDU
Nntp-Posting-Host: suncub.bbso.caltech.edu
To: Info-VAX@CRVAX.SRI.COM
X-Gateway-Source-Info: USENET

	In part 1, I posted a DECW$LOGIN.COM procedure which starts the
DECWindows Session Manager on a remote node via RSHELL.  I said I tried
to get it working as DECW$SYLOGIN, and failed.  Well, here's how...
	The Poor Man's X Terminal procedure got around the DECWindows
security problems using the file DECW$SERVER_ACCESS_TRUSTED.DAT; it also
mentioned DECW$SERVER_ACCESS_ALLOWED.DAT.  I wondered if I could use the
same method to solve the problem.
	My first attempt, simply adding "TCPIP <remote-node> *" to the
..._ALLOWED.DAT file, failed.  While I could put up windows while the
login box was displayed, the access was removed when I logged in (when
DECW$LOGINOUT exited), and replaced with the user security (contained
in DECW$SMB_SECURITY) by DECW$WSINIT (NOT the Session Manager).  Also,
if I didn't have "LOCAL 0 *" in the ..._ALLOWED.DAT file, the login box
wouldn't display.
	I decided to get clever, and create the following files.  This
is complicated, and I'll try to keep the explanations brief, so follow
the bouncing ball.  SCRAP is the VS II/GPX workstation, and SUNCUB the
VAX 3600 remote node.  (Note: I HOPE I have this all right; these files
were edited for length.  Some of them should be in SYS$COMMON and have
node selection, but hopefully you get the idea.  Anyway, it fails, and
I'll tell how at the end; it's interesting.)
	First, we set the access for the workstation node.

File DECW$SERVER_ACCESS_ALLOWED.DAT (on SCRAP):

LOCAL 0 *
TCPIP 0 *
TCPIP SUNCUB.BBSO.CALTECH.EDU *

	Next, we start the login box on the workstation using TCP/IP,
to keep the access from disappearing when we log in (it works, I don't
know why).

File XTCP$STARTLOGIN.COM (on SCRAP):

$ set display /create/perm/node=0/trans=tcpip
$ run sys$system:startlogin
$ exit

	Next, we start the Session Manager on the remote node using
TCP/IP RSHELL, just like in the DECW$LOGIN procedure.

File XTCP$STARTSM.COM (on SunCub):

$ remnode = f$trnlnm ("MULTINET_RSHELL_ADDRESS")
$ if remnode .eqs. "" then exit
$! Executing via RSHELL; start the Session Manager on remote node
$ set display /create/perm/transport=tcpip/node='remnode'
$ @public:symboldef
$ 'f$trnlnm("DECW$SESSIONMAIN")'
$ exit

	Now, we'll add to DECW$SYLOGIN.COM on the workstation to start
the Window Manager on the workstation.  This starts the XUI Manager; it
should select between the two somehow.  The Motif Manager is the reason
for the "LOCAL 0 *" in the ..._ALLOWED.DAT file, incidentally; for some
reason it won't work without it.

Add to file DECW$SYLOGIN.COM (on SCRAP):

$ spawn/nowait/input=nl:/proc="DECW$WINMGR" run sys$system:decw$winmgr

	Last, we'll add to DECW$PRIVATE_APPS_SETUP.COM on SCRAP to set
this all up.

Add to file DECW$PRIVATE_APPS_SETUP.COM (on SCRAP):

$ decw$sessioninit == "@sys$manager:xtcp$startlogin"
$ decw$sessionmain == "rshell/input=nl: suncub @sys$manager:xtcp$startsm"
$ decw$sessionend == "run sys$system:decw$startlogin"

	This all looks great, right?  And it works...everything goes
OK UNTIL you log into the SYSTEM account using it, AFTER logging in to
another account.  The symptom is that when DECW$WSINIT runs when you
log in as SYSTEM, the screen turns black, but DOESN'T go to gray, the
pointer stays a little watch, and the DECW$SERVER_0 process falls into
an RWAST state until you kill the attempted login process.  When you
do kill the login, the server recovers, and you can restart the login
box process.
	I'm not sure if the problem is with the privilege of SYSTEM or
with Multinet 3.2D; by the time I figured out how to make the failure
occur repeatedly (I think), I had given up.  Another priveleged account
SEEMED not to cause the failure, but I'm not sure.
	Anyway, that's the story.  I still haven't managed to make it
work.  Anyone have any ideas?

-G.

Glenn Eychaner, C Programmer & VMS Manager, Big Bear Solar Obs., Caltech
eychaner@suncub.bbso.caltech.edu  (909)866-5791  40386 North Shore Lane
SUNCUB::EYCHANER, 5554::EYCHANER  (818)395-4014  Big Bear City, CA 92314

