tony@ajfcal.UUCP (Tony Field) (01/29/89)
I have notices a number of *strong* complaints about the quality of the
Vpix system and of SCO hotline service. Although I agree with some
of the technical complaints, I do have a different opinion about SCO & Vpix.
1. When I decided to try a DEMO version of Vpix, SCO informed me that
Vpix should not be considered a *perfect* dos interface for all
applications. It should be used whenever reasonably well behaved dos
programmes MUST be run in a Xenix environment. For those applications
that I tried, amongst which are LOTUS, WordPerfect 4.2, and a few
compilers, I was completely happy with the way that Vpix handled the
system. Certainly some *poorly behaved* programmes caused problems.
2. I was VERY pleased with how well Vpix handles the system console and
attached terminals. I am pretty sure that Vpix handles terminal i/o
by some "memory/page fault" mechanism with a bunch of associated
computations to determine where the data is to be placed on the
target terminal. This is slow/expensive but I am impressed with how fast
it does run on a time-share system.
^^^^^^^^^^^^^^^^^
In article <5980005@hplsla.HP.COM> jeffh@hplsla.HP.COM (Jeff Harrell) writes:
> 1) Support- I do not like being placed on hold for 15-30
> minutes only to be told I can get an "appointment"
> in two to three days. It's been my experience that
> the person on the other end of the line ( the one
> that calls back in a couple of days ) knows less
> about VP/ix than I do.
3. I have found that hot-line support is usually excellent. The analysts
are generally competent. On occasion, I have had to place a second
call to get assistance from a more "senior" analyst with better knowledge.
4. The SCO person who 'screens' your call determines the analyst to whom
you talk to. The better you describe your problem, the better he/she
is able to direct the problem to the appropriate level of analyst.
(I think SCO has 4 different levels of skill in the analysts: the
'screener' directs the problem to the analyst based on YOUR description
of the problem - therefore describe the problem ACCURATELY).
5. If you need FAST answers, then request an EXPRESS call. This generally
gives you "immediate" access to an analyst for "short/critical" questions
needing no more than 5 minutes of analyst time. This has saved my
skin a couple of times when I have had to re-build a totally
corrupted system after major power problems. If I loose my temper because
I must wait for 6 minutes before I can talk to the analyst, I always
remember that it is SCO's dime that pays for the long-distance call,
not mine (however, I did pay for SoftCare - so it really is my dime).
One improvement SCO could make is to have a special SUPER-CRITICAL
call to assist people who are attempting to rebuild a production system.
It is totally unacceptable to have 15 accountants or 20 people
in the word processing pool down for more than a short while. A
call "returned tomorrow" under these circumstances is of NO VALUE.
6. I am unhapppy with the fact that I get a 30 minute appointment, possibly
"tomorrow" to chat with an analyst.
A friend of mine has had Xenix for 2 years: he indicates that this is
a "recent" phenomena (within the past year) probably due to the
dramatic increase in popularity of Xenix. He used to get immediate
response to ALL of his problems - including direct contact with the
Xenix development staff. Such is the price of popularity.
He also indicated that e-mail used to be "faster" than voice: however
there is now a bottleneck in the e-mail response. ouch..
7. I do not use Vpix: I prefer to use a dedicated DOS machine rather than
mix up my environment.
8. Another (for me) serious problem: Vpix and CGI do not like to co-exist.
SCO is working on this.
These are my OPINIONS and reflections on my experiences. Since I am my
own boss, these also reflect the option of my boss.
I hope I am not in the minority.....
tony......
--
+------------------------------------
| Tony Field ..alberta!calgary!xenlink!ajfcal!tony
| Co-Design Information Systems Ltd.
| Calgary, Alberta, Canadarfarris@serene.UUCP (Rick Farris) (01/30/89)
One thing I haven't seen discussed here, is the fact that some of "SCOs" analysts are actually part-time contractors, working at home. I'm not sure of the proportions, but I know there are people out there (Sandy?) that are paid on a per-call basis. That's the real reason for the delays in call backs. SCO has to locate a person to call you, who has to do something with their "real job", and finally get back to you. Rick Farris RF Engineering POB M Del Mar, CA 92014 voice (619) 259-6793 rfarris@serene.cts.com ...!uunet!serene!rfarris serene.UUCP 259-7757
jeffh@hplsla.HP.COM (Jeff Harrell) (01/30/89)
>I have notices a number of *strong* complaints about the quality of the >Vpix system and of SCO hotline service. Although I agree with some... You bet you are going to hear a few complaints. VP/ix is buggy! >It should be used whenever reasonably well behaved dos >programmes MUST be run in a Xenix environment. PFS-FIRST CHOISE, PAGEMAKER and VENTURA are "well behaved dos applications". Try one of them out before you speek... >I have found that hot-line support is usually excellent. The analysts >are generally competent. Could you please email the number you are calling! We MUST be talking about a different support organization! SCO support has been very poor at BEST for me. >I do not use Vpix: I prefer to use a dedicated DOS machine rather than >mix up my environment. Well, on this I agree! If VP/ix did what it's been said it would you'd use the product- I paid for it to use it; not let it collect dust. Sure hope the BUGS start going away... ---------- Jeff (Spectra Software) Harrell
sandy@turnkey.TCC.COM (Sanford 'Sandy' Zelkovitz) (01/30/89)
In article <363@serene.UUCP>, rfarris@serene.UUCP (Rick Farris) writes: > > > One thing I haven't seen discussed here, is the fact that some of > "SCOs" analysts are actually part-time contractors, working at home. > I'm not sure of the proportions, but I know there are people out > there (Sandy?) that are paid on a per-call basis. That's the real > reason for the delays in call backs. SCO has to locate a person to > call you, who has to do something with their "real job", and finally > get back to you. > > Rick Farris RF Engineering POB M Del Mar, CA 92014 voice (619) 259-6793 > rfarris@serene.cts.com ...!uunet!serene!rfarris serene.UUCP 259-7757 Rick, SCO has a complete support staff and does not rely on outside contractors to handle complaints, etc. They do, however, recommend outside help, such as device driver programming, system administration, and the like. In some cases, they may also go out for external programming such as the Multiview package, VpiX, and X-windows. SCO has a VERY nice system for Technical Support internally. The call is first given to a "general" support person. If the problem/question is too much that that individual, the call is then given to a specialiced in that area. My only connection with SCO is as a VAR and am recommended to companies to help solve their individual problems. Sandy -- Sanford <sandy> Zelkovitz XBBS 714-898-8634 UUCP: ....att!hermix!alphacm!sandy ....trwrb!ucla-an!alphacm!sandy ....uunet!turnkey!alphacm!sandy ....ucbvax!ucivax!icnvax!alphacm!sandy DATA: 714-898-8634 VOICE: 714-894-7898
les@chinet.chi.il.us (Leslie Mikesell) (01/31/89)
In article <29@ajfcal.UUCP> tony@ajfcal.UUCP (Tony Field) writes: [defense of VPix deleted] >7. I do not use Vpix: I prefer to use a dedicated DOS machine rather than > mix up my environment. Some defense: what you are saying here is that VPix is not good enough to use. If it worked right there wouldn't be any problem with the mixed environment. I would define working "right" as acting like a networked DOS machine with full support for netbios. Oh well, maybe sun will do things right in their rumored <$5K unix/dos machine... Les Mikesell
root@conexch.UUCP (Larry Dighera) (02/01/89)
In article <363@serene.UUCP> rfarris@serene.UUCP (Rick Farris) writes: > >One thing I haven't seen discussed here, is the fact that some of >"SCOs" analysts are actually part-time contractors, working at home. >I'm not sure of the proportions, but I know there are people out >there (Sandy?) that are paid on a per-call basis. Can you support your alleged statement of fact with some supporting evidence. This is the first I have heard of SCO employing independent contractors as remote Technical Support Analysts; certainly Sandy Zelkovitz is not one. How about some real facts? Larry Dighera -- USPS: The Consultants' Exchange, PO Box 12100, Santa Ana, CA 92712 TELE: (714) 842-6348: BBS (N81); (714) 842-5851: Xenix guest account (E71) UUCP: conexch Any ACU 2400 17148425851 ogin:-""-ogin:-""-ogin: nuucp UUCP: ...!uunet!turnkey!conexch!root || ...!trwrb!ucla-an!conexch!root
compata@cup.portal.com (Dave H Close) (02/01/89)
Everyone on this net can certainly send email to SCO (uunet!sco!support). They don't seem to know how to process it, it sometimes gets lost or doesn't receive appropriate priority. However, that seems to be getting better. I theory, email should be more efficient for all concerned. I've encountered analysts who are willing to bs for 10-15 minutes about non-critical issues; while I appreciate the info, I'm sure that others waiting would appreciate us getting off the line. 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). It should be possible for SCO to get some people to work overtime or from home answering email questions with serious improvement for their schedule and our response. Dave Close, Compata, Arlington, Texas
scf@statware.UUCP (Steve Fullerton) (02/03/89)
Enough support bashing for a while. We have several systems including
SCO and 386/ix. I deal with both customer support groups and really must
applaud the support from Interactive. I have always been connected to an
analyst without waiting or having to deal with a call back. Furthermore,
they don't seem in a great rush to finish with my call (are SCO analysts
on an incentive plan based on the volume of calls they handle? :-). To
my amazement, they even make followup calls to insure that a problem has
been resolved. (To SCO's credit, I have also received a followup call;
however, it was 3 weeks later). In addition, Interactive doesn't charge
for support!
I sure hope they keep it up as they get more sites installed.
--
Steve Fullerton Statware, Inc.
scf%statware.uucp@cs.orst.edu 260 SW Madison Ave, Suite 109
orstcs!statware!scf Corvallis, OR 97333
503/753-5382rosso@sco.COM (Ross Oliver) (02/07/89)
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