Possible daylight savings time change problem

  • Follow


Is it possible that the time change caused the following problem:
Sunday morning our two clustered DS10s each had the TCPIP$BIND process =
eating up 99% of cpu. When I could finally login and shutdown BIND, a =
symbiont process running DCPS took over the cpu. I finally restored =
normalcy by shutting down queue manager and restarting it. This is a new =
system, running for about two months now. We've got OpenVMS 7.3-1 and =
Compaq TCP/IP 5.3 with the two DS10s clustered using a shared quorum =
disk in a storage shelf. We do not run Multinet other than Process =
Software's SSH server for VMS. Thanks - Pat G.
0
Reply PGrealy (12) 4/7/2004 2:38:07 PM

Grealy, Patrick wrote:
> Is it possible that the time change caused the following
problem:
> Sunday morning our two clustered DS10s each had the
TCPIP$BIND
> process eating up 99% of cpu. When I could finally login and
shutdown
> BIND, a symbiont process running DCPS took over the cpu. I
finally
> restored normalcy by shutting down queue manager and
restarting it.
> This is a new system, running for about two months now.
We've got
> OpenVMS 7.3-1 and Compaq TCP/IP 5.3 with the two DS10s
clustered
> using a shared quorum disk in a storage shelf. We do not run
Multinet
> other than Process Software's SSH server for VMS. Thanks -
Pat G.

You need V7.3-1 Update V2 and TDF V3 (which was release March
22). But then again V7.3 Update V1 (which included TDF V1)
claimed to have fixed this, and TDF V2 claimed to have fixed
this. The Australians will have to tell us if TDF V3 really
fixed this next October. :)

-- 
Peter Weaver
Weaver Consulting Services Inc.
Canadian VAR for CHARON-VAX
www.weaverconsulting.ca


0
Reply WeaverConsultingServices (227) 4/7/2004 3:13:26 PM


Peter Weaver wrote:
> Grealy, Patrick wrote:
>> Is it possible that the time change caused the following problem:
>> Sunday morning our two clustered DS10s each had the TCPIP$BIND
>> process eating up 99% of cpu. When I could finally login and shutdown
>> BIND, a symbiont process running DCPS took over the cpu. I finally
>> restored normalcy by shutting down queue manager and restarting it.
>> This is a new system, running for about two months now. We've got
>> OpenVMS 7.3-1 and Compaq TCP/IP 5.3 with the two DS10s clustered
>> using a shared quorum disk in a storage shelf. We do not run Multinet
>> other than Process Software's SSH server for VMS. Thanks - Pat G.
>
> You need V7.3-1 Update V2 and TDF V3 (which was release March
> 22). But then again V7.3 Update V1 (which included TDF V1)
> claimed to have fixed this, and TDF V2 claimed to have fixed
> this. The Australians will have to tell us if TDF V3 really
> fixed this next October. :)

I just got a voice mail from the HP saying that these patches did not
fix the problem. They expect another patch next September/October.

-- 
Peter Weaver
Weaver Consulting Services Inc.
Canadian VAR for CHARON-VAX
www.weaverconsulting.ca


0
Reply WeaverConsultingServices (227) 4/7/2004 5:04:14 PM

In article <EEC575D39D864C4BBAE8CD309982B0F2081734@sphnt33.sph.uth.tmc.edu>, "Grealy, Patrick" <PGrealy@sph.uth.tmc.edu> writes:

>Is it possible that the time change caused the following problem:
>Sunday morning our two clustered DS10s each had the TCPIP$BIND process =
>eating up 99% of cpu. When I could finally login and shutdown BIND, a =
>symbiont process running DCPS took over the cpu. I finally restored =
>normalcy by shutting down queue manager and restarting it. This is a new =
>system, running for about two months now. We've got OpenVMS 7.3-1 and =
>Compaq TCP/IP 5.3 with the two DS10s clustered using a shared quorum =
>disk in a storage shelf. We do not run Multinet other than Process =
>Software's SSH server for VMS. 


7.3-2, Multinet 4.4, and we saw a very similar problem.  (In our case, 
TOMCAT took over the CPU, but when it was shut down, DCPS symbionts went
hog wild and had to be killed.)

-- Alan

-- 
===============================================================================
 Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDU
 Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056
 Paper mail to: SSRL -- SLAC BIN 99, 2575 Sand Hill Rd, Menlo Park CA   94025
===============================================================================

0
Reply winston (523) 4/8/2004 6:33:08 AM

3 Replies
43 Views

(page loaded in 0.063 seconds)


Reply: