Conference bulova::decw_jan-89_to_nov-90

	Yes!

	1) Stop the process DECW$SERVER_0
	2) invoke DECW$STARTUP.COM
	3) logout

	Windowing will then appear!

I think you skipped a couple steps in .1 like logging in via set host from
another terminal/workstation.  As soon as you stop the server, your terminal
emulator windows go away.

A much easier thing to do would be to type @SYS$MANAGER:DECW$STARTUP RESTART
in the terminal emulator.

BTW, stopping DECnet from a window should not stop DECwindows, since you
should be running the terminal emulator over a local (non-DECNET) connection.

Burns

Has anyone given thought to how one might make DECwindows more tolerant of link
level failures? It seems that the Xlib and transport layers could have logic
that would allow it to reestablish context if the link dropped. What's the 
current thinking on this? It doen't seem reasonable to force each application 
to build the redundancy when it could be embedded in the transport.

As an example, I know of one application designed to keep track of mission 
critical telemetry data. The hardware is configured such that every display
station is dual-rail ethernet, connecting to redundant hosts. The current 
design calls for updates to occur on a near-realtime basis and that link
failures (due to cable or host failure) be detected and failover to redundant
systems to occur w/o interruption of the display. The time allowed for failover
is much less than the time allowed for the application to reestablish context
from an empty screen. Is there any possibility that such robust fail-safe
mechanism be built into V2.0?

James

Agreed.  At the very least it would be nice if DECwindows used the NCP timeout
parameters in determining when to lose a link.  We have an LaVC here and a
lot of the applications run on remote machines.  If the DECnet circuit bounces,
even for a second, all of the applications lose their links and have to be
restarted.  Even if the NCP timeout is 45 seconds or something reasonable.

    
    In the case where a link truly disappears, which context do you
    maintain?  The one the server had created up to the last executed X
    function or the one the client application *thought* it had based on
    what it had called in Xlib/Toolkit routines (the difference being what
    was buffered in the server, the client, or in the network)?  And how to
    recover?  Will the client assist in checkpointing based on sequence
    numbers or is Xlib expected to recover everything?
    
    At present, X is merely a way of distributing graphical operations, not
    creating fault-tolerant distributed systems.  That is an area for RPC
    services.
    
    						monty

X has a feature that allows an applications resources and windows to stay
arround after the client dies.  You could use this mode to leave the server
context intact and have the application just switch over to using a
second connection.  Since all gc's and windows and such are still there
and in the exact state they were when the connection died the application
just needs to change the value of the display variable and his application
should continue to run un-interrupted.

The one thing that you must be carefull about is when the application realy
exits it must either clean up after itself, or shut off the resource save mode.

							Mike

re .6:  Ouch!  What Mike says is an interesting idea, but you have to be real
careful to avoid having your resources stay in the server forever (at least
until you log out).   For example, you'd better have a kernal-mode exit handler
to make SURE you don't get shut down without cleaning up resources.  Note,
however, that you can't call Xlib from kernal mode.  Sounds like trouble.
In addition, you have to keep track of whether you have restarted or not.
If you have not restarted, just switching modes from RetainPermanent to
DestroyAll will do before you exit.  However, if you have restarted the
connection, that means that you are no longer the owner of the resources.
You need to do a KillClient on them to make sure they go away.

Finally, I'm not sure how XLib and the tool kit will deal with this.  It may
be that Xlib will destroy its various structures which are associated with
the resources that are being retained and therefore, you will never be able
to reference them again.  Not to mention the toolkit.

An interesting idea, though...

