Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ucsd!ucsdhub!esosun!seismo!uunet!sco!rosso
From: rosso@sco.COM (Ross Oliver)
Newsgroups: comp.unix.xenix
Subject: Re: VPIX and other SCO complaints
Message-ID: <1510@viscous.sco.COM>
Date: 6 Feb 89 22:00:13 GMT
References: <29@ajfcal.UUCP> <5980008@hplsla.HP.COM> <14152@cup.portal.com>
Reply-To: uunet!sco!rosso (Ross Oliver)
Organization: SCO Technical Support
Lines: 99

In <14152@cup.portal.com>, compata@cup.portal.com (Dave H Close) writes:
>
> Everyone on this net can certainly send email to SCO (uunet!sco!support).
....
> In theory, email should be more efficient for all concerned.
....
> So why don't we try to train SCO to use email as
> first priority?  Let's all send them mail whenever we have a problem (maybe
> in addition to a phone call for urgent problems).

Dave is right, electronic support can be more efficient and less hassle
than waiting on hold for half an hour.  SCO uses e-mail extensively within
the company, and I believe it could be just as effective in supporting
customers for non-critical issues.  However, if not handled correctly,
it can be just as time-consuming and frustrating, if not more so, than
telephone support.  I would like to suggest some guidelines to help both
you and SCO to make the most of electronic mail.

Many of the mail messages we receive have no identification whatsoever.
I think the informal nature of Usenet promotes the misconception that
everone knows everyone else.  Someone sends mail from uunet!foobar!root,
and expects us to know exactly who they are.  A message like this will
almost always end up in the bit bucket.  So, rule number one:

                Always clearly identify yourself

Include in your message your name, company, return email address,
and phone number.  If you have a support contract, or have otherwise
registered with Support, include your customer key number also.

Another problem with email is that unlike a telephone conversation,
it is primarily one-way communication.  For us to solve your problem
as quickly as possible, you must provide as much information as possible
on the first contact.  Otherwise, several days may be wasted as the
responding Support Engineer must query for additional information.  For
example, here is a message that arrived recently:

    Hi
    We are SCO level 2 resellers here in ###############.
    I have a client with 2 Wyse 100 terminals, and he is unable to
    use mscreen. Additionally, the Wyse 100 has no ~ and `.
    The mscreen problem is primary problem.
    Any help is appreciated. Thanks

    <person's name and contact info>

This message is missing vital information necessary to solve the problem.
What are the details of the problem?  "Unable to use mscreen" does not
provide any information to help diagnose the problem.  What is the exact
command line?  Is there an error message?  What is the machine configuration?
Since mscreen is a new utility, I know his client is running release 2.3 on
a 386-based machine.  However, if the problem had been with a more generic
utility, I would not have known anything about the system configuration.
This lack of sufficient information is the reason for our current procedure
of handling support questions submitted via electronic mail (and FAX as
well): customers will be contacted by phone, and scheduled into our regular
hotline support.

On the same day, the following message was also received:

    I'm running SCO Xenix 386 2.3.1 currently on an ITT 386 XL Model 10 with
    4 Mb of RAM and 15 Mb of free disk space.

    I have a subdirectory with about 70 C source files.  When I use "doscp * b:"
    to copy the files to a diskette, about 42 of the files are copied when a
    message
    doscp: no memory for buffers
    appears on the terminal.  What causes this and how can I fix it?

    <name and contact info>

This message is much more complete.  It contains a description of his
environment, the exact command that is causing the problem, and the
resulting error.  From this description I have been able to reproduce
the problem.  Even if I had not been able to do this, having the
text of the error gives me something to look for in the source code
to find out what might cause the problem.  So, rule number two:

                  Details, Details, Details

Describe as accurately as possible the symtoms of the problem.  Include
exact commands or sequences of keystrokes, and text of any error messages.
Also describe the environment in which you are working: the full release
numbers of your software, your machine type, and installed peripherals.
The more complete the information, the more likely we will be able to help
you without time-wasting requests for additional details.

As Dave mentioned, SCO Technical Support can be reached at uunet!sco!support.
Through arrangement with the Univeristy of California, Santa Cruz, we also
have an Internet address of support@sco.COM.  Other possible paths are
sun!sco, and ucbvax!ucscc!sco. We can also accept FAX support requests;
the SCO FAX number is (408) 458-4227.  Since many different departments
receive FAX's on this number, be sure you specify that your FAX should go
to Technical Support.

Ross Oliver
Software Support Engineer
The Santa Cruz Operation, Inc.
sco!rosso