julian@bongo.uucp (julian macassey) (10/20/89)
I received the following from Jeff Glassman, WA6ENI via amateur
radio; via tcp/ip for the curious. Jeff is the night manager of a GTE
CO. He is responding to a tale I sent him (yes, via ham radio) that
ran here a couple of weeks ago about DMS100 CPC problems:
From wa6eni@wa6eni.ampr.org Thu Oct 19 15:38:09 1989
Received: from wa6eni.ampr.org by n6are.ampr.org with SMTP
id AA3045 ; Thu, 19 Oct 89 15:38:00 PDT
Date: Thu, 19 Oct 89 15:45:09 GMT
Message-Id: <1560@wa6eni.ampr.org>
From: wa6eni@wa6eni.ampr.org (Jeff Glassman)
To: n6are@n6are.ampr.org
I work in a WECO 1AESS owned by GTE. Actually it is a very nice
switch and very well behaved. We are going to be upgrading to G
feature package for our 911 folks.
That story about the DMS 100 really brought a smile to my face. As
an equipment maintainer who is usually the only person who is in the
CO I can appreciate the goings on.
I have a similar story to relate. There is a customer out of my CO
who happens to want to call forward his phones at the exact time that
we are doing a translation data assembler back up tape. There is a
period of time when a customer cannot execute any recent changes to
their line (call forwarding variable, speed call variable etc.) while
the verificaton between the primary and secondary translators os
occurring.
This only takes about 5 min. but it just happens to occur at the
time that he leaves his premises. He thought his call forwarding was
broken and kept reporting to 611 who would always find it to be a
Test-OK when they checked it. This went on for months with no
resolution.
Supervisors had been out to insure him that there was no problem
and kept showing him the proper ws to use call forwarding. (HE ALREADY
KNEW HOW TO USE THE @#$% CALL-FOWARDING!!) In desperation he watched
one of the outside plant persons dial up the CO and noted the number.
He called into the CO, got the day shift person who informed him what
the problem was and that there was no way that anything could be done
about it. ("I just do my job - I don't set policies...")
When he called me at the CO (at 3:30am) and gave me his story with
all the names of who he had contacted and what he had tried, I was
amazed! NO ONE had ever explained to him that the situation occured
for only five minutes at a time and only once or twice a week. He had
never even thought of trying it after a few minutes because he thought
that it was repeatedly breaking and being repaired in the morning.
Needless to say I was able to straighten him out on what the situation
actually was in just a few minutes.
The whole incident just showed me how important communications is
within a communications company, and how little information actually
makes it through from one section to another of the company. If that
customer had not taken matters into his own hands and gotten hold of
me there is no telling what it would have taken to get his "problem"
solved. I hope that incidents such as this are rare and isolated but I
fear that they are getting more common all the time.
===============================
Yours,
Julian Macassey, n6are julian@bongo ucla-an!denwa!bongo!julian
n6are@k6iyk (Packet Radio) n6are.ampr.org [44.16.0.81] voice (213) 653-4495woolsey@ames.arc.nasa.gov (Jeff Woolsey) (10/25/89)
I'm having an odd call forwarding problem on a DMS-100 (209-832). If I try to forward to a number out of the LATA, then, having no-pick, I must prefix with 10XXX. If I don't wait for the number to answer, and attempt to set it up again, it "takes", but forwards through it get either reorder or the last successful forward. All other forwarding permutations work, including allowing the 10XXX-dialed number to answer. Bizarre! Pac*Bell repair took two weeks to isolate it this far, and I haven't followed it up for a while.