Modem interoperation blues

Greg Andrews gandrews at netcom.COM
Wed Feb 20 14:53:46 AEST 1991


In article <1991Feb18.171101.27050 at rwwa.COM> witr at rwwa.COM (Robert W. Withrow) writes:
>>I would suggest that you call and try some test transfers.
>
>Trust me, I've tried!  You must remember:
>
> 1) I don't own a Telebit modem.  Telebit is thus (reasonably)
>somewhat reluctant to provide me with technical support.

True, Telebit won't be able to spend as much time with you as if you
had bought a Telebit modem.  Still, demonstrating the problem shouldn't
take very long (as I stated in my last post).  Have you even _tried_ to
duplicate the problem with a transfer protocol that the tech can run
on the spot from their bench (Xmodem, Ymodem, Kermit...)??

>  I suppose I could buy one just to debug the problem, but I don't 
>understand why I should do modem manufacturers R&D for them...

Well, that's not what I was asking you to do - sorry if my message gave
that impression. 

> 2) Even if I were to get technical support from them and they
>determined that there was an `incompatibility', without test equipment
>on my end it would be difficult or impossible to tell where the fault
>lies.  For example, if Telebit told me that the PPI modem was
>``wrong'' (which, incidentally, they have already done)  should I
>belive them?  Do you think PPI would?

Why is it your job to determine 'where the fault lies'?  It's not even 
the phone technician's job to do that.  After the problem has been
demonstrated, your jobs are finished.  The tech then gives a report to
his/her engineers and THEY figure out which modem has the bug.  

The engineers are the only ones who have the equipment and the knowlege 
to dig that deeply into the modems and figure out where the problem is.  
Neither the customer nor the phone tech can make that determination except 
empirically (e.g. "if it works with all other modems but this one, then
maybe THIS modem has the problem...").

> 3) PPI, the modem I *do* own, doesn't seem to know what uucp is (it
>is not mentioned in the owners manual, and their support people were
>not conversant about it)!  In fact, the technician I spoke to had
>never heard of Telebit!

There's not much that anyone but PPI can do about that.  I talk with
the Sysop of the PPI forum on Compuserve quite a bit.  While he knows
almost nothing about Unix and uucp, he seems willing to slug it out
if it helps his customers.  To be fair, if you had called Telebit
tech support five years ago, you would have found that they knew just
as little about uucp.  After a while, the company learns about the
market they sell into, and Telebit has been selling into Unix for a
few years now.

>The upshot of all this is, when dealing with V.42/V.42bis and UUCP:
>Don't be surprised if modem manufacturer A's modem fails to work with
>manufacturer B's modem.

I agree with you.  V.42bis has been out for how long now?  A year and
a half?  The ways and means of handling a relatively new error control
protocol (V.42) and a very new compression algorithm (V.42bis) are still
new to everyone involved.  How long did it take (is it still taking)
for most V.32 modems to be able to link together?  New features are new
features, and though I hope for the best, I still expect problems to pop
up between manufacturers from time to time.

>Don't expect to see a flurry of concern from Tech Support if they don't 
>work.  

I disagree with that.  Has PPI showed a lack of concern for the trouble
that you, their customer, are having?  They may not know much about your
computer, but I don't think that would make them unconcerned about your
problem.  As you mentioned before, Telebit can't be expected to give an
enormous amount of support for someone who bought the other guy's modem,
but did they show a LACK of concern?  How many calls did you make to
Telebit tech support and what sort of tests did they try with you?

>Do expect to spend hours and hours of your own time diddling with 
>your modem settings and software options to get it to work.  
>
>The good news is that if you are persistent, you are likely to get it
>to work.

That's the state-of-the-art in Unix, I'm afraid.  In keeping with the
overall philosophy of Unix, it provides general-purpose tools to use
for the task at hand.  It doesn't provide a ready-made environment for
ANY modem to just plug-n-play.  Not even Telebit modems.  Some vendors
have included modem-specific extras into their systems (like SCO's
dialTBIT binary dialer or the pre-programmed Dialers entrys), but you
still need to configure the modem correctly, still need to decide
whether getty should be fixed speed or cycling, etc., etc...

After all is said and done, my Summary line still holds.  Until the
problem is demonstrated to someone, it won't be fixed.  The best advice
I can give you is to demonstrate it to one of the companies, whether
Telebit or PPI.  Until that happens, nobody thinks there's anything
wrong with their modems...

-- 
.-------------------------------------------.
| Greg Andrews      |   gandrews at netcom.COM |
`-------------------------------------------'



More information about the Comp.unix.sysv386 mailing list