[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:	DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:	See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:	STAR::VATNE

Created:	Mon Oct 30 1989
Last Modified:	Mon Dec 31 1990
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3726
Total number of notes:	19516

1783.0. "remote display problems (VMS-DECnet)" by KETJE::PUTMANS (Close that Window, please) Fri Nov 24 1989 04:30

	Hi,

	we have had a VMS to VMS DECwindows display problem.

	for security reasons our system manager has pointed the
	TASK object in ncp to a dummy user with dummy passwd

	i thought DECwindows used the X$X0 task (pointed to DECW$SERVER_0)
	to do the remote display ?

	now the remote display doesn't work anymore !!

	after CLEARing the TASK object and
	@sys$manager:decw$startup restart
	the remote display works again ???

	i have the impression decwindows tries the object TASK first	
	and in the case it doesn't exist it uses X$X0.

	can someone explain this behaviour ?

	P.S. : we are running VMS 5.2 (DECwindows V1)

	thanks,
	Eric.

T.R	Title	User	Personal Name	Date	Lines
1783.1		DECWIN::FISHER	Burns Fisher 381-1466, ZKO3-4/W23	`Sun Nov 26 1989 19:25`	15
	According to Paul Beck, If DECwindows can't access an object X$X0 which is explicitly defined as an object with number 0 because the TASK object is present with a bogus password, then DECwindows has a bug. (I said something else in an earlier version of this note, and was corrected. I've deleted the whole mess since few people saw it, and there is no sense confusing the issue). Please QAR the problem, and perhaps a DW Transport devo can shed some light here. Burns
1783.2	Did someone stop the net without restarting the sever?	IO::MCCARTNEY	James T. McCartney III - DTN 381-2244 ZK02-2/N24	`Sun Nov 26 1989 22:36`	15
	I've seen this problem once and the cause what from the network being "bounced" (brought down and back up) to reload the network database from scratch. Don't ask me why they did it this way, they did... anyway, the result was that the object X$X0 was destroyed when the net was stopped, and DECwidnows apparently doesn't retry attempting to re-establish the object. Restarting the server brought the X$X0 object back. So, I believe that as long as the net is up BEFORE the server is started and stays up for the entire time the server is running, everything is fine and connections never try to ask for the TASK object. I also believe that the solution to this problem is to make DECwindows more robust about keeping it's objects and sockets registered with the correct network transports. Restarting the server simply because the network was bounced is not the correct answer. James
1783.3		DEVO::FISHER	Burns Fisher 381-1466, ZKO3-4/W23	`Mon Nov 27 1989 09:29`	3
	re .2: Fixed in VMS V5.3. At least DECnet will restart if the network bounces. Burns