Subject: Re: (usr-tc) 2.0.60 HDM Code

From: Todd Keister <[email-masked]>
Date: Tue, 12 Oct 1999 20:06:05 +0000

Jeff:

     I think you have missed the point.   We don't just want to "Throw Code" at
given issues.  It may seem like extra steps, and sometimes it is laborious to
follow these procedures, but in business, law, and especially in science, if you
don't have clearly documented data trails, and reproducible results - then you
have not accomplished a darn thing.

     Once again:
               >This is done so that we can document the use of these special
codes to
               >see if the code fixes the specific issue it was designed to
address, AND also
               >to see if the new fix for one issue causes issues with any other
               >processes in the code or product.

     If we were to just release code "willy nilly" and not track what we've
done, it would be of no use to anyone, and we would be breaking many more things
than we fix.

     ER code is "special issue" code that addresses one speicific problem, and
it is not feasible to stress check this code for all possible issues in all
possible configurations.  A specific ER code may have a known issue with another
process - and that will be fixed before an ER is promoted to a Service Release.
In the meanwhile customers who desperately need one item fixed, and who can
"make due" while any other errors are resolved - can do just that - they can get
the fix that they need - and they can get it NOW (which is the whole point of
this process).

     I hope this clarifies my prior statements, and I hope this helps to clarify
what could on the surface seem to be another "Stupid Policy" that is actually
just a part of the Scientific Method.

     Todd ;-}

Jeff Mcadams <[email-masked]> on 10/12/99 12:12:31 PM

Please respond to [email-masked]

Sent by:  Jeff Mcadams <[email-masked]>

To:   [email-masked]
cc:    (Todd Keister/MW/US/3Com)
Subject:  Re: (usr-tc) 2.0.60 HDM Code

Thus spake Todd Keister
>     ER or Engineering Release Code is only available by calling to
>Tech Support, and then WE (Tech Support) must get permission to release
>the code.

Good grief, its getting worse.  What's next?  Are we going to have to
get a note from our mother's to use ER code?  Blech.

>This is done so that we can document the use of these special codes to
>see if the fix the specific issue they are supposed address, and also
>to see if the new fix for one issue causes issues with any other
>processes in the code or product.

Is it at all possible that 3Com could ever *eliminate* beaurocracy in
their processes rather than constantly adding layer upon layer of it?

>     I hope this helps.

Unfortunately, no, I doubt it really does.  :/

Does anyone in upper management at 3Com listen to what we're saying?  I
sometimes get the distinct impression that they really don't give a crap
what we feel.  I guess that is progress though...we do have *some*
people at 3Com listening to us now...even if they aren't the people
making decisions on most of these things.

Jeff "getting frustrated with 3Com idiocy again" McAdams

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 12 Oct 1999 20:07:32 +0000

Thus spake Todd Keister
>     I think you have missed the point.   We don't just want to "Throw
>Code" at given issues.  It may seem like extra steps, and sometimes it
>is laborious to follow these procedures, but in business, law, and
>especially in science, if you don't have clearly documented data
>trails, and reproducible results - then you have not accomplished a
>darn thing.

No...I didn't miss the point...I understand where you're coming
from...*however*.  This seems (from my perspective at least) to be a
reaction to as you put it "release[ing] code 'willy nilly'".  IMO, the
fix isn't to put yet another layer of beaurocracy down to track it, the
real fix is to have tech support be good enough at what they do, and
enough information available to them (I think this second part is the
killer) that they can more intelligently use ER code releases as
trouble-shooting tools.  This is, as you say, intended to provide a fix
for those that need it, and feedback on those fixes before they're put
into an SR, but putting yet another layer of beaurocracy on this just
puts that much more difficulty on us, the customers actually *using*
this equipment and code, from being able to make the most from it.

Basically, 3Com just added yet one more layer between us, the customers,
and the development process of the code, yet one more layer that
insulates our feedback from the actual people making decisions about
the development of the product(s).

Please don't get me wrong, Todd...I'm certainly not trying to take a
shot at you, or any other tech support folks.  I'm taking a shot at 3Com
overall, who's (corporate) reaction to things seems to be to add more
beaurocracy to things where there are problems in an effort to fix
them...when...at the core, at least a major component of the problems are
that there's entirely too much beaurocracy already, and customers are
already entirely too isolated from the development effort.

>     I hope this clarifies my prior statements, and I hope this helps
>to clarify what could on the surface seem to be another "Stupid Policy"
>that is actually just a part of the Scientific Method.

Oh, I'm very clear on 3Com's thinking here...some of it even makes
sense...that doesn't mean its not "another 'Stupid Policy'" though.  ;)

My other question still stands though...and this may be one that you,
Todd, may not be able to answer, and I can understand that...but does
upper management at 3Com really take us seriously?  We (the users of tc
equipment on this list) have constently, over the years, alerted 3Com to
problem after problem, most of which were ignored until they reached
epic proportions, resulted in various people threatening lawsuits,
resulted in cascades of complaints from the users both on this list and
in the totalservice fora.  These problems are, almost invariably, not
acted upon until it reached a crisis situation at 3Com and consequently
took much greater effort to fix than it would have if addressed when it
was first mentioned on the list.