Burns

    Which part of the server actually creates the X$X0 object?
    SERVER_MAIN? DIX? 
    
    David
    

    XPORT_DECNET.B32, which is part of DECW$TRANSPORT_DECNET.EXE, which is
    merged image activated to the server during startup.  It's in facility
    DIXXPORT.

    re: .2
    
    	I have tried @SYS$MANAGER:DECW$STARTUP RESTART, and it restarts
    	the server process, but I still don't get any X$X0 object. I'm
    	running SDC DECwindows 5.1 and VMS 5.1.
    
    	Any suggestions?
    
    		-- Stan

    1. Are you using a logical DECW$IGNORE_DECNET?
    
    2. Do a SHOW LOGICAL DECW$SERVER_TRANSPORTS?  You should see LOCAL
       and DECNET.  The logical is located in the DECW$LOGICAL_NAMES
       table.
    
    3. When you bootup, does a message appear that it is waiting for DECNET
       and then does it die?
    
    4. The X$X0 object is used by the server and must exist on the machine
       which is running the server. A non-workstation which runs a client
       does not need the X$X0 object to communicate with the remote display.
       Silly question but are you looking for X$X0 on a non-workstation?
       (I just had to check)
    
    5. Do an LIST under INSTALL and see if DECW$TRANSPORT_DECNET is
       installed "Open Hdr Shar Lnkbl".
    
    David
    

    
    	RE: .12
    
    	1. DECW$IGNORE_DECNET - No, I don't have that defined
    
    	2. DECW$SERVER_TRANSPORTS - It wasn't defined. I defined it, then
    		I restarted the server with @DECW$STARTUP RESTART, and
    		I still don't have any X$X0 object.
    
    	3. When I boot, I get the message that DECwindows is waiting for
    		DECnet to start. This is because I use a SUBMIT for
    		STARTNET, and an "@" for DECW$STARTUP. Even when I SUBMIT
    		them in the same submit command, I don't get a X$X0
    		object.
    
    	4. I'm looking for the X$X0 object on the workstation that I want
    		to display the window on (a VSII).
    
    	5. Under INSTALL, a LIST command shows me DECW$TRANSPORT_DECNET
    		is installed OPEN HDR SHAR LNKBL
    
    	Does it make a difference what fashion I use to start up DECnet
    		and DECwindows?
    		$SUBMIT/NOLOG SYS$MANAGER:STARTNET.COM, -
    			      SYS$MANAGER:DECW$STARTUP.COM
    			--or--
    		$SUBMIT/NOLOG SYS$MANAGER:STARTNET.COM
    		$@SYS$MANAGER:DECW$STARTUP.COM
    			--or--
    		$@SYS$MANAGER:STARTNET.COM
    		$@SYS$MANAGER:DECW$STARTUP.COM
    
    				Thanks
    					Stan

    No.  The command procedure handles it. I submit STARTNET.COM and
    execute DECW$STARTUP.COM.
    
    Was this an upgrade to V5.1 from a FT or a straight installed from
    v5.0-2?
    
    Do you have more than one version of DECW$TRANSPORT_DECNET.EXE? Is
    the creation date 17-DEC-1988 15:31:51.68?
    
    Is the checksum for the entire image %X'87EC2D80?
    
    
    David
    

    
    
    
    
    
    
    
    
    
    
    
    
     
    RE: .14 by OIWS20::BRYSON
    
    This was an upgrade from VMS V5.0-2 to 5.1, no field test software was
    involved.
    
    I only have one version of DECW$TRANSPORT_DECNET.EXE (shown below). I
    don't know how to determine the checksum of it.
    
    Following the <FF> are what DECnet objects are defined, what DECwindows
    logicals are there, and a DIR/FULL of DECW$TRANSPORT_DECNET.EXE.
    
    I've check the known object list on several other nodes in my group,
    and most have the X$X0 object there. There are others besides mine,
    however, that don't have it.
    
    So far, the help has been great. Keep it coming!
    
    		Thanks
    			Stan
    

       $ ncp sho known obj
 
Known Object Volatile Summary as of 14-MAR-1989 08:57:05
 
   Object   Number  File/PID                   User Id          Password
 
  $MOM           0
  $NICONFIG      0
  DFS$COM_ACP    0  00000050
  TASK           0                             NONE
  FAL           17  FAL.EXE
  HLD           18
  NML           19  NML.EXE
  REMACP        23  0000004D
  MIRROR        25
  EVL           26  0000004B
  MAIL          27  MAIL_SERVER.EXE
  PHONE         29  PHONE.EXE
  CTERM         42  0000004D
  VPM           51  VPM.EXE
  DTR           63
  DQS           66  DQS$SERVER.EXE
  DECW$CLIENT  222

$ sho log decw$*

(LNM$PROCESS_TABLE)

(LNM$JOB_80336ED0)

(LNM$GROUP_000001)

(LNM$SYSTEM_TABLE)

  "DECW$DECTERM_MAILBOX_KAMERA::0.0" = "_MBA570:"
  "DECW$SERVER_MBX_0000FFFE_0" = "MBA250:"

(DECW$LOGICAL_NAMES)

  "DECW$BOOK" = "SYS$COMMON:[DECW$BOOK]"
  "DECW$EXAMPLES" = "SYS$COMMON:[SYSHLP.EXAMPLES.DECW]"
  "DECW$INCLUDE" = "SYS$COMMON:[DECW$INCLUDE]"
  "DECW$KEYMAP" = "SYS$COMMON:[SYS$KEYMAP.DECW.USER]"
	= "SYS$COMMON:[SYS$KEYMAP.DECW.SYSTEM]"
  "DECW$SERVER_TRANSPORTS" [super] = "DECNET"
	= "LOCAL"
  "DECW$SERVER_TRANSPORTS" [exec] = "DECNET"
	= "LOCAL"
  "DECW$STARVUEECOM" = "SYS$MANAGER:DECW$STARTVUE.COM"
  "DECW$SYSTEM_DEFAULTS" = "SYS$COMMON:[DECW$DEFAULTS.USER]"
	= "SYS$COMMON:[DECW$DEFAULTS.SYSTEM]"
	= "SYS$LIBRARY:"
  "DECW$USER_DEFAULTS" = "SYS$LOGIN:"
  "DECW$WINMGREXE" = "SYS$SYSTEM:DECW$WINMGR.EXE"
  "DECW$XLIBERRDB" = "SYS$MESSAGE:DECW$XLIBERRDB.DAT"


