🚀 go-pugleaf

Thanks for one of the best messages I've seen in this group!

In article <4brlr0$22f@access1.digex.net>, glenn@access1.digex.net (D.
Glenn Arthur Jr.) wrote:

> In article <4bqq0o$8d4@access4.digex.net>,
> Sean Connery <bond@access4.digex.net> wrote:
> >In article <4bpp4r$39m@zippy.cais.net>,
> >Dr. Roger M. Firestone <rfire@cais2.cais.com> wrote:
> >I do not personally feel that the problem has been with Digex advertising 
> >one speed but not providing it at all....that is not it.
> >
> >The bigger problem is how long it took to get to the point of finding the 
> >fault with the SLC96s.
> [...]
> >It took many...many moons for Digex to even consider themselves at 
> >fault IMHO.  
> 
> I thought that by now it was pretty well established that Digex was
> _not_ at fault, that they were basically screwed over (legally) by
> Bell Atlantic, the reality of the existing tarriff, and some unfortunate
> technology.
> 
> And although I have not been following this discussion very closely,
> even I have been able to pick up that it took forever and forever for
> Bell Atlantic to admit to Digex that there might possibly be a 
> problem with the SLC design -- after Digex had been hassling them for
> ideas and help and trying all sorts of hardware fixes on their end
> (at who knows what kind of expense)!
> 
> Or did I hallucinate the messages describing adding resistors to
> however many phone lines when the most likely-sounding explanation
> for the problem was too high a signal level (before Bell Atlantic
> finally revealed that the SLC was losing bandwidth)?  And I seem
> to recall other possible explanations/solutions being discussed.
> 
> 
> It's frustrating as H*** when a problem sits and sits and doesn't
> get solved, and even when you get updates saying, "We're trying
> something else now," it still feels like nothing is being done.
> Folks can be scurrying around like mad and losing sleep, but out
> here on the other end of the phone line that's invisible.  But
> come on, people:  haven't any of you gotten stuck with a _tough_
> technical problem before?  One where you don't have enough
> information to be able to say, "Oh, of course, the problem is
> _this_," but have to guess at the inner workings of some device
> or program by trying hack after hack until one of your tries 
> provides a clue?  
> 
> I've been there, and let me tell you -- it's even more frustrating
> that sitting on your butt and wondering why someone else is taking
> so long to fix it.
> 
> I can just imagine the looks on the faces of the Digex folks when
> Bell Atlantic finally -- after they'd wasted God knows how much 
> time, time that cost real money in payroll -- finally told them
> that it _wasn't_ something they could have fixed after all and 
> that it was all because of the SLC that Bell Atlantic supplied
> and that because of the way the regulations are written there was
> no recourse.  I can imagine their faces, and I'm glad I wasn't
> in the room.
> 
> I can just imagine how the various techies must have felt when 
> they found out that this brick wall they'd been banging their
> head against lo these many months didn't have a secret door
> hidden in it after all and wasn't going to crumble and someone
> else had been sitting on information that could have saved them
> a whole lot of headaches.
> 
> Again:
> >The bigger problem is how long it took to get to the point of finding the 
> >fault with the SLC96s.
> 
> And so I ask you -- without the benefit of knowing (as you do
> _now_) what to look for, how long would it have taken _you_,
> properly equipped with a reasonable set of diagnostic tools,
> to have figured out for yourself 1) that the problem was with
> the SLC96, and 2) that it was a design problem and not a configuration
> one?  Remember, you're not allowed to mess with the configuration
> yourself (have to go through Bell Atlantic for each new try),
> you _don't_ have specifications for the SLC96, and you can't 
> afford to take the whole system offline for any of your tests
> ('cause you're still running all your dial-up customers through
> it at the same time).
> 
> It's like trying to figure out how a wristwatch works without
> being allowed to open it, X-ray it, or read a book about clockwork.
> Or worse, it's like trying to figure out why this one watch is
> running slow, but only when certain people wear it.  You can 
> guess there's a spring involved somewhere because you have to
> wind it, but what _is_ that ticking noise and could it be
> relevant?  (Remember, no documentation!)
> 
> And:
> >I do not personally feel that the problem has been with Digex advertising 
> >one speed but not providing it at all....that is not it.
> 
> No, I guess not.  It's about feeling frustrated and powerless and
> wanting to take it out one somebody.  Well _grow_up_, goddammit.
> You think _you_ felt frustrated and powerless?  Walk a mile in
> Digex's moccassins, fercryinoutloud.
> 
> Bell Atlantic finally provided the clue that could have saved _all_
> of us -- techies, management, and customers -- months of headaches
> and frustration, and we're still hearing folks whine at Digex about
> it?  What do you _want_?  What can be _done_ now?  If you're going
> to kvetch like this, it sounds like you're still asking for 
> something, but I have no clue what.  Figure it out -- ask your
> pshrink to help if you have to -- and look at whether what you're 
> asking/wishing for is at all reasonable.  Then state it or drop it.  
> And if Digex says what you're asking for is something they can't or 
> won't do, lay the matter to rest.
> 
> Hint:  If what you want involves time travel, it's not reasonable.
> If what you want is an apology from Digex for sweating blood and
> spending lots of time and money on something that it turned out 
> they had no control over, try to think first about how that request
> is going to feel to them.
> 
> My advice?  Let it go.  It's gotten repetetive and boring.  Fortunately, 
> I'm just another customer like you, so I can just killfile this subject.
> 
> 
> To recap:  The speed problem turned out to not be Digex's fault or 
> something Digex has any control over.  The problem is not technically
> Bell Atlantic's fault either, because according to current regulations
> it's not officially a _problem_.  The ill will and frustration remain,
> and _that_ could have been avoided if Bell Atlantic had been more on
> the ball figuring out that the SLC96 was losing bandwidth OR had been
> more forthcoming with technical documentation on it (so that Digex 
> could have spotted the problem -- I'm sure they know how to read
> manuals).  We ain't gonna take it out of Bell's hide (much as many
> of us would like to), so why are you _still_ beating up on Digex?
> 
> -- 
>         D. Glenn Arthur Jr./The Human Vibrator, glenn@access.digex.net
>          <a href="http://www.access.digex.net/~glenn>Glenn's page</a>
>  "Being a _man_ means knowing that one has a choice not to act like a 'man'."
>   Due to health problems my newsreading time varies; I might miss followups.

-- 
Never ascribe to malice what can reasonably be ascribed to stupidity.