Conference noted::pwv50ift

	Thank you very much for your quick answer.
	We have two question about this case.

	1. How is the following project time calculated ?
	   How is the VMS system time converted to PATHWORKS timer ?

	   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		:
	   29-MAR-1997 10:09:04.81		:
	   23-APR-1997 05:51:52.11		:
	   18-MAY-1997 01:34:39.41		:
	   11-JUN-1997 21:17:26.71
	    6-JUL-1997 17:00:14.01
	   31-JUL-1997 12:43:01.31
	   25-AUG-1997 08:25:48.61
	   19-SEP-1997 04:08:35.91
	   13-OCT-1997 23:51:23.21
	    7-NOV-1997 19:34:10.51
	    2-DEC-1997 15:16:57.81

	2. By jumping the project time by $ SET TIME DCL command just before 
	   its time, can we avoid this problem ?

	Best regards and thanks,
	Tsuyoshi.

	

    1 sorry no time to look it up for you.
    
    2 No, problem remains, even gets worse.
      You need the patch
    
    Adrie

	Thank you very much for your quick reply.
	We escalated to IPMT to get the patch for V5.0D-ECO2 this evening.

	Best regards and thanks,
	Tsuyoshi.

Is there another problem with PATHWORKS consuming OpenVMS Nonpaged Pool
(NPAGEDYN), and putting it onto the 64 byte lookaside list - other than 
the one mentioned in note 4121.0 ?  

Could older versions of PATHWORKS (before 5.0D) have a different time based 
(and cycle) the problem could occur at ?

  I ask because around 27-JAN-1997 17:52 it appears that two sites may have
  had the problem occur (one in England and one in Kansas USA).  The last
  occurance of the problem was around 13-JAN-1997 23:00 (and we did get
  a few calls on this problem), but the next "expected" occurance of the 
  problem was 7-FEB-1997 18:43 - not 27-JAN-1997.


o In the UK the customer is running PATHWORKS 5.0C OpenVMS Alpha 6.2 and
  crashed with a CLUEXIT at 27-JAN-1997 17:52 after the 64 byte lookaside 
  list consumed nonpaged pool and was filled with:

  6B6C626D 00000040 6B725750 8558B400  [email protected]     8558B880
  6B6C6264 00000040 6B725750 8558CD00  .�[email protected]     8558B400
  66667562 00000040 6B725750 8558B900  .�[email protected]     8558CD00
  6B6C626D 00000040 6B725750 8558CC40  @�[email protected]     8558B900
  6B6C6264 00000040 6B725750 8558B840  @[email protected]     8558CC40
  66667562 00000040 6B725750 8558E440  @�[email protected]     8558B840
  6B6C626D 00000040 6B725750 8558CB40  @�[email protected]     8558E440
  6B6C6264 00000040 6B725750 8558D400  .�[email protected]     8558CB40
  6B6C626D 00000040 6B725750 8558E500  .�[email protected]     8558D400
  6B6C6264 00000040 6B725750 8558CC00  .�[email protected]     8558E500
  66667562 00000040 6B725750 8558E680  .�[email protected]     8558CC00

  This seems to occuring at intervals about every 40 days 17 hours 20 mins
  at this site.  
	07-nov-1996 07:07 log 77286.00-69G-1UVO
	18-dec-1996 00:24  crash, not reported
	27-jan-1997 17:54  CLUEXIT crash
	09-mar-1997 11:24  predicted next event !!

  The contact for this site is John Travell, COMICS::TRAVELL.


o In USA the customer was running PATHWORKS 5.0A OpenVMS Alpha 6.1 and
  the system hung since about 27-JAN-1997 17:34-17:44 (last errorlog
  entry was at 17:34) after the 64 byte lookaside list consumed nonpaged 
  pool and was filled with

  80D393C0 00000040 4B525750 8198B180  .�..PWRK@...�.�.     8198A400
  80DF1200 00000040 4B525750 8198A9C0  ��..PWRK@.....�.     8198B180
  00000000 00000040 4B525750 8198B340  @�..PWRK@.......     8198A9C0
  80DF1280 00000040 4B525750 8198AA00  .�..PWRK@.....�.     8198B340
  80DF4100 00000040 4B525750 8198AA40  @�[email protected]�.     8198A540
  00000000 00000040 4B525750 8198B140  @�..PWRK@.......     8198AA40

  This same site had a hang back on 18-DEC-1996 as well, about 40 days
  ago.

  The contact for this site is Jeff Kaminski, CSC32::J_KAMINSKI, call
  number C970128-1528.  

  The customer in the USA is running Windows NT systems and is serving
  disks to them through PATHWORKS.  We will have to see if Service Pak
  5 (or higher) has been applied to all his systems or not.

    The customer in the USA (Kansas) had a Windows NT 3.51 Server up to
    Service Pak #2.  We are now wondering if this could be a manifestation
    of the Windows NT network storm problem that triggered PATHWORKS to
    consume all of the nonpaged pool with 64 byte patches.  We have
    recommended he upgrade this server to Service Pak #5 or higher.

I have a tape, I have not yet restored the dumps. 
If the dumpfiles are wanted I will restore and zip them. 
Bear in mind that this site is running V5.0C, and elsewhere on their 
network is a cluster running V5.0A...

The customer is ready to upgrade to 5.0E, but is still concerned that 
there may be another mechanism causing these 40-day cycle events, and
wants further investigation. 

Q: Will PWRK engineering accept an IPMT for V5.0C ??  :-)

	JT:

You will be told to go to V50E

