Copyright 1996-1998 by James Mohr. All rights reserved. Used by permission of the author.
Be sure to visit Jim's great Linux Tutorial web site at https://www.linux-tutorial.info/
If you're like me, you think the manual is for cowards. Any good computer hacker should not be afraid to open up the box and start feeding in disks without any regard for the consequences. You tear open the box, yank out the floppies, pop the first one in the drive and startup the Software Manger or custom and happily go through the thankless task of installing the software. After everything has been installed and your desktop icons have been created, you double-click on the icon and start you new multi-media Web Viewer. But wait! It doesn't work right. No matter how much you point and click and click again, nothing happens. In frustration, you get on the phone and frantically dial the 800 number in back of the manual (the first time you opened it).
When you finally get through to support after waiting for two hours (it was actually only 5 minutes), you lash out at the poor tech support representative who was unlucky enough to get your call. You spend more time ranting about poorly written software than you spent on hold. When you finally get done insulting this person's ancestry, he calmly points out that on page 2 in the manual where it describes the installation procedure it says that in order to get the Web to work correctly, you have to have a network installed. Since you decided not to install TCP/IP when you first loaded the system, there is no way for the Web viewer to work. You're embarrassed and the whole situation is not a happy thing.
The obvious solution is to read the manual before, during and after the installation. That tends to limit the embarrassing calls to tech support, but the world is not perfect and eventually something will go wrong. Programs are (still) written by human beings who can make mistakes, which we users call bugs. Perhaps the QA technician who was checking your SCSI host adapter sneezed at the very moment the monitor program reported an incorrect voltage. Maybe they never tested that one, rare set of circumstances that causes the program to freeze the way it did on your machine. The end result is that you've read the manual, checked and rechecked the hardware and it still does not behave the way it is supposed to. You can't solve the problem yourself, so you need help.
The most commonly known source of help is the company's tech support department. Tech support is like any system. You put garbage in and you're likely to get garbage out. Calling in, demanding immediately results or blaming the support rep for the problem will get probably get you one of two things. Either you are told that it's either a hardware problem if you've called a software company, a software problem if you've called a hardware company or they say there is "something" else on the machine conflicting with their product, but it's your job to figure it out. You may get an answer that, yes, that board is bad and you can return it to the place of purchase to get a refund or exchange. In other words, they blew you off.
If the board was bad, getting a replacement solves the problem. If however, there is a conflict, you will probably spend even more time trying to track it down. If the problem is caused by some program problem (conflicts or whatever), reinstalling may not fix the problem.
Rather than spending hours trying to track down the conflict or swapping out boards, you decide to call tech support. The question is "which one?" If there is only one program or one board, it's pretty obvious which one to call. If the problem starts immediately after you add a board or software package, the odds are that this has something to do with it. If, however, the problem starts after you've been running for a while, tracking down the offender is not that easy. That's why you're going to call tech support, right. So grab that phone and start dialing.
Stop! Put that phone down! You're not ready to call, yet. There's something you need to do first. In fact, there are several things you need to do before you call.
Calling Tech Support is not as easy as picking up the phone and dialing. Many people who are having trouble with their system tend to think that it is. In many cases, this is true. The problem is basic enough that the tech support rep can answer it within a few minutes. However, if it's not, lack of preparation can turn a two minute call into a two hour call.
Preparation for calling tech support begins long before that first phone call. In fact, preparation actually begins before you install anything on your system. I mean anything. Before you install your first program, before you make the change to .profile to change your prompt, even before you install the operating system.
In previous chapters, we talked about purchasing a notebook and detailing your system configuration. This kind of information is especially important when you need to call a hardware vendor to help track down a conflict or the software should work. You may never use most of this information. However when you do need it, you save yourself a great deal of time by having it in front of you.
By knowing what product and what release you have before you call, you save yourself time when you do call. First you don't have to hunt through notes or manuals while the clock is ticking on your phone bill. Even if you can't find the release, don't guess or say "the latest". Although you can get the release number from the installation media, this may not be exactly what was used to install. The best source is to run uname -X. This tells you exactly what release the system is currently running.
If you guess, then the support technical might have to guess too. This is important because fixes are almost always release specific. If you say "the latest" and it isn't and the "bug" you have was corrected in the latest release, the analyst is not going to give you the fix, because he thinks you already have it. This wastes his time, wastes your time and in the end you don't get the correct solution.
Should it be necessary to contact SCO Support, at the very minimum you should have the following information:
Operating System(s) and versions.
Machine type: XT, AT, PS/2, etc.
Make and model of all hardware (rarely is just the brand sufficient)
Controller make, model and type
Symptoms of problem: Noises, messages, previous problems.
An exact description of the error message you receive and the context in which you receive it.
Drive organization: Partition sizes, special drivers.
Special devices/drivers such as disk array hardware and software.
What was the machine doing when the problem occurred?
What was the sequence of events that preceded the problem?
Has this problem occurred more than once? How often?
Did you install any third party device drivers or additional hardware recently?
What was the last thing that you changed?
When did you change it?
Is this a production machine and are you down now?
The last question is essential to getting you the service you need. If you are not clear to support about the urgency of the situation, you may end up waiting for the available support analyst or you might get the "try this and call back later answer." By explaining the urgency to everyone you contact, you are more likely to get your answer quicker.
On the other hand, tech support (at least at SCO) is based on an honor system. SCO Support will believe you when you call in and say your system is down. Many of the customer service people are not in a position to judge the severity of the problem. However, the support analyst is. Saying that your company is down because you can't figure out the syntax for a shell script is unfair to other people who have problems that are really more sever than yours. Simply turn the situation around where you are the one waiting for support on a system crash and someone else is tying up the lines because he can't install a printer.
Once you have all the details about the problem you are now ready to call, right? Well, not yet. Before you actually start dialing, you need to make every effort to track down the problem yourself. The first reason is pretty obvious. If you find it yourself, then there is no need to call tech support.
If you can't find it and have tried everything you can think of, you can save a great deal of time by telling the support rep what all you tried. The support rep does not have to go through all the basic stuff again and can concentrate on more detailed issues.
Many vendors, including SCO, have bulletin boards containing answers to commonly asked questions. There is even a WWW page for the SCO bulletin board to make access even easier. Unless your system won't boot at all, this is usually a good place to look before you call support. Again it's an issue of time. It is generally much easier to get into a bulletin board than to a support engineer. You may have to spend a little time becoming familiar with the particular interface that this company uses. However, once you have learned your way around, you can not only find answers to your questions, but you often find treasures such as additional programs that are not part of the base distribution. Even if you don't find the solution, knowing that you did look on the bulletin board saves the support engineer a step. In addition access a web page or a bulletin board can keep you up-to-date on patch releases.
I mentioned that some companies have fax-back services. Often times answers to common questions are available. Another source is newsgroups or on-line services like CompuServe. Even if you don't get the solution to your problem, you may have gotten some of the suggestions that the tech support rep would give you. Since you already know that something doesn't work, you have save yourself the problem of getting a "try this and call back answer."
From the tech support perspective this is very helpful. First, there is the matter of saving time. If it takes 20 minutes just to get through the basic "sanity" checks, then that is 20 minutes that could have been used servicing someone else. Why do you care if someone else gets help instead of you? Well, if you happen to be the one waiting to talk to the support rep, you want him or her to be done with the other customer as soon as possible to be able to get to you quicker. The bottom line is that the quicker they're done with one customer, the quicker it is for everyone.
Make sure the hardware is supported before you call to SCO Support. If not, getting effective support is difficult at best. They may have to guess at what the problem is and possibly give you erroneous information. In many cases you will either be referred to the hardware vendor and simply told they can't help you. Not that they won't try. The issue is usually that they don't have any information about that product, so the best they can do is go from knowledge about similar products. If the product you want to use deviates from the norm, then generic information is of little value.
If a piece of equipment is not officially supported, the support rep may never have seen this before and may be unaware of quirks that this machine has. A printer may claim to be HP LaserJet compatible, but the interface script may send commands to the printer that the clone does not have. Many people will insist that this is a problem with the operating system. SCO never claimed the hardware was going to work. So, if the hardware vendor claims it is 100% compatible, it is up to them to prove it.
On the other hand, because of the nature of the job, support analysts have encounter hardware that is not officially supported. If they try to get it to work and they succeed, then they are in a position to try it the next time. If they have successfully installed something similar, then many of the same concepts and issues apply.
This same thing applies to software. Make sure the software is supported by the OS. It may be that the particular release of the application is only support on the newer version of the OS. In that case, neither the OS vendor nor the application vendor will be able to help. They know that it will not work. I remember one call into support where the customer was having trouble with a version of SCO's Professional spreadsheet product that has been discontinued for over two years. To make things more interesting they were trying to get it to work on Interactive's UNIX, not SCO.
Also try to determine if it is really an operating system problem and not specific to just one application. If you call SCO Support with a problem WordPerfect, make sure the problem also occurs outside of WordPerfect. For example, if you can print from the command line, but can't print from WordPerfect, it's not an operating system problem. However, if the OS, SCOMail and WordPerfect all have trouble printing, then it is probably not an issue with WordPerfect. The reverse is also true. It would be much better to call SCO support with such a problem than to call WordPerfect. Maybe you are only using WordPerfect, but the problem is with operating system and not just WordPerfect.
If the problem is software and deals with configuration, make sure that all of the associated files are configured correctly. Don't expect tech support to check your spelling. I had one customer who had problems configuring his mail system. He spent several minutes ranting about how the manuals were wrong because he followed them exactly and it still didn't work. Well, all the files were setup correctly except for the fact that he had made something plural although the manual showed is as being singular.
Even after you have gathered all the information about your system and software, looked for conflicts and tried to track down the problem yourself, you are still not quite ready to call. Preparing for the call itself is another part of getting the answer you need.
One of the first questions you need to ask yourself is "Why am I calling tech support?" What do you expect? What kind of answer are you looking for? In most cases, the people answering the phones are not the people who wrote the code. Many have spent hours digging through it, looking for answers or may have created an SLS or two. However, this is not the same as writing the SCSI hard disk driver. Therefore, they may not be in a position to tell you why the program behaves in a certain way, only how to correct it. Despite this, SCO Support engineers may have a better overall knowledge of the product than many of the engineers, they are probably not the ones who did the actual coding. Therefore, they may not be in a position to tell you why the program behaves the way it does, only how to correct it.
If you are contacting the support reps via fax, email or any other "written" media, be sure that there are no typos. Especially when relating error messages, always make sure that you have written the text exactly as it appears. I have dealt with customers who have asked for help and the error message they report is half of one release and half of another. The change required is different depending on the release you are running. This is also import to know when calling. Telling the support rep that the message was "something like" may not do any good. If there are several possible errors, all with similar content, the exact phrasing of the message is important.
This is also a problem with two systems when one is having the problem and the other is not. It is not uncommon for a customer to describe the machines as "basically the same." This kind of description has little value when trying to track down a problem. I get annoyed at people who use the term when trying to describe a problem. I don't want the basics of the problem, I want the details. Often customers will use it as a filler word. That is, they say "basically," but still go into a lot of detail.
Many customers insist that the two systems are identical. If they were identical, then the both would be behaving the same way. The fact that one works and the other doesn't indicates that the machines are not identical. By trying to determine where the machines differ, you narrow down the problem to the point where tracking down the problem is much easier. You even find the problem yourself, thus avoiding the call to support.
Once you get tech support on the phone, don't have them read the manual to you. This is a waste of time for both you and the support rep, especially if you are paying for it. Keep in mind that although there may be no charge for the support itself, you may be calling a toll-number. If this is during the normal business day (which it probably is), the call could still cost $20-$30. However, this is also dependent on your support contract. Many SCO customers will pay tens of thousands of dollars a year for support so that the can have the manual read to them. They don't have the time to go searching for the answer, therefore they pay someone else (SCO Support) to do it for them. If you want a premium service, you have to pay a premium price.
If you do read the manual and it still does not behave the way you expect or you are having problems relating the doc to the software, ensure that the doc matches the SW. Customer was having trouble changing his system name under Unix 324.0. He said the doc sucks because the SW did not work the way it was described in the manual. Turns out the doc he was using was for 3.2.2. not 324! No wonder the doc did not match the software
If you don't know the answer to the question, tell the support rep "I don't know." Do not make up an answer. Above all, don't lie outright. I had a customer who was having problems running some commands on his system. They were behaving in a manner I had never seen before, even on older releases. In order to track down the problem I had him check the release his was on. None of the normal tools and files were there. After poking around a while, I discovered that although this was version of Unix, it was not SCO. When confronted with this, the customer's response was that their contract for the other operating system had run out.
I once had a customer that was trying to do remote printing. He first said he had two copies of the "latest" version of ODT. I had him run swconfig and found out that the TCP/IP release was not the latest. As it turns out it was not ODT either, just the OS and TCP/IP. We then wanted to check out the other side. Well, it wasn't the latest either. In fact, it's not even UNIX at all but OS/2. So, I put the customer on hold to see if anyone knew about OS/2 connectivity. When I got back on, the customer was talking to his dealer (it was a conference call), the customer asked "Why do they need to know the release anyway?"
Getting information from some customers is like pulling teeth. They won't give it up without a fight. In order to get the right answer you must tell the analyst everything. Sometimes it may be too much, but it is much better to get too much than not enough.
When talking to support, have everything in front of you. Have your notebook open, the system running if possible and be ready to run any command the support rep asks you. If you have a hardware problem, try to have everything else out of the machine that is not absolutely necessary to this issue. It is also helpful to try to reinstall the software prior to calling. Reinstalling is often useful and several companies seem to use this method as their primary solution to any problem. If you have done it in advance of calling and the problem still persists, the tech support rep won't get off with that easy answer. Although I am not professing this as the standard way of approaching things, however if you believe reinstalling would correct the problem and you have the opportunity, doing so either solves the problem or forces support to come up with a different solution.
Another common complaint is customers calling in and simply saying that a particular program doesn't work right. Although this may be true, it doesn't not give much information to the technician. Depending on its complexity, a program may generate hundreds of different error messages, all of which has a different cause and solution. Regardless of what the cause really is, it is almost impossible for the technician to be able to determine the cause of the problem simply by hearing you say that the program doesn't work.
A much more effective and successful method would be to simply state what program you were trying to use, then describe the way it behaved and how you expect that it should behave. You don't even need to comment on it not working right. By describing the behavior, the technician will be able to determine one of two three. Either you have misunderstood the functionality of the program, you are using it incorrectly or there really is a bug in the program.
It is a very common attitude by people calling into tech support that they are the only customers in the world with a problem. Many have the attitude that all other work by the entire company (or at least Tech Support) needs to stop until their problem is resolved. Most tech support organizations are on schedules. Some have phone shifts scattered through out the day, and can only work on "research" problems during specific times of the day. Other organizations have special groups of people whose responsibility it is to do such research. In any event, if the problem requires special hardware or a search through the source code, you may have to wait several hours or even days for your solution. For the individual this may be rather annoying, but it does work out better for everyone in the long run.
The attitude that the analyst needs to stop what they are doing and work on this one customer's problem becomes a major issue when problems are caused by unique circumstances. The software or hardware company may not have that exact combination of hardware available. Although the combination ought to work, no one that has not tested it can guarantee there will be no problems. As a result, the support rep may have to wait until they are not working on the phone to gather that combination of hardware. It may also happen that they need to pass the problem to someone else who is responsible for problems of this type. As a result, the answer may not come for several hours, days, weeks or even months depending on the priority level of the contract.
In addition to the priority of the contract, there is also the urgency of the problem. If you have a situation where data is disappearing from your hard disk, you will be given a higher priority than your contract would imply.
While I was working in SCO support, I talked with many other support reps. Often a customer would have a support contract with their vendor and the vendor would have the contract with us. The vendor would call us if they could not solve the problem. I had a chance to ask many of them some of the more common problems.
There are several common complaints among tech support reps. Although it may seem like an obvious thing, many people are not in front of their machine. It's possible that the solution is easily enough that the support rep can help even without you at the machine. However, I talked to a customer who had printer problems and wanted me to help him fix things while he was driving down the freeway talking on his car phone.
Another very common issue that supports reps brings up is customers who come off as thinking they know more than tech support. When they are given suggestions their response is usually "That won't work." Maybe not. However, the behavior exhibited by the failure often does give an indication of where the problem lies. If you are going to take the time to call support, you must be willing to try everything that is suggested. You have to be receptive to the suggestion of the support rep and willing to work with them. If necessary, be willing to start the problem from scratch and go over the "basics." The customers that get the best response from support are usually the ones who remain calm and are willing to try whatever is suggested.
People have called computer manufacturers to be told how to install batteries in laptops. When the support rep explains how to do this and that the directions are on the first page of the manual, one person replied angrily, "I just paid $2,000 for this damn thing, and I'm not going to read a book."
At first glance this response sounds reasonable. A computer is a substantial investment and costs a fair bit of money. Why shouldn't tech support tell you how to do something? Think about a car. A car costs more. So, after spending $20,000 for a new car, you're not going to read the book to figure out how to start it? Image what the car dealer would say if you called in, asking how to start the car.
The computer industry is the only one that does to this level when supporting its products. Sometimes you get very naive customers. At least they are naive when it comes to computers. In attempting to solve a customer's problem it is often essential that we know what release of the operating system they are using.
Some are missing some basic knowledge about computers. One customer was having trouble where we needed to know the release. Although he could boot, he was having so much trouble typing in basic commands like uname. We told him to type uname then press return and it responded "dave: command not found." (you name)
We then asked him to get the N1 floppy and read us the release number off the floppy. He couldn't find it. Not the floppy, the release number. So after 10 minutes of frustration, we decided to have him photocopy the floppy and fax it to us.
Wow!" he said. "You can get information from the floppy that way."
"Sure," we said. "No problem." (What's so hard about reading a label?)
A few minutes later a fax arrived from this customer. It consisted of a single sheet of paper with a large black ring in the center of it. We immediately called him back and asked him what the fax was.
"It's the floppy." He said. "I'm still amazed that you can get information from the floppy like that. I must tell you, I had a heck of a time getting the floppy out of the case. After trying to get it out of that little hole, I had to take a pair of scissors to it." (The case was actually the plastic jacket).
Many of us laugh at this because this is "common knowledge" in the computer industry. However, computers are the only piece of equipment where the consumer is not expected to have common knowledge. If you drive a car, you are expected to know not to fill it up with diesel when it takes normal gasoline. However, trying to load a DOS program onto an UNIX system is not unexpected.
One customer I had was having trouble installing a network card. The documentation was of little help to him because it was using a lot of "techno-babble" that most "normal" people couldn't understand. The customer cannot even answer the basic questions about how his hardware was configured. He insisted that it is our responsibility to know that because we wrote the operating system and he's not a computer person. Well, I say, it's like having a car that won't start. You call the car dealership and tell them it won't start. The service department asks you what model you have. You say that they should know that. They then ask if you have the key in the ignition. You say that you are not a "car person" and don't know this technical stuff.
In the past few years, many software vendors have gone from giving away their support to charging for it. This ranges anywhere from $25 a call for application software to $300 for operating systems like Unix. As an end user, $300 can be a bit hard to swallow. However, in defense of the software industry it really is not their fault. As more and more computers are being bought by people who have never used one, the number of calls to support organizations have gone up considerably. People treat computers differently than any other piece of equipment. Rather than reading the manual themselves, they much prefer to call support.
Would you ever call a car manufacturer and ask how to open the trunk? Would you ever call a refrigerator manufacturer to ask how to increase the temperature in the freezer? Hopefully not. However, computer tech support phones are often flooded with calls at this level, especially if their support is free or free for a specific warranty period.
The only way for a company to recover the cost of the support is to either include it with the cost of the product or to charge extra for it. The bottom line is that there is no such thing as a free lunch, nor is there free tech support. If you aren't paying for the call itself, the company will have to recover the cost by increasing the sales price of the product. The result is still money out of your pocket. In order to make the situation fairest for everyone involved, companies are charging those people who use the tech support system.
I remember watching a television program a couple of years ago on air plane accidents and how safe planes really are. The technology exists today to decrease the number of accidents and near accidents almost to zero. Improvement to both airplane operations, air traffic control and positioning could virtually eliminate accidents. However, this would result in increasing the cost of airline tickets by a factor of 10! People won't pay that much for safety. The risk is too low.
The same thing applies to software. It is possible to write code that is bug free. The professor who taught my software engineering class insisted that with the right kind of planning and testing, all bugs could be eliminated. The question is "At what cost?" Are you willing to pay 10 times as much for SCO OpenServer just to make it bug free? Another support rep at SCO put it like this: "How can you ask us to hold up the entire product for an unknown length of time, to fix a single problem which affects few users and is not fatal? Would you expect Ford to ship their next year's model of Escort 3 months late because they found out that the placement of the passenger door lock was inconvenient for people taller than 6'9"?" As ridiculous as this seems, calls reporting bugs are often at this level.
SCO, like many other software vendors realize that bugs will happen. SCO even goes to the extent of documenting some of the known ones in the release notes.(Another good reason for reading it) In addition, because of the production issues involved, SCO (as well as many other vendors) will consider a product "ready" months before it ships. Only fatal bugs will cause the product not to ship. Known bugs are still included and maintenance supplement are already in the works by the time the first box goes out the door. To me this is acceptable behavior compared to other companies that call their bug-fixes "updates."
After years of tech support, I am convinced that the statement "The customer is always right" was not coined by some businessman trying to install a customer service attitude in his employees. It must have been an irate user of some product who didn't bother to read the manual, tried to use the product in some unique way, or just generally messed things up. When this user couldn't figure out how to use whatever he bought, he decided it was the fault of the vendor and called support.
You as the customer are not always right. Granted it is the responsibility of the company to ensure you are satisfied. This job usually falls on the shoulders of tech support, as they are usually the only human contact customers have with hardware and software vendors. However, by expecting tech support to pull you out of every hole you dig yourself into or coming across rep as a "know-it-all" or "I-am-right", you run the risk of not getting your question answered. Isn't that the reason for calling support in the first place?
You may have noticed that throughout the discussion on support, I didn't mention the different levels of support that are offered by SCO. This is difficult at best. SCO Support policies change as the demand and custome requirements change. To be safe and find out the latest prices and policies, it is best that you call SCO directly.
You may someday find yourself in a position where you cannot continue to try and solve problems over the phone. You need someone to come to your office to look at the problem first hand. This is where the computer consultant comes in. Sometimes consultants are called in to evaluate and analyze the current situations and make recommendations and sometimes even implement these recommendations.
Computer consultants are like lawyers. They often charge outrageous fees (several hundred dollars an hour) and rely on the fact that you know little or nothing about the subject. They have a service that you need and want you pay as much as you are willing to pay. Fortunately, all you need to do to see if a lawyer is qualified is to look on his wall. If the diploma is from Joe's Law School and Barber College, you'll probably go somewhere else. However, there are few laws governing who can call himself a computer consultant. Therefore, you need to be extra careful in choosing a consultant.
I had one consultant call for a customer of his who was having trouble with a SCSI tape drive. The consultant almost got upset when I started talking about the technical issues involved such as termination, proper cabling, etc. You see, he had a master's degree in electrical engineer and was, therefore, fully aware of the technical issues at hand. I asked him how much RAM does his system had. He responded, "Do you mean memory? Well, there is, huh, 32, huh, what do you call them, megabytes." (No, I'm not making this up.)
Another time a customer was having a similar problem getting a network card working. Again it was the issue that the customer did not have the basic computer knowledge to know about base addresses and interrupts. The difference between thin-net and twisted pair was foreign to him. He had worked for many years on mainframes and had never had to deal with this level of problem. After over half-an-hour of trying to help him, it became apparent that this was really beyond what tech support is there for. I suggested he hired himself a consultant. In the long run, that would ensure he got he attention and service he need. There was a long pause, and then he said, "I am the consultant."
One of my favorites is a consultant in Texas who was trying to do long distance hardware trouble shooting of a site in Alaska. Despite the fact that they had a modem connection, it is often quite difficult to check hardware settingsand cabling through a modem.
My auto mechanic has a PC running a DOS application written specifically for automobile workshops. Aside from the fact that the consultant has them start Windows and then click on an icon to start this DOS application, it does its job (it's the only thing the machine is used for). Recently they discovered that they were running out of hard disk space and needed a larger drive. So, the consultant came in put in a larger hard drive and things looked better. Since it was not part of their contract, he charged them for two hours labor to replace the drive, plus 10% more than the average market price for the hard disk. Now, so far, this seems like an acceptable practice. However, they took the smaller drive with them, although they charged full price for the larger drive. It wasn't defective, just too small.
These stories represent four basic problems with computer consultants. First, you don't have to have studied computer science or even a related field to open shop as a computer consultant. Although electrical engineering is a related field and the person may know about the computer at the transistor level, this is comparable to saying that a chemist who knows what goes on at the molecular level inside an internal combustion engine is competent enough to fix your brakes.
The next issue is that although the person had worked with computers for years, they know little about PCs or operating systems. I have seen it enough times where a consultant assumes that all computer systems are the same. They worked for years on Windows so they are qualified to install and support UNIX, right?
There is the issue of the consultant not making house calls. They have to. They have to be willing to come to your site and check the situation themselves. You cannot be expected to shut down operations to bring a computer to their office, nor should you tolerate them trying to do remote support (i.e., across a modem).
Lastly, if you do need to hire a consultant, make sure you know what you are paying for. When you do decide on a consultant, make sure that you know specifically what services are being provided and what obligations the consultant has. These services include not only hardware and software, but what work they are going to provide. If they need to replace a defective hard disk, the cost of the disk is include, but the time to replace it may not.
The best solution is to ask your friends and other companies. If you have a good relationship with another company of similar size and product, maybe they can recommend a consultant to you. Another source is the Internet and on-line services like CompuServe. Ask people there what they experiences are. Also, contact SCO. They provide a list of authorize resellers and consultants based on region of the country. This way you get one that is from your area and knows SCO.
Although, as I said, there is no such thing as a free lunch, you can get pretty close some times. For about less than a $30 start-up fee and about $10-$20 a month, you can get support that is comparable to SCO Support. The only problem is that it might be several hours (rarely longer) before you get an answers. I am talking here about the SCOFORUM on CompuServe.
The September 1995 issue of SCO World magazine included an article on the CompuServe SCOFORUM. It was written by Jean-Pierre Radley, one of the system operators (sysops) for the SCO Forum. Rather than repeating the contents of the article or the CompuServe literature, I would simply like to say it is well worth the money.
The topics range from basic shell programming issues to kernel internals and beyond. You will find people who have been working with SCO products for years and who can provide valueable insight into the various SCO products. There are are many professional writers who pop up, such as John Esak, who is a columnist for SCO World magazine. I, too, am a regular contributor.
Despite the delays that are caused by the very nature of this media, responses are fairly quick. Unless your system has crashed and you are loosing thousands of dollars an hour, this is an execellent source of information. If you have email and fax support with SCO, you probably end up getting your answers faster through CompuServe.
CompuServe customer service can be reached at 800-848-8990 or 614-529-1340. In addition, there are offices all over the world. The CompuServe "starter-kit" that is available through many computer software sources contains a list of phone numbers.
Another valueable source is the is the USENET newsgroups. In order to gain access, however, you need a "news feed." That is, some other site that will provide you with the newsgroups. Because USENET uses "store and forward." Turn around time, can be days, depending on where you get your feed. CompuServer, on the other hand, stores all of it's messages in a central location. The minute your message is posted, it is available for everyone.
Throughout this book I made references to several other works that I feel would be very helpful, if you want to learn more about a particular subject. Aside from books, there are many magazines that provide useful information. Although more geared toward DOS and Windows, BYTE magazine often provides good technical articles about both new and existing technologies. There is, of course, SCO World magazine that provides technical information as well as SCO related news.
One magazine that is beginning to make it's mark in the SCO marketplace is Inside SCO UNIX Systems published by The Cobb Group. For those who are not familiar with them, The Cobb Group publishes dozens of technical magazine ranging from Microsoft Office to Borland's Parodox to one of their latest additions, Inside SCO UNIX Systems.
I think the biggest difference between SCO World and Inside SCO UNIX Systems is like the difference between commercial TV and public television. Commericial television is paid for by advertisements. As a viewer, the fee you pay is nominal if you have cable or free if you use your antenna. It is similar with SCO World.
Public television is paid for by the viewers. Although the yearly pledge you make to your local PBS station is comparable to your fees for cable, you are only paying for one channel. With Inside SCO UNIX Systems the situation is similar. There are no adds, not even small ones. The publication of the magazine is paid for exclusively by subscription fees. I like not having my programs interrrupted by commericals, that's why I was a member of a PBS station when I was living in California. I also like to be able to read articles without commerical breaks. I also like the fact they alreay come with holes in them so the fit nicely into three-ringed binders.
Please don't get me wrong. I subscribe to SCO World, as well. Just as I watch commerical TV. Both PBS and commercial TV have their place, just as SCO World and Inside SCO UNIX Systems each have their place.
For subscriptions, SCO World can be reached at 800-879-3358 or 303-604-1464. If you want, you can use their email address, which is firstname.lastname@example.org. Inside SCO UNIX Systems can be reached at 800-223-8720 or 502-493-3232. Or for information and subscriptions, their email address is email@example.com.
Another place is the Internet. Unfortunately it's hard to be more specific. There are thousands of resources out there for every conceivable topic. Most major computer companies have a Web site. Often all you need to do it add www to the company name to get access to the Web page. I have done this in getting to Intel (www.intel.com), Conner (www.conner.com) and even CNN (www.cnn.com). Here you can get product information as well as press releases.. Many of these have links to other sites so it's easy to bounce from site to site.
Copyright 1996-1998 by James Mohr. All rights reserved. Used by permission of the author.
Be sure to visit Jim's great Linux Tutorial web site at https://www.linux-tutorial.info/