pan@prowest.propress.com (Philip A. Naecker) (09/22/90)
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
_________________________________________________________________________taylort@decus.com.au (09/25/90)
In article <3451@prowest.propress.com>, pan@prowest.propress.com (Philip A. Naecker) writes: > 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, ... > (stuff deleted ...) > > 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. > etc. etc. ... I cannot guarantee that I have the solution to your problem, but I do know for a fact that this symptom occurs on an NCD17c. (There, I've mentioned a name and it didn't hurt a bit.) The problem is that the DEC session manager changes the host access list on the server (X terminal) to match the one in your saved configuration file. However, it does so only part way through the startup. As a result, further attempts to open connections fail because you probably do not have your own host listed as a valid node. To get around the problem, log in on a VAXstation and use the customise security menu to add an appropriate host/username combination, i.e. the one which you will be logging in to. Then run DECW$STARTLOGIN as usual. When you log in, the access list will already have you as a valid user for the purpose of connections. If you want multiple users to use the X terminal, you may have to specify a wildcard username. This of course leaves you wide open for other users from the same host to play tricks on you by running applications on your screen. It also has implications for security. (more stuff deleted ...) > > 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. > This is true in essence. There is a new XDMCP protocol for this type of remote login function which NCD contributed to the X Consortium. However, it is not yet widely used and certainly not available under VMS. Trevor