| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3562.1 | Upgrade your DECswitch900EF to fw rev v1.5.2 | NETCAD::BATTERSBY | Don't use time/words carelessly | Tue May 28 1996 10:05 | 14 |
| Andy, the current shipping rev of firmware for the DECswitch900EF
has a "major" rev of 1.5.z and a "minor" rev of x.y.2
Thus when one looks at the console menu 3 of the DECswitch one will
see fw=v1.5.2 for the rev, or in your possible case will be seeing
rev fw=1.5.0 I only emphasis this as we have seen instances where
people shortcut the rev when describing it and perhaps confuse people
as to the real rev involved. Now if you really have a DECswitch
with a rev of 1.5.0, then you should have it upgraded to the current
shipping rev. The older rev you have in your DECswitch may be having
an affect on your ability to manage it. There are known problems with
v1.5.0 rev firmware, but they don't seem to fit your problem as you
describe it.
Bob
|
| 3562.2 | HUBwatch (ClearVISN) bug - fixed in the next release. | NETCAD::GALLAGHER | | Tue May 28 1996 10:13 | 24 |
| >DECswitch 900EF (v1.5) and Gigaswitch(v ?) go GA-GA if uptime reaches
>248 days. It appears, from what the customer tells me, that once it
>reaches the 248th day, the high order bit in the time counter is set.
>When this happens, SNMP queries for time and expects to get a 4 byte integer
>but gets a 5 byte integer. Rebooting the module fixes it.
This is what's suppose to happen. When counters exceed 0x7fffffff they
are also returned in 5 bytes. This is specified in the SNMP protocol
documents.
>BTW, using Hubwatch to connect to it he gets a 'system error' or '
>general error'.
This is a bug. It will be fixed in the next release.
>Is there a known problem w/ his version of firmware (at least on the
>DECswitch).
The firmware's doing the right thing in this case.
And by the way, it's nice to hear that our products stay up for 248 days.
I wish my workstation and PC could go that long without crashing.
-Shawn
|
| 3562.3 | | NPSS::MDLYONS | Michael D. Lyons DTN 226-6943 | Tue May 28 1996 11:41 | 5 |
| ...the same goes for the GIGAswitch/FDDI firmware - there's no problem
with large uptimes for the GIGAswitch/FDDI firmware. The problem is
just with those network management systems which have bugs.
MDL
|
| 3562.4 | HUBwatch/VMS ? | PRMCS2::kupka | | Thu May 30 1996 18:28 | 12 |
|
>>BTW, using Hubwatch to connect to it he gets a 'system error' or '
>>general error'.
>This is a bug. It will be fixed in the next release.
Is the HUBwatch for VMS affected as well?
If yes, what next release will fix the problem?
Tomas
|
| 3562.5 | HUBwatch for OpenVMS status | SLINK::HOOD | Your bad news bear | Fri May 31 1996 13:50 | 19 |
| >Is the HUBwatch for VMS affected as well?
no.
>If yes, what next release will fix the problem?
OK, here it is... Current plans are to make an X4.1 version of HUBwatch for
OpenVMS available soon (I'm testing it now - Do not send mail or post notes
asking for it!!! I'll post a pointer when it's ready.). There will NOT be a
released V4.1 version, nor will there be any future released versions of
HUBwatch for OpenVMS ever.
Because this is an X version, it will not be available through the SSB.
It is also largely unsupported. But, people who absolutely positively
require it will be able to have it.
From what I've read, OpenVMS customers are being given some interesting
incentives to move to Windows/NT. For more info, contact Jack NAC::Forrest.
Tom Hood
|
| 3562.6 | | PRMCS2::kupka | | Mon Jun 03 1996 04:17 | 10 |
| >Is the HUBwatch for VMS affected as well?
no.
Just asking...
I have one customer, running DECmcc 4.0, HUBwatch/VMS 3.1. They have about 8 hubs (FW V3 - all
modules). All 8 switches (FW 1.4) became unmanageable at the same time. We test the
HUBwatch/Windows version (3.1) with the same result. After reboot (power cycle on the hub, not
only restart of the switch), everything works fine.
Tomas
|