Conference bulova::decw_jan-89_to_nov-90

	What does a show system of the node that is hanging look like?

								mike

    
    IT LOOKS OK WHEN THE SYSTEM COMES UP, I CAN SEE THE DECWINDOW PROCESS 
    AND EVERYTHING ELSE APPEARS TO BE OK.....

What VMS version?  What does SHOW SYSTEM say when it is hung?

If the server is in HIB and if the system is VMS V5.1 or V5.2, you are
probably seeing a problem that has been fixed starting in V5.3.  Search
around for keywords like "RETRY" and "HANG".  Does anyone have not numbers
handy?

Burns

    Do you think if I reinstalled decwindows (5.3) over again , it might 
    help?
    
    
    

One never knows, but it's not very likely.  Please give us more info so we can
help...Do a show sys and paste the info into a reply.  Also try including
sys$manager:decw$server_0_error.log  and *output.log.

Another thing to do in the meantime is to autogen one of the systems in question.


Burns

Make sure the user's BYTLM quota is up there.  About this quota is diminished
by 1200 every time the SM starts an application.  When it gets low enough, the
SM goes into a resource wait, and the session eventually hangs.

    	On VSII/GPX's that don't load the whole net database, I have
    observed that after a reboot, the Window Manager can get Very Slow

    	eg.  I press MB1 on the resize box of the Icon Box,  the pointer
    changes to the resize cursor.  I release MB1. Twenty Seconds later, the
    cursor back to the default (an arrow).


    	I have learned to restart the whole server when such an event
    happens.  Before I learned that, I would wait until I had a few actions
    queued up, (like moving the icon box, or creating a terminal) before I
    would restart the server.

    	Doing a show system, or show memory never indicated any resource
    shortage.  Remember, we have no tools or techniques for showing what
    processes are waiting on what resources.  When things are contending
    for shared/scarce resources, all we see is degraded performance, never
    who is contending for what. 

    	I have seen murmurings in this file that there may be (may have
    been?) contention between decnet starting up and decwindows starting
    up.  If you can afford to try a `folk remedy', try forcing a delay
    between decnet starting and decwindows starting.   (I recommend wearing
    a black cloak and a pointed (conical) black hat with astronomical
    pictures (mostly stars) while performing this operation.  I think it
    might help :-)

    	Note for QAR hounds: I believe this was QAR'd.  I believe the
    response was "We can't reproduce it."  [Interested parties can discuss
    this aspect further by eMail.]


    	Since getting a �VAX 3+ upgrade I haven't seen the problem.  I only
    saw it with 9 meg servers.
    
    
    				Paul Komar
    				just a DECW user.
    				(GNU aficionado)
    
    P.S. if I had a nickel for every wierd DECwindows problem (like this)
    that I've heard about, and a quarter for every DECw problem that I help
    alleviate, I'd be well on my way to having a very nice cloak and hat :-)

    
    	This morning, I found that my workstation had rebooted.  In the
    process of logging in, I mis-typed my password.  The `failure' box
    replaced the login dialog.  After that, the server was frozen.  (this
    is on my recently upgraded [to a �VAX 3+] workstation, in a previous
    note, I mistakenly said that this kind of hang didn't occur after the
    upgrade.
    
    	I rebooted (through autogen, which created a dumpfile), and went
    through the same procedure to cause the server to hang.  It did.  I
    caused the system to hang and dump.  I have entered a new QAR (03989)
    describing this problem.
    
    	I believe that the problem will occur after every reboot.  I am
    tempted to add a decw$startup restart to my systartup_v5.com, but I
    won't; I don't want to mask the problem.
    
    	How about a fix?
    
    			Paul Komar.
    			VAXcluster Design Validation group.
    			VaxCluster Technical office.
    

	What version of decwindows and VMS are you running?

	Have you checked to be sure the workstation has enough of the following
	parameters:

		GBLPAGES
		GBLSECTIONS
		GBLPAGFIL
		NPAGEDYN
		PAGEDYN

	You can try the above parameter set to the following and see if they
	work:

		GBLPAGES	40906 (min)
		GBLSECTIONS	  384 (min but I prefer 512)
		GBLPAGFIL	 2048 (????)
		NPAGEDYN	1024000 - 1536000
		PAGEDYN		 512000 - 1024000

	Good luck		

    
    	VMS V5.3 and the associated version of decwindows.
    
    I ran autogen last night.  It left me with the following values.  Also,
    I had to restart my server this morning because it was responding too
    slowly for my tastes.  It is always zippy, though, after one restart.
    
	GBLPAGES	31720
	GBLSECTIONS	400
	GBLPAGFIL	6024
	NPAGEDYN	499712
	PAGEDYN		867328
    	
    	16 meg physical memory.
    
    	I'll try your suggested values for these parameters. (I'll add them
    as MIN_xxx to my modparams.dat file)
    
    	I have a few questions, (please don't be offended)
    
    	If changing the parameters does solve the performance problems, can
    anyone explain what was going `wrong'.
    
    	If changing the parameters doesn't solve the problem, can anyone
    explain what is going on?
    
    	Does anybody really understand the decwindows server and how it
    interacts with its running environment?  (I really want an answer to
    this question, offensivse as it may be, because I have an idea in mind
    that might help the answer be "yes!" in the future...)
    
    		Paul Komar.
    		Reference Modeler.
    
    	P.S. still no mail regarding my QAR.  Other users in the cluster
    know to restart the server after a reboot.  Kind of embarassing...
    
    

    
>    	Does anybody really understand the decwindows server and how it
>    interacts with its running environment?  (I really want an answer to
>    this question, offensivse as it may be, because I have an idea in mind
>    that might help the answer be "yes!" in the future...)

Problems such as the one you describe generally have nothing to do with
the server.  They have more to do with image activation and the amount
of resources (such as global pages) available to run applications such
as LOGINOUT.  These are general VMS problems that DECwindows tends to
aggravate.  The only good workaround for now is to avoid the problems by
using AUTOGEN to increase the available resources.

    Can you describe in more detail what you mean by 'responding too
    slowly?'  I've not seen the problem you mention, and can't come up with
    a senario in which restarting the server would effect anything. 
    (Unless some of the RUN/DETACHED parameters change between the first
    and second server starts.)
    
    Have you tried MONITORing the server after a reboot?  That might reveal
    that it is paging to death, or commiting some other performance sin.
    
    James

    	
    I have discovered that no one removed the explicit invocation of
    DECW$STARTUP from the cluster startup procedure.  With VMS V5.3,
    DECW$STARTUP is automagically executed.  As a result there were two
    servers running, where only one was required.  Eventually the second
    server stopped.

    After removing the explicit invocation of decw$startup, I could no
    longer reproduce any slowness.
    
    	The full story (mis-spellings and all, sigh) is available in
    decwindows-ift qar 3989.
    
    One example of slow response is that it has taken 30 or more seconds
    for the resize cursor to change to the pointer (Default) cursor after
    releasing MB1 (after trying to resize a windows)
    
    Another example is that it can take minutes for a window to move into
    its `outline' when trying to move any window.
    
    Here is the ultimate example of `responding too slowly' (from the QAR)
    
	When two servers had been started (one implicitly, the
        other inadvertently), if after a reboot, I typed in a valid
        Username (mine), but an incorrect password, the login box
        would disappear, and then the User Authorization Failure
        dialog box would pop up.  The server then appeared to hang. 
        There was no response to mouse clicking over the
        Acknowledged box, nor was there any response to pressing the
        Return key.  The server process was in HIB and the _WSA2:
        process was in LEF.
    
    
    		Beware all ye System Managers (part-time, full-time, or
    just "Hey, get Paul to fix it!" -type system managers)  When things
    change, there is little or no protection for the error prone.
    
    		Paul Komar.
    
    		"Just model it, then you'll have a clue about what's going
    		on..."
    
    	P.S. How is decw started?  I can't find any invocation of
    	     decw$startup in sys$manager: