Conference noted::pwv50ift

4200.0. "Many problem/4-MAR-1997:14:28" by TKTVFS::HAMADA_T (Tsuyoshi Hamada, TECM/CSC/MCS in Japan) Tue Mar 11 1997 07:27

About 4-MAR-1997:14:28, a lot of customers has experiencecd system hang or 
CPUSPINWAIT or removing from shadow set in Japan. It seems to me that this 
problem is PATHWORKS problem, there is a TIMA information about this problem. 

Q1. Does anyone know the algorizm how problem project time that is written in 
    following TIMA information is calculated ?
    When we have tested the case of "4-MAR-1997 14:26:17.51", the time that 
    NONPAGE start to increase is about "4-MAR-1997 14:27:47", 90s has passed
    since project problem time(4-MAR-1997 14:26:17.51).  

	   Projected Problem Times     	Binary time
	   -----------------------     	--------------------------
	   31-OCT-1996 11:52:21.01     	009AAAAA 6FC9CF20
	   25-NOV-1996 07:35:08.31     	009ABE2B A5826B60
	   20-DEC-1996 03:17:55.61	009AD1AC DB3B07A0	     
	   13-JAN-1997 23:00:42.91	009AE52E 10F3A3E0
	    7-FEB-1997 18:43:30.21	009AF8AF 46AC4020
	    4-MAR-1997 14:26:17.51   	009B0C30 7C64DC60
	   29-MAR-1997 10:09:04.81	009B1FB1 B21D78A0
	   23-APR-1997 05:51:52.11	009B3332 E7D614E0
	   18-MAY-1997 01:34:39.41	009B46B4 1D8EB120
	   11-JUN-1997 21:17:26.71	009B5A35 53474D60
	    6-JUL-1997 17:00:14.01	009B6DB6 88FFE9A0
	   31-JUL-1997 12:43:01.31	009BA83A 2A29BE60	
	   25-AUG-1997 08:25:48.61	009BBBBB 5FE25AA0	
	   19-SEP-1997 04:08:35.91	009BCF3C 959AF6E0
	    2-DEC-1997 15:16:57.81	009BE2BD CB539320
	         .          .
	         .          .

Q2. This problem can be reproduced in inhouse system.
    But, problem is reproduced at the passing about 90s. For examples,
    in the case of 4-MAR-1997 14:26:17.51, problem is reproduced at 
    4-MAR-1997 14:27:57.
    Is the projected problem time right ?

Q3. Does this problem occur in using NETBEUI transport only ?
    

This is the part of TIMA information.
-----------------------------------------------------------------------------
PRODUCT:    OpenVMS VAX, Versions 5.5-2 and above
            OpenVMS Alpha, Versions 1.5 and above
            PATHWORKS for VMS, Versions 5.0 through 5.0D

SOURCE:     Digital Equipment Corporation


SYMPTOM:

OpenVMS VAX and Alpha systems, running PATHWORKS, version 5.0 through
5.0D, can periodically consume nonpaged pool (NPAGEDYN) in large
quantities.  This pool consumption occurs at periodic intervals of
approximately 24 days, 20 hours, and may cause a variety of symptoms:

  - Significant NPAGEDYN expansion, i.e., 20% or more, consuming
    memory resources, inducing extra swapping and paging, and
    degrading system performance.

  - The following system crashes may occur:

      o CPUSPINWAIT bugchecks with the POOL spinlock owned while
        reclaiming the lookaside list.

      o CLUEXIT bugchecks, often with "maintenance timer expiration"
        errors in ERRLOG.SYS.

      o SSRVEXCEPT bugchecks, due to RFDRIVER exhausting its NPAGEDYN
        resources.

      o INVEXCEPTN bugchecks may also be possible, for products unable
        to handle the shortage of NPAGEDYN.

  - System hangs with subsequent analysis revealing:

      o Many processes in FPG, RWMPB, PFW, or COLPG state, with
        pagefile resources consumed and NPAGEDYN expanded.

      o Errorlog entries indicating the inability for certain devices
        to initialize, due to insufficient NPAGEDYN.

      o SYS-W-POOLEXPF errors on the console.

  - On OpenVMS VAX systems you may encounter an oversized lookaside
    list for 64 byte packets due to previous expansion caused by
    PATHWORKS, and tracked in SYS$SYSTEM:LISTPREPOP.DAT.

      Note:
        Subsequent reboots use LISTPREPOP.DAT to pre-populate the
        lookaside lists.  This effectively wastes pool space, which
        can cause NPAGEDYN expansion, and performance degradation,
        long after the problem has occurred.  If this occurs, it is
        recommended that LISTPREPOP.DAT;* be deleted just prior to
        a reboot.

  - On OpenVMS VAX systems, AUTOGEN runs can oversize NPAGEDYN and
    NPAGEVIR based on the expansion caused by PATHWORKS.  This wastes
    pool space and possibly cause performance degradation long after
    the problem has occurred.

      Note:
        After this occurs on an OpenVMS VAX system, it's recommended
        that you delete LISTPREPOP.DAT;* just prior to a reboot,
        allow the system to run for 2-3 hours, and then re-run
        AUTOGEN.

    This problem has been addressed a number of times both in this
    conference and in others.  There is a patch available for V50E systems
    which is included in V50E-ECO1.  ECO1 is about to be released (in final
    qualification now).  If you need the patch prior to the release, submit
    an IPMT case and the patch will be made available.
    
    Dan