We will not patch V50C

    Neither are we going to look to dumps of there is
    no IPMT request.
    
    All these problems are solved though in v50e eco 1.
    
    Adrie

The customer in the UK has already been supplied with V5.0E, and advised that 
older versions will not be fixed.
My interest in this is NOT to solicit a fix for V5.0C, it is solely to raise 
the issue that there appears to be a pattern of event SIMILAR to the known
pool consumer, BUT recurring at a DIFFERENT frequency, and at different TIMES.

Specifically, two sites, one in the UK (EDS), and one on Kansas USA (customer 
not known to me) are suffering problem at approximately 40 day 17 hour 
intervals. The most recent event occurred shortly before 27-JAN-1997 17:52, 
and the next event is expected at about 11:24 on the 09-mar-1997...
Previous history on both sites have problems at about the same times, 
07-nov-1996 07:07 and 18-dec-1996 00:24. Older dates were apparently not 
recorded exactly, just that problems were seen at intervals consistent with 
this pattern.

Question. 
Since the symptoms appear to exactly mirror the known pool consumer, can 
Pathworks engineering explain this variant problem cycle, and confirm that 
the specific issue causing this `40 day' cycle is fixed in V5.0E or ECO#1.

If the answer is `unable to confirm fixed', I must raise an IPMT to request 
that the problem causing this `40 day' cycle is fixed in an ECO to V5.0E.

Note again, I do NOT want fixes for OLDER versions....

	JT:

    fixed
    
    see prev notes in this notesfile
    or note in utrtsc::pw_tools
    
    The last notesfile describes the frequency.
    
    Adrie
    

    utrtsc::pw_tools
    note 25.6
    
    Adrie

    RE: above
    
    The final fix for the pool consumer will be in V50E-ECO1.  The last
    portion of the fix just missed the window for inclusion in V50E.  A
    patch to V50E is available.
    
    Dan

Folks, I KNOW the 49.6 day cycle problem is fixed in 5.0E + ECO#1, this is a 
DIFFERENT issue. 
The symptoms are similar, but the TIMING is DIFFERENT.

Can you unambiguously specify that in addition to the 49.6 day cycle fixes, 
5.0E + ECO#1 will also fix this ** FORTY DAY ** cycle problem.

Have you even SEEN this "forty day" cycle issue ??
 
Can you confirm that older versions of pathworks (back to V5.0A) have the same
or different problem frequencies. ??

The only common feature that I know of is that both the UK and USA customers 
have systems running V5.0A somewhere on their networks. For the UK customer, 
the V5.0A systems are in Germany, but still on the same network.

Sorry to be a pain, I am getting grief from my customer.!

	John Travell.

    We don't support these older versions anymore. 1 of the reasons
    is that there were so many patches in streams that were related
    to pool corruption and buffer list exhuastions. This is probably
    what you are seeing.
    
    Adrie

.14> Sorry to be a pain, I am getting grief from my customer.

If your getting grief, why haven't you escalated it via IPMT?

But be forewarned, as Adrie implied, we don't support the old versions, so
the first thing you will be told to do is upgrade to V50E.

Brad

> If your getting grief, why haven't you escalated it via IPMT?

because the problem is related to a now unsupported version. I try to avoid 
the work needed to raise an IPMT when I know full well that the response will 
be to have the customer upgrade to the current version.

> But be forewarned, as Adrie implied, we don't support the old versions, so
> the first thing you will be told to do is upgrade to V50E.

I agree totally, I have told the customer to upgrade, I told them that the
version they run is unsupported, they have been supplied with V5.0E. 

Despite all this they still sent me a tape. Their view is that V5.0E fixes 
a problem known to occur every forty-NINE.something days, and their problem
cycle is different, at every FORTY.something days, some NINE days shorter
than the known problem cycle. 
While all the evidence seems to me to suggest that it is a manifestation of 
the same problem, this customer wants a statement from a `higher authority'
that the real cause of the *forty* day cycle is known, and fixed...
His claim is that the mechanism generating the 40 day and 49 day cycles cannot
be the same. I cannot refute that.

	JT:

    There is no such problem as a forty day cycle problem.
    There might be 1 in Windows NT. I can recall something
    like broadcast storms etc... caused by a WNT bug that
    could cause other systems to crash.
    
    Again, there is NO 40 day cycle problem inside streams.
    
    Adrie

Ok, so there is the higher authority (Adrie) telling you the customers
problem does not exist.  I'll bet Adrie didn't even realize he was a 
higher authority ;^).

But hold on a minute, the customer says it does exist.  Well, engineering
doesn't know of one, so we can't tell you it is or isn't fixed.  We haven't
ever seen it.

So, what your customer needs to do is upgrade to V5.0E, reproduce his problem,
and then escalate so we can identify this 40 day problem and fix it.

From engineering's point of view, V5.0E does NOT fix a forty day problem.  If
your customer wants us to fix it, we will be more than happy to.  Upgrade to
V5.0E, reproduce it, escalate it.  Simple.

And if we are fortunate, the problem will go away when he installs V50E.

Brad

    I didn't say there was no 40 day cylcle problem...
    
    I said there is NO 40 day cycle problem inside streams...
    
    ;-) Adrie

I will only escalate this *IF* it can be reproduced with V5.0E and ECO#1...
Don't hold your breath...

	JT:

    RE: .-1
    
    ECO1 is not yet released.  If the customer requires the "timer" fix
    prior to the release, submit an IPMT case and the patch to V50E will be
    provided.
    
    Dan