I will say that 3Com has seemed to become more responsive to actual
implementation problems...ie, actually fixing bugs in code...while at
the same time making it, in many cases, actually harder for the customer
to get ahold of the code that makes the fixes.  Security issues are
still dealt with in much too slow of a manner.  I reported "Yet
Another(tm)" SNMP bug in the Total Control platform almost 3 weeks ago
now (not yet made public...will be soon), and still haven't gotten any
feedback about it.  3 weeks is *way* too long for a bug like this to
exist in a known state.  There should be an SR release for security
issues made immediately...take the last released code...start from that
base, and develop a fix for the security hole independently of your
other fixes...3Com seems to have a *very* lax attitude concerning
security fixes.

We've been complaining about support contracts for years now...any
progress there?  None that I've heard of...indeed, this too has gone in
the wrong direction.  Used to be that you had to have equal support
coverage on each card in a chassis, then you had to have it on each
chassis in a location, now you have to have it on all your chassis in
all your locations.  This should be going the other direction!  There
are easily accessible serial numbers on each card (shoot, you can even
pull them up in a nice clean spreadsheet format via TCM!), why not have
support contracts be done on a per-card basis?  Again...we here at IgLou
specifically have been asking for exactly this for over a year, and the
only response we have gotten from *anyone* (other than our sales rep,
who agrees with us) has been a call to give us the pricing as it
currently exists, they were *totally* unwilling to even *consider* that
their support contract structure was sub-optimal.

3Com has *YET* to deal with the NETServer to HiPer Arc upgrade issue.
They still are foisting essentially a Bait and Switch tactic on their
long-time customers that have NETServer cards.  3Com has known about
issues in the NETServer code base and refuses to take necessary and
available steps to fix them (either replace the cards with Arcs, or
back-port Pilgrim to the older cards, either would be an acceptable
solution, 3Com refuses to do either), and now I've heard reports that
3Com tech support folks either don't know about this situation (broken
MPIP in NETServers specifically) or don't acknowledge it as a known
problem.  Yeesh.  I answered a post in the totalservice *.totalcontrol
newsgroup just the other day telling someone that they were SOL
regarding this issue because 3Com refused to stand by their product.

These are the types of things that illustrate what I'm talking
about...3Com would rather add more beaurocracy and hierarchy to things
to try to fix it rather than step back, realize that the beaurocracy and
hierarchy is largely what's standing in their way from figuring out what
the real fixes are.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Marshall Morgan <[email-masked]>
Date: Tue, 12 Oct 1999 20:09:01 +0000

We just purchased additional DSP Upgrade kits.  How to we get more recent code
on them if they ship with older code without a service contract?

BTW: Making code fixes available without service contracts is a good way to
ensure the 3com name stays good in the eyes of the end-user customer ... or
would 3com rather have us run old code (with old code problems) on our modems
that does not work with our newer customer modems.

Marshall Morgan

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Todd Keister
> Sent: Tuesday, October 12, 1999 12:37 PM

-

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 12 Oct 1999 20:17:24 +0000

Thus spake Marshall Morgan
>on them if they ship with older code without a service contract?

In this specific situation, you can go to the totalservice website and
register your new cards for warranty support.  This last for 90 days and
gets you full access to all the code I believe.  The suggestion I heard,
because of a bug in the registration code on their web site, is that its
a good idea to set up a new login and password for the totalservice web
site each time you do this...something about overlapping warranty
periods not being recognized correctly and when the first warranty
period runs out your access to the code is revoked...even though you
have other warranties still in effect.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Brian <[email-masked]>
Date: Wed, 13 Oct 1999 03:39:03 +0000

Ok, here is an idea.  At least post on Totalservice what ER codes are
available, what they are supposed to fix.  This way we know the option
exists.

Another plus would be "fill out this form before downloading the code".
Then you all could spam our mailboxes and ask us to evaluate the
code........a little automation, good for us, good for you, you don't have
to pay those expensive tech support people just to hand us the ER code,
you get your data, and we get our code.

Brian

>  "help" to the same address.  Do not use quotes in your message.

-----------------------------------------------------
Brian Feeny (BF304)     [email-masked]   
318-222-2638 x 109	http://www.shreve.net/~signal      
Network Administrator   ShreveNet Inc. (ASN 11881) 	      

-

---

From: Brian <[email-masked]>
Date: Wed, 13 Oct 1999 03:52:16 +0000

> on them if they ship with older code without a service contract?

Login to totalservice.  Once in their, you can register equipment for
warranty.  It will want the serial numbers of the DSP cards.  Enter them,
it validates them in real time,and grants you access on the account you
are logged in with.

It works for me 50% of the time, but hopefully they have fixed any bugs in
that system.

> that does not work with our newer customer modems.

brian

-