Note: My Web pages are best viewed with style sheets enabled.

Unrated

Why I Canceled Pacific Bell Internet (PBI)

Copyright © 1997, 1998, 2000, 2003 by David E. Ross

Mental inertia makes us tolerate the intolerable until pain — physical or mental — creates the impulse to act.

Summary

Late in 1996, I decided that — having been a software engineer for 34 years — I should finally buy a PC for my home. I chose Pacific Bell Internet (PBI) as my Internet service provider (ISP) for two main reasons:

• Rather than giving PBI my credit card number and having the charges automatically appear on my Visa bill each month, they would bill me on my phone bill. I had heard that too often it was difficult to stop automatic credit card charges once they started.
• PBI is part of Pacific Telesis, the dominant company in telecommunications in California, with a reputation for excellence.

PBI's service proved unacceptably deficient, both the actual Internet service and also the technical service provided by PBI's personnel. Outages in POPs, peering, news servers, mail servers, and even DNS tables were not rare. (A POP is a "point of presence", the point where a subscriber dials into the ISP's network. "Peering" is the connecting of an ISP to the rest of the world through a backbone provider. DNS tables contain the relationship between the domain names (e.g.: www.pbi.net) and the numeric address codes actually used to route messages through the Internet.) In the meantime, technical support generally reacted to any reported error as if the subscriber — the customer whose monthly fees paid the salaries of the support staff — were always at fault. Worse, the support staff often knew less about the Internet than the subscribers and even tried to talk subscribers through "corrective" actions that would be destructive.

The merger between Pacific Telesis and Southwestern Bell, leaving the latter in charge, did not result in any improvement. Finally, after almost two years with PBI, I canceled my account and joined Internet Access of Ventura County (VCnet). The most attractive characteristic of VCnet was that the three owners are:

• an experienced senior software engineer,
• an experienced UNIX system administrator, and
• a computer science student.

Some Details

Although the following starts with my beginning as a PBI subscriber and ends with the frustration that finally caused me to cancel, the other PBI failures described here are not necessarily in chronological order.

Although I was then a software engineer for over 30 years, I got my first home computer only in December of 1996. America Online was pre-installed with a 30-day free trial. However, I had already heard about AOL's problems — accepting far more customers than they could handle, similar to an airline overbooking a flight by 200% — that I had decided to subscribe to Pacific Bell Internet (PBI) before my computer was even delivered. I should have suspected something was wrong from the beginning, when the 14 days to deliver the CD passed without any little package from PBI. They had said that, with the pre-Christmas volume of mail, it might take a while. On the 16th day, however, I called PBI and discovered that the CD had not even gone into the mail yet. Neither Christmas nor the U. S. Postal Service had anything to do with the delay. On the 18th day, I received the CD. Two weeks later, I received two more CDs, both on the same day.

PBI has two POPs that are local calls from my home: one in Canoga Park and one in Simi Valley. I quickly developed the habit of calling Simi Valley when, on 25% of my calls to Canoga Park, I failed to connect. There was no busy signal; Canoga Park did indeed answer. There just was no carrier signal.

Other problems involved frequent outages of various services. Since my daughter moved to Canada (where even airmail sometimes takes a week to arrive), we depend on E-mail for frequent communication. But we can't depend on E-mail when either the POP3 server goes down (no incoming mail), the SMTP server dies (no outgoing mail), or both. PBI would post the status that the mail servers were slow; "slow" is not the case when no connection to a server succeeds even after a half-hour wait. Pacific Bell Internet does not understand the difference between slow (their term) and dead (reality).

The mail server quit such that E-mail addressed to me was returned to the sender with an error message claiming that the address did not exist. I might expect someone else's E-mail to me might have the address wrong; but this happened to E-mail I sent to myself from work, using an address-book entry that had worked before. PBI claimed that all incoming mail was being spooled and would be received soon after the server was fixed. The mail never arrived. (It is not going to arrive if it is returned to the sender.)

Technical help over the phone from PBI is one of their selling points. After all, PBI maintains an 800 area code phone system 24 hours a day, seven days a week. Many years ago, before the term "help desk" came into use, I performed that kind of service myself. In those days, only the most senior technical professionals — those who understood the software thoroughly, including its design and the reasons for its capabilities — were allowed to communicate directly with customers. We could not afford to have a customer make a mistake through using the help we gave them. Today, only the most novice junior personnel seem to answer the phone. To correct my problem, they would advise me to reboot; when I told them I just rebooted before calling, they were at a loss.

When I told them that I am having a problem with their news server, they assert the problem must be at my end and advise me to delete the one file (news.rc) that contains the history of my browsing through newsgroups. (If I did that, I would have to browse through some thousands of messages in each newsgroup just to return to my current state. Instead, I changed the name of the file and moved it; Netscape's Navigator thought it was gone. This did not cure my problem. PBI later admitted the problem was at their end. I restored the file.)

There is a Web site I visited often. Manageable Software Services, Inc. provided a freeware service (now discontinued) that located new downloadable versions of software that I have already installed. For an extended period, I could no longer connect to that site via PBI's Simi Valley POP; I could get there only via the dreaded Canoga Park POP (which had improved). PBI insisted something was wrong with the URL or Manageable Software Services' server. I insisted they had to try the URL themselves; it worked! Then, I insisted they had to try the URL through Simi Valley; they refused, claiming I was doing something wrong at my end. So I did two jump traces to the site, one each from Simi Valley (failed) and Canoga Park (succeeded). Only then did they admit they had a problem. Two months later, I still could not connect to Manageable Software Services via Simi Valley. The problem had already been traced to an anti-spam filter against the Simi Valley POP installed by a backbone service in the path between PBI and Manageable Software Services. I sent my accumulated E-mail on the subject to someone at Manageable Software Services. Shortly thereafter, I could connect via Simi Valley. I discovered this by trying it. I never received any feedback from PBI saying that the problem was fixed. For all I know, PBI might still think this is a problem.

Scott Adams (the creator of Dilbert) informed me that he was indeed referring to PBI. After all, he used to work for Pacific Bell.

The most serious outages affect newsgroups. Yes, I admit I am a newsgroupie. I regularly browse about eight newsgroups, but my subscription list has 15 entries. Sometimes, there are even more newsgroups because I add others temporarily while seeking information on a particular subject. It is not unusual for PBI's news server to be completely non-responsive ("slow" according to PBI's status). Most news server failures — possibly most problems overall — are never detected by PBI; instead, PBI learns of these problems when customers report them. I originally wrote this paragraph late on a Sunday night, when the feed into PBI's news server was just starting up. It had died about 4:30pm on the previous Friday, but that failure was not cited in PBI's status until after 7:00pm, after a customer finally convinced PBI's technical help that he was not causing the problem at his end of the connection. By 8:00am Saturday, PBI's status said everything was okay again. Yet nothing new had yet been posted on their news server since 4:30pm Friday, except for a few items posted by other PBI customers. Newsgroups that typically have 200-250 new messages posted each day had none all Saturday. The news feed from the outside was dead. After I reported this continuing failure, PBI's status reported that the feed was slow. As I said above, they do not know the difference between "slow" and "dead".

Along with E-mail, Web pages, FTP, and IRC ("chat"), newsgroups are one of the five main facets of the Internet. I missed more than 48 hours of newsgroups through PBI. When my morning newspaper is missing, the Los Angeles Times either replaces it or gives me credit on my account. There is no way to replace lost time, and PBI absolutely refused to offer any credit on my account for those lost 48 hours.

My complaints against PBI's technical staff are summarized as follows:

• No feedback to customers from PBI on reported problems.
• A general attitude from PBI technical "help desk" personnel that all problems are caused by the customers. The customers (whose fees pay the salaries of the technical staff) are always wrong.
• "Help desk" personnel who are inadequately trained. Rather than risk damage to my software, I decided to call the "help desk" only to report problems, never to ask for help.
• Insufficient monitoring of the system. PBI relies on its customers to report problems. Rarely did I call to report a system-wide problem that was already known. Since the customers are always wrong (see above), this creates excessive delay in starting corrective action.
• When PBI was finally convinced that a reported problem was real, they minimized it to a scope that only included what was reported by the customer. If a customer reports a problem receiving E-mail through a particular POP, PBI treats it as if only that POP has failed, without recognizing that perhaps the mail server has failed.

The Final Straw

Truly unacceptable service from PBI finally pushed me beyond my mental inertia. In a one month period, I experienced the following:

• PBI's DNS tables became corrupted. The DNS (Domain Name Server) tables translate domain names such as www.pacbell.net into numeric IP addresses so that data (e.g.: an E-mail message, a request for a Web page) get routed to the correct server. I could not reach several Web sites. I was able to ping IP addresses, but I could not ping the equivalent domain names. Before my first call to PBI, I knew something was wrong with the DNS tables.

  Repeated calls to PBI's telephone help service resulted in comments that everything seemed to be working okay at PBI's end. They would not listen when I tried to explain the symptoms of DNS failure. After over an hour with one technician trying to step me through "correcting" my settings (which had worked fine the day before), I finally prevailed on him dial into the system through the same POP I was using and try the same Web pages I was trying to reach. Aha! He finally admitted that there might be a problem within PBI. Moments later, he told me that their DNS tables had been truncated (the entries at the end had been lost). If that was already known, why was he tweaking my PC settings for an hour? Several hours later, the problem still existed but was not reported in either PBI's status Web page or status phone message.

• Several times, I could not reach my own Web page. I could not upload revisions. I could not even browse it. The Web server hosting customers' Web pages was down.
• After waiting in a telephone queue for over 20 minutes to report that no newsgroup messages had appeared on PBI's server for over 15 hours, I was told this was a known problem. I could have avoided the wait if it had only been reported on the status Web page or phone message. The next morning, the news server was still not receiving messages; also the status Web page and phone message both said everything is normal. Apparently, being broken is considered normal at PBI.
• I could not reach PBI's status Web page, the Web page for checking whether any incoming E-mail was waiting for me on PBI's mail server, or any other PBI Web page for existing customers.

That is when I canceled my PBI account and joined VCnet.

PBI's overall deficiency is far greater than repeated system failures. It is a combination of the failure of PBI technicians to monitor their system from the customers' environment (dialing in through their POPs), an attitude that any difficulty must originate from a customer's PC and could not possibly reside in the PBI system, and a refusal to inform customers of known problems.

10 November 1998
Updated 1 November 2003

Late in October, I called PBI to cancel my subscription, effective the end of the current billing period. I was told that the billing period had just begun, so the cancellation was effective 20 November. Hearing about problems others had canceling ISP accounts, I requested a confirmation number, which I then recorded.

On 20 November (a Friday), I could still connect to PBI's local POPs. Also, through my VCnet account, I could connect to PBI's FTP server to upload revised Web pages to PBI's Web host. (I had reduced my pages merely to point to my new Web site at VCnet, including a special pointer to this page.) Oh well, I assumed my account would terminate at midnight. But then, over the weekend and even on Monday (23 November), I was still able to connect to my PBI account.

Finally, on Tuesday — four days after the account was supposed to be canceled — I called PBI's billing department. I gave them my account ID and asked for the account's status. The woman told me that the account was current.

I asked, "Do you mean the account is still open?"

"Oh, yes," she replied.

I told her that, about three weeks earlier, I had requested the account to be closed. Then, I read her the confirmation number.

"Oh, I see now. You're right," she said, "I'll cancel it for you today."

"This is a new billing period," I told her. "I don't want any charges on this account for this period. You were supposed to cancel it effective last Friday."

"We've already posted the new month's charges," she informed me. "I'll post a credit to cover it."

The next day, I could no longer connect to a dial-up POP or PBI's FTP server. However, my remnant Web site remained active for another week.

This was just another example of PBI's incompetence. Of course, I still have the confirmation number to use when the next phone bill arrives.

3 December 1998

Actually, PBI finally got the cancellation correct. Now their Pacific Bell parent is being sued by the state of California for botching a multi-million-dollar project to install a computer network for the state.

Today, I received an unsolicited CD from PBI. It's the software to become a PBI subscriber. The envelope claims "Here's one CD you won't want to use as a coaster." Actually, they are right. Instead, I will drill a small hole near the edge and hang it from my peach tree to keep the birds from ruining the fruit. It will join about a dozen other CDs that I already collected for that purpose.

24 April 2000

Here are some interesting excerpts from PBI's Terms of Service:

In other words:

• When you subscribe to PBI, you are buying random disconnections, system-wide outages, and other failures.
• Since PBI refuses to make any assertions that the quality of their service is satisfactory, the implication is that the quality will be unsatisfactory.

Before I retired, I tested software developed by various companies for the Department of Defense. If these companies made such statements about the computer systems they provided to the military, none would still be in business.

Thanks to Adam Bernstein for bringing the Terms of Service to my attention.

21 June 2000
Updated 1 November 2003

On 29 August 2000, the Los Angeles Times had a front-page article about PBI and its digital subscriber line (DSL) service ("Missteps Rattle PacBell's New Internet Service"). Very much like AOL in 1996, PBI promoted a service far in excess of its ability to provide that service. The article described how customers waited months for DSL connections but were billed during that period when they did not have DSL service. Orders were "lost" and appointments for on-site installation broken. Over 45,000 California customers have been affected.

Not mentioned in the article was the fact that PBI priced its wholesale DSL service in a way that effectively prevented other ISPs from offering DSL to customers who have Pacific Bell telephone service.

3 September 2000

"Internet" Table of Contents

David Ross home

E-mail