Directory DUA0:[SYS0.SYSCOMMON.SYSLIB]

DECW$TRANSPORT_DECNET.EXE;3               File ID:  (1147,28,0)        
Size:           17/18         Owner:    [SYSTEM]
Created:  17-DEC-1988 15:31:51.68
Revised:  13-MAR-1989 15:42:16.41 (4)
Expires:   <None specified>
Backup:    <No backup recorded>
File organization:  Sequential
File attributes:    Allocation: 18, Extend: 0, Global buffer count: 0
                    No version limit, Contiguous best try
Record format:      Fixed length 512 byte records
Record attributes:  None
RMS attributes:     None
Journaling enabled: None
File protection:    System:RWED, Owner:RWED, Group:RWED, World:RE
Access Cntrl List:  None

Total of 1 file, 17/18 blocks.

    
                            

    RE: .13
    
    > 2.DECW$SERVER_TRANSPORT - It wasn't defined. ...
    
    That shouldn't happen.  This logical is defined in
    DECW$STARTSERVER.COM and there are no conditionals that should cause it
    to skip this definition.
    
    	$ decw$define decw$server_transports decnet,local
    
    Strange.
    
    Have you made any changes to the DECwindows environment (com files)?
    
    Look at DECW$SERVER_0_ERROR.LOG for any error information when it tries
    to load the DECnet transport.
    
    When the server come up, does everything work OK locally?
    
    May be GBLSECTIONS or GBLPAGES are being depleted. Look in INSTALL.
    This is probably not the problem.
    
    It bugs me that DECW$SERVER_TRANSPORTS was not defined. Try this.
    
    1.   Log into the system from another terminal
    
    2.   Stop the current Server process
    
    3.   DEFINE DECW$SUBPROCESS_IGNORE "TRUE"
    
    4.   Make sure that DECnet is up and running
    
    5.   SET VERIFY
    
    6.   @DECW$STARTUP
    
    This will give you output from each step of the startup process.
    
    Keep a close eye out for error messages and when DECW$SERVER_TRANSPORTS
    should be defined in DECW$STARTSERVER.COM
    
    David
    

    Look and see if you're running out of global sections... I
    just had an experience where a NEW installation of DECwindows (even
    after an autogen with WINDOW_SYSTEM=1 caused there to not be enough
    global sections (probably due to other layered products) and the
    DECwindows startup quietly died. 
    
    

    
    
    
    	RE: X$X0 object never there
    
    	The problem isn't there anymore. Out of desperation, I
    	re-installed DECwindows, and the problem disappeared. I couldn't 
    	afford to take any more time flailing at it.
    
    	Thanks to everyone for the suggestions. Without this (and other)
    	conferences, I don't know where I would turn.
    
    				-- Stan
                                     

    I have been having the same problem -- no X$X0 object defined.  I first
    noticed the problem when running 5.1-t2 and decw bl13.  I had been
    using decwindows across the network, with no problems...then all of the
    sudden the client reported "Toolkit error: Can't Open Display".  The
    security stuff under the session manager was correct.
    
    The only thing I could think of that changed was disabling TASK 0
    (corrective action for the virus).
    
    I hoped that upgrading to sdc VMS & DECwindows would fix the problems -
    but it hasn't.  
    
    Could the TASK 0 have anything to do with it?
    
    Keith

    
    If you're running sdc decwindows, the task object will not affect
    anything.
    
    					m

    So then - no other hope of finding out why my task X$X0 is dead?
    
    I see from an earlier reply, that someone just 're-installed'
    DECwindows (again) and that fixed the No X$X0 Object problem.   Our's
    is an LAVC, and reinstalling DECwindows would take down six
    workstations for the better part of a day.  I guess I can't see what
    installing the same kit would do.  We upgraded another standalone
    workstation from the *same* vms & decw kits - and they have the network
    object *and* have TASK Object disabled too!
    
    Anyone have any ideas ?
    
    Thanks,
    Keith

    The bug has been found ... read 19.26 for the answer !!!
    
    Keith