Conference bulova::decw_jan-89_to_nov-90

    
    	Hello again,
    
    	I just finished upgrading to VMS 5.3/DECw 2.0 and I am still
    	getting the same problem.
    
    	Rich

    WAG:
    
    Get rid of 99% of your MODPARAMS.DAT and AUTOGEN.

    Certainly try Andy's idea, but you are getting a reserved operand fault
    in the server (error 454 hex) on a PolyFillRectangle (opcode 70).  That
    does not sound like sysgen parameters, though heaven knows you can get
    weird things from that.  Please include the server log file
    and submit a qar.  Please be sure that it is a log file from V5.3
    and not a previous field test version so that we can trace the
    addresses accurately.
    
    Burns
    

    Actually, are you sure the server itself is dying?  The log implies
    that it is kicking off a client which it thinks is causing it to do bad
    things, but it does not seem to have shot itself.
    
    Burns
    

    
    After the windowing system goes down, a show system does not find
    any DECwindows processes (like DECW$SERVER_0, etc.) running.
    
    My suspicion is either hardware error (probably unlikely, though
    my system has taken some good size hits lately) or as implied, a
    system parameter problem.
    
    I didn't have this problem with 5.1-1.  I started to have this problem
    immediately after upgrading to vms 5.2.  After that upgrade, I
    installed the following products: RDB 3.0b, CDD+ 4.1, COBOL 4.2,
    DTR 4.2, Basic 3.3, DECforms 1.1, LSE 2.3, DDAL 2.0, VPA 2.0, FTSV
    2.2, Nmail 9.1, and Securepack 3.2.  I adjusted system and account
    parameters to the minimum requirements specified in the installation
    guides for each product.  I haven't built any other accounts yet
    (still waiting for a stable system) and haven't installed DECwrite
    or DECdecision yet (again, waiting for a stable system).
    
    I would have thought that if there was a corrupted file, the upgrade
    to VMS 5.3/DECw 2.0 would have replaced that file.  VPA doesn't
    seem to be picking up any problems (except the usual 'increase working
    set size for DECnet' when NETACP starts running at reboot.
    
    The error message has changed from 5.2 to 5.3 in DECw$sm.log.  It
    now reads:
    
    	XIO:  fatal IO error 65535 on X server "NOTA20::0.0"
    	      after 322 requests (322 known processed) with 0 events
    							    remaining.
       Session Error: -NONAME-E-NOMSG, Message number 02DBA002
    
    Note that the error message under 5.2 was 02DB821C
    
    It also seems that after the third time of restarting DECwindows
    manually, when it goes down again, it takes the system with it.
    The Dump Analyzer point to a 'DECWINDOWS, DECwindows fatal error'
    as causing the crash, specifically the process DECW$SERVER_0.
    
    If it is parameters, any ideas on how which ones, or should I
    completely redo modparams, again, by going through the installation
    guides for all of the products, re-AUTOGEN the system, and see if
    that takes care of.
    
    Any further thought or suggestions would be appreciated.  BTW, I
    have a call into the CSC to see if they have any solutions as well.
    
    Thanks....
    
    							Rich

    If I had to take a wild guess after seeing all those layered products
    installed, I would say raise your global pages and global sections
    higher.  There isn't any way that autogen can anticipate these
    requirements in advance.  I have 45,000 global pages and 350 global
    sections on my system, partly to make sure I have enough contiguous
    pieces.

                Dave

    I currently have allocated 475 GBLSECTIONS and 30,000 GBLPAGES (this
    was based on attempting to install an ACMS application on my W/S
    for testing and debugging).  That application is no longer present.
    
    Doing an INSTALL LIST/GLOBAL/SUMMARY shows me that 237 of the
    GBLSECTIONS are being used when DECW is not running and 238 when
    it is running.  I have 13,348 free GBLPAGES without DECw and 13,174
    with DECw.
    
    Should I increase these parameters further (or perhaps cut down
    on them??)??
    
    Rich

    Well, further information arises...
    
    I shut me network down and lo and behold, no decwindows crash. 
    I am still trying to trace down a few items in NCP to make sure
    it isn't software, but, after talking to Customer Support,it appears
    that the network might be causing my problems.  According to the
    specialist I talked to, this has been discussed in this Notesfile;
    specifically bad netwrok hardware and connections.  Can you point
    me to these notes?  Does this seem reasonable?
    
    BTW, if this is the cause, why is DECwindows so sensitive to junk
    on the network?
    
    Rich

It shouldn;t be.  Please QAR the whole mess, and include an updated log file
from the server (it should have timestamps if it is from the new server).

Burns