Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!brutus.cs.uiuc.edu!psuvax1!ukma!rutgers!bellcore!texbell!vector!telecom-gateway From: julian@bongo.uucp (julian macassey) Newsgroups: comp.dcom.telecom Subject: 1ESS Call Forwarding Problem Message-ID: Date: 20 Oct 89 00:31:26 GMT Sender: news@vector.Dallas.TX.US Organization: The Hole in the Wall Hollywood CA U.S.A. Lines: 67 Approved: telecom-request@vector.dallas.tx.us X-Submissions-To: telecom@eecs.nwu.edu X-Administrivia-To: telecom-request@vector.dallas.tx.us X-TELECOM-Digest: volume 9, issue 464, message 1 of 9 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-4495