Xref: utzoo comp.windows.x:27243 comp.os.vms:30595
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!prowest!pan
From: pan@prowest.propress.com (Philip A. Naecker)
Newsgroups: comp.windows.x,comp.os.vms
Subject: How to get DECW$STARTLOGIN to work with arbitrary X server
Message-ID: <3451@prowest.propress.com>
Date: 21 Sep 90 17:51:40 GMT
Organization: Professional Press - Pasadena Office
Lines: 108

Just when you think you're starting to understand this stuff....

I'm trying to get an X-terminal up using the DECw session manager.  I believe
that for what I am doing, I can reproduce this problem on several different
manufacturer's Xterminals, so I'm not going to pick on the manufacturer of this
particular terminal.  (By the way, the manufacturer's support folks *are* able
to make things work, so there must be something different about my
environment.)

Here's the configuration:

	VMS 5.3
	2 VAXstations (3100 and VSII), clustered.
	TCP/IP from MultiNet, V2.2
	I've tried running DECW$STARTLOGIN both from the VSII and the VS3100.
	I've also tried returning the VSII to VWS (so that there would be only
	a single X display, the Xterminal) and running from that environment.

Here's what happens:

1.  I get the server to boot via TFTP just fine.

2.  I can do a SET DISPLAY/CREATE/NODE=mumble/TRANS=TCPIP[/EXEC] and then
successfully display the output from arbitrary X clients, including all of the
OOTB clients on VMS.  This proves to me that:

	1.  The transport is basically intact.
	2.  The fonts are basically correct and can be located.  (Indeed, I can
	    see TFTP requests arrive as new fonts are required.)
	3.  The Xterminal's server is not completely brain dead.
	4.  The basics of SET DISPLAY, etc. are working as I expected.

3.  After some fumbling around, I was able to get DECW$STARTLOGIN to display
the login banner on the Xterminal.  There was really only one problem:  for
reasons that are unclear, DECW$STARTLOGIN does not follow conventions for the
search order of logical names when translating DECW$DISPLAY.  Instead, it
starts with the job table and *then* searches the process table.  Thus, if you
have a job table entry for DECW$DISPLAY and then innocently do a SET DISPLAY,
the SHOW DISPLAY says one thing but DECW$STARTLOGIN uses the other.

Eventually, this problem was made evident by the fact that attempts to run
DECW$STARTLOGIN cause errors to appear in a local server's error log file
(i.e., SYS$MANAGER:DECW$SERVER_0_ERROR.LOG).

4.  At that point, since we have a login banner up, one would think we could
certainly log in and everything would be peachy, right?  Wrong.  Instead, after
we log in the following occurs:

	1.  The login banner and dialog box disappears.
	2.  The cursor changes to a watch.
	3.  The server appears to hang.
	4.  The _WSAn: process errors out and re-creates itself, apparently
	    ad nauseum.
	5.  Various errors arise, but the two of interest are a generic
	    XLIBIO error and SYSTEM-F-LINKDISCON, network partner disconnected
	    logical link.
	6.  The DECW$SM.LOG in the user's default directory is as follows:

XIO:  unable to open connection WSA3:
      after 0 requests (0 known processed) with 0 events remaining.
Session Error: -SYSTEM-F-LINKDISCON, network partner disconnected logical link

	7.  There is an ACCVIO in the file SYS$LOGIN:WSAn.LOG.  I can send it
	    to anyone who thinks they can use it.


5.  This same behavior has been described to me by several other folks, working
in different configurations and with different servers.  This is also the
apparent behavior when one tries to use this technique on a DEC VT1200.

6.  I tried bypassing DECW$STARTLOGIN and just running DECW$SESSION directly
from another terminal, pointing the display at the Xterminal.  This also fails
with the LINKDISCON error.


Questions:

1.  Am I doing anything obviously wrong here?

2.  What is the correct procedure to get an arbitrary Xserver to display the
DECW$STARTLOGIN banner and then allow logins that work like those on a local
display?

3.  I have been told by DEC's customer support that there *is* no correct
procedure - it is unsupported.  This strikes me as very odd.  I don't see why
any particular server configuration should work any differently for, say, the
DECW$CLOCK client than for the DECW$STARTLOGIN client or the DECW$SM client.


I believe (silly me) that in general this should work.  It seems to be much
like what I have done in the past with other Xterminals.  Is there something
specific that needs to be done to make the startlogin/session-manager sequence
work correctly?

Thanks in advance.

P


_________________________________________________________________________
Philip A. Naecker                Consulting Software Engineer
Internet: pan@propress.com       1010 East Union Street, Suite 101
          uunet!prowest!pan      Pasadena, CA  91106-1756
Voice:    +1 818 577 4820        FAX: +1 818 577 0073

Also:     Technology Editor, DEC Professional Magazine
          VAX Professional Magazine Review Board Member
_________________________________________________________________________