HDTenEightyP/NetNews huggingface dataset:
From: Petty@ralvm29.VNET.IBM.COM (Jack Petty)
Date: Wed, 9 Sep 92 13:13:51 EDT
Newsgroups: comp.dcom.modems
Subject: Re: IBM 7855-10 Disconnect at Phone Pick-Up
Disclaimer: This posting represents the poster's views, not those of IBM
News-Software: UReply 3.0

In <9209090702.AA17611@ucbvax.Berkeley.EDU> ST7021@SIUCVMB.SIU.EDU writes:
>
>  o Is this some V.32(bis) thing (my old Hayes VS9600 doesn't do this at
>    9600)?
Thomas,
That's right.  The "Retrain" message on the front panel means the 7855
is doing the V.32 retrain thing.  Two things can produce that message:
   The 7855 is trying to recover from what it thinks of as a bad line or,
   The local DTE has told the 7855 to go on-hook and the 7855 is
   signalling that fact to the other modem.
You can differentiate between the two cases by temporarily setting the
7855 to ignore local disconnect attempts.  You can use &D0 if your local
DTE drops DTR to do a disconnect or you can change register S2 to 255
if your DTE sends an escape sequence to initiate a disconnect.  Change
both settings if you don't know what your local DTE does and remember to
reverse the changes later.  I suggest you make these changes and re-try
to see if the symptoms change.

If your re-train setting is at the factory default, the 7855 will
normally try to recover a "bad" line for 30 seconds.  You can look at
the results of a \S and then \S1 command to see the complete modem setup.

>  o Could it be interpreting the drop in volume (or whatever) as a Break
>    signal? Would that be relevant?
Thomas,
Not likely.

>  o Is there a register that I can alter that will make it more tolerant
>    to this?
Thomas,
I can't answer this one until we understand more about what is going on.
There are some V.32 modems that do not respond to a V.32 re-train but
I certainly hope those are a minority.
>
>I can understand how rough a local line pick-up can be on the carrier, but I
>was hoping the error correction would be a bit more fault tolerant.
Thomas,
Good point.  Is there a difference in behavior between having ECL turned
on or off?
>
>Thanks for any ideas!
Thomas,
If you like, we can call your 7855 from here with a 7855 and see how two
of them behave when you take an extension off-hook.  This would be a
good thing to do after you determine that your local DTE is not
instructing the 7855 to go on-hook.

If all else fails...
You might be able to re-wire your house so the extensions are "behind"
the modem.  In that case, when the modem is off-hook, the extensions
are dead.  There are also devices that attach at each extension and
allow only one extension at a time to "own" the phone line.

I have seen a number of posts here about modems that go on-hook in
response to call waiting tones.  One real possibility is that many
V.32 modems do not recover from line glitches.

Jack Petty
From: Dave Caulkins <dcaulkins@igc.apc.org>
Newsgroups: comp.dcom.modems
Date: 14 Sep 92 21:10 PDT
Subject: Re: Latest WB ROMs from UUNET?
Nf-ID: #R:1992Sep14.201146.18300@europa.as:60847793:cdp:1346000028:000:59
Nf-From: cdp.UUCP!dcaulkins    Sep 14 21:10:00 1992


I believe the latest version of WB ROMs is LA5.01.

Dave C
From: jnm@ornl.gov (Jamey Maze)
Newsgroups: comp.dcom.modems
Subject: FAQ answer: modem acronyms...
Date: 14 Sep 92 21:20:01 GMT
Followup-To: comp.dcom.modems
Organization: Oak Ridge National Lab

Friday I posted a note on comp.datacom asking for definitions of some key
modem acronyms. A summary of what I learned is given below. Many thanks to
Camillo Sars, Stephen J. Walick, Soenke Behrens, Lam Lai Yin Savio, Roger
Nordin, John Wallace, Alan Edmonds, Toby Nixon, and others who replied
after I composed the summary below. 

--

V.32, V.32bis, V.42, and V.42bis are CCITT standards.

V.32	- A full-duplex modem which can operate in either asynchronous or
synchronous V.32 mode, with Trellis Coded Modulation, utilizing a speed of
9600 bits per second (bps), with a selectable fallback of 4800 bps.

V.32bis	- A full-duplex modem which can operate in either asynchronous or
synchronous V.32bis mode, with Trellis Coded Modulation, utilizing a speed
of 14,400 bps with selectable fallback speeds of 12,000, 9600, 7200, or
4800 bps.

V.42	- A standard protocol for error correction which provides error-free
transmission over a standard full-duplex, V.32bis,	V.32, V.22, V.22bis, or
Bell 212A connection, also a protocol which includes the Link Access
Procedure for Modems (LAP-M), the main protocol used between two V.42
modems; additionally, V.42 includes an alternate protocol, the Microcom
Networking Protocol (MNP)tm up to class 4 to provide backward compatibility
between V.42 and existing MNP modems.

V.42bis	- A high-performance data compression algorithm that increases the
data throughput by a ratio of upto 4:1, only possible if both sending and
receiving modems establish connection using LAP-M and if both connected
modems are configured for data	compression.

MNP	- Trade Mark acronymn for the Microcom Networking Protocol, class 1
through 4 for error correction, class 5 for data compression increasing the
data throughput up to 2:1, class 10 for extreme error correction on
cellular data connections.

An MNP5 connection includes MNP4 error correction just like a V.42bis 
connection includes V.42 error correction. The main difference between MNP5

and V.42bis is, apart from the much better compression in V.42bis, the fact

that V.42bis adapts itself to the data being sent, and shuts itself down if

the data is pre-compressed, and thus cannot be compressed further. MNP5
always 
sends the "compressed" data, and thus, on precompressed data, the
throughput 
can actually be degraded, as it adds useless overhead to the data stream.

Also, we have V.Fast now, which will be released somewhere around 1994,
which will be 28,800 bps full-duplex communication. It will probably allow
19,200 speed on lines which permit 14,400 V.32bis today, and faster
depending on the line quality.


--
Jamey Maze, Oak Ridge National Lab
From: kenny@osf.org (Kenneth Crudup)
Newsgroups: comp.dcom.modems
Subject: Cardinal 9600V.42 modem info wanted
Date: 7 Sep 92 06:19:57 GMT
Organization: Open Software Foundation


I hope someone can help me. I've got this 9600 baud modem, and I don't have
any docs for it. All I do know is that it's a "Cardinal" brand "9600V42"
modem. It's an external modem, in a black case, and a separate power supply.

There is a sticker on the bottom, but as Murphy would have it, some of the
lettering is coming off, so all I can make out for what appears to be the
"model code" is GDE9600V42.

It seems very generic, and I would hope someone could give me (fax me?)
the AT-codes for things like MNP/V.42 selection, setting up RTS/CTS, etc.

I've been using it like I got it and have been able to only average 1070
cps on binary data, which may be all it can do if it's just a V.32, but I'd
like to be sure. I'd also like to setup RTS/CTS flow control and speed locking.

Thanks in advance.

-- 
Kenneth R. Crudup, Contractor, OSF DCE QA
OSF, 11 Cambridge Center, Cambridge, MA 02142	+1 617 621 7306
kenny@osf.osf.org			OSF has nothing to do with this post.
Not one of the "PC" weenies.
From: slq56@cc.usu.edu
Newsgroups: comp.dcom.modems
Subject: << PP14400FXSA HELP NEEDED ASAP >>
Date: 11 Sep 92 02:09:56 MDT
Organization: Utah State University

I just recently purchased a Practical Peripherals PP14400FXSA modem for
use on my BBS, however, I've run into some difficultly getting it to
connect properly under Binkleyterm 2.56.  When another high-speed modem
attempts a connection, both data compression and error correction disable
once the connection is made.  I don't think it's the frontend mailer I'm
using, rather the init string.  I would very much appreciate it if someone
would send me their modem initializating settings for this specific
brand, and/or some suggestions as to how I can fix this.  It's of 
extreme importance I get this running soon, and any information anyone
can provide me with will be VERY much appreciated. 

                                             Thanks,
                                                -Frank
                                                 SLQ56@cc.usu.edu
Newsgroups: comp.dcom.modems
From: jwarring@violet.srg (Jeff Warrington)
Subject: BOCA 14.4 problems
Reply-To: jwarring%srg@uunet.uu.net
Organization: ARINC Research
Distribution: comp.dcom.modems
Date: 9 Sep 92 11:47:38

I would be interested to know if the Self Test procedures described in
chapter six of my ~manual~ work on anyone else's modem.  It describes
what works if the procedure compleates properly but they never
addressed what was wrong or what to do if the test didn't succeed
~('cause of course that wouldn't happen)~.  Any way mine returns
"ERROR" for any AT&Tn I am hoping that this is why my modem seems to
drop connections seemingly at random.

I would be interested in hearing about trouble people have had w/ BOCA
equip.

jwarring%srg@uunet.uu.net
--
blah blah blah blah blah blah blah blah
     uunet.uu.net!srg!jwarring
blah blah blah blah blah blah blah blah
blah blah blah blah blah blah blah blah
         Jeff Warrington
From: geoff@zswamp.UUCP (Geoffrey Welsh)
Newsgroups: comp.dcom.modems
Subject: Re: What is best modem for UUCP?
Date: Wed, 09 Sep 92 21:40:46 EDT
Organization: Izot's Swamp

alanlb@bethesda.cs.vt.edu (Alan L. Batongbacal) writes:

> Hi there!  I've been following this group for sometime, hoping to catch
> a UUCP thread.  I need to make a decision regarding modem choice for
> UUCP bulk transfers.  I really don't need any fax features--all I need
> is the fastest modem I can get for about $700-$800.  I'm tilting
> towards the Telebit 3000 and/or something like it.  What do you think?

   The Telebit 3000 is a fine V.32bis modem, but UUCP-g protocol's window size 
is insufficient to capitalize fully on error-corrected, dialup connections as 
fast as 14400 bps.  Not only will you find the UUCP-g throughput of the 
Telebit WorldBlazer to be slightly higher thanks to the protocol spoofing that 
makes up for the fact that PEP is essentially a half-duplex protocol, but I 
think that you'll find that most UUCP feeds support PEP.  Well, OK, most 
support both... but you'll find some sites that support PEP but not V.32bis, 
and few which support V.32bis but not PEP.  In addition, PEP deals much better 
with bad lines.

   If you can get your hands on a Telebit WorldBlazer, especially if your 
feed(s) have one, you'll find this the best modem for a UUCP feed.  It also 
supports V.32bis, if standards and wide compatibility are a concern.

Geoffrey Welsh, 7 Strath Humber Court, Islington, Ontario, M9A 4C8 Canada
geoff@zswamp.uucp, [xenitec.on.ca|m2xenix.psg.com]!zswamp!geoff (416)258-8467
         Coincidentally, most people who fight for "fairness" would be
         significantly better off under the system they call "fair"...
From: SUJANSKY@CSEARN.BITNET (Maros BOJKO)
Newsgroups: comp.dcom.modems
Subject: BEST 2400 PLUS modem problem
Date: 9 Sep 92 23:58:02 GMT
Distribution: world
Organization: The Internet


     I have gratuated at Technical University in Kosice this year.  I
have got several hobbies, but the greatest are computers.  In our
country it was very difficult to gain some pieces of information on
computer technology several years ago.  So I was fascinating when I had
got an opportunity to contact several BBS in USA three years ago, in
time of deep communism.  I had some problems, but I decided to work in
this field.  I bought a modem after smart revolution.  It was BEST 2400
PLUS (w/o MNP protocol), but it is all I know about producer.  The
problem is I would like to uprade it for MNP 5 (or 9600 baud), but I do
not know how to solve this (in manual is written it is possible).  I
tried to find BEST company through nic.ddn.mil (unsuccessfully).  It's a
pity I cannot afford to buy a new 9600 baud modem, because prices are
still very high in our country.  Can you send me an info where can I get
such information?

    Is there any possibility to get more info on my problem?  I would
be very grateful for any piece of information available.

Thank you in advance.

     Maros

My address: Maros BOJKO
            Volgogradska 30
            080 01 Presov
            Czech and Slovak Federative Republic

    E-MAIL : sujansky@csearn.bitnet
        or   sujansky@147.32.1.3
From: dplatt@ntg.com (Dave Platt)
Newsgroups: comp.dcom.modems
Subject: Re: UUCP 'G' protocol packet size
Date: 9 Sep 92 17:38:04 GMT
Organization: New Technologies Group, Inc.  Palo Alto CA

In article <5259@airs.com> ian@airs.com (Ian Lance Taylor) writes:

>Moreover, every 'g' implementation that I am aware of will accept
>varying block sizes in a single conversation, up to the requested
>limit.

Interesting - I've had almost the opposite experience.  Both SunOS 4.1.x
uucp (a HDB variant), and ULTRIX uucp (whatever version APPLE.COM is
currently running) seem to have hard-coded 64-byte-packet receivers.  If
one tries to send them a shorter (32-byte) packet, neither one handles
it properly... the packets are either rejected, or result in timeouts.
I ended up deciding that "smart packet" mode (sending packets shorter
than the limit) should be enabled only when the peer site sets a limit
of 128 bytes or more.

On the other hand, Taylor uucp is remarkably tolerant... it not only
accepts packets which are shorter than the negotiated limit, but it also
accepts packets which are _longer_ than the requested limit.  I tried
force-feeding it 256-byte packets, in a session which had requested a
64-byte limit, and it gobbled them down just fine.  Nice work, Ian!  [I
know, I know, this technique is a revolting violation of protocol... but
I haven't yet had the energy required to write up a set of Taylor-style
configuration files which would enable g-protocol INIT negotiation of
256-byte packets... I'm still using HDB accomodation mode.]

-- 
Dave Platt                                                VOICE: (415) 813-8917
              Domain: dplatt@ntg.com      UUCP: ...netcomsv!ntg!dplatt
 USNAIL: New Technologies Group Inc. 2468 Embarcardero Way, Palo Alto CA 94303
Newsgroups: comp.dcom.modems
From: dpsmith@pbhyb.PacBell.COM (David P. Smith)
Subject: Re: Anyone using PC Pursuit (or similar services)?
Organization: Pacific * Bell
Date: Thu, 10 Sep 1992 13:52:09 GMT

From article <1992Sep10.040135.16428@nntpd2.cxo.dec.com>, by j_parsons@moutns.enet.dec.com (What was sliced bread the greatest thing since?):
> --
> Is anyone here still using Sprint's PC Pursuit service? I used to be an avid 
> user but had to bail out when they did away with the unlimited usage for $30/month a few years ago. I am curious to find out if the service is still around, and if so what the current pricing policies are. Do they support 9600 baud (or higher) yet? Are there competing services which support 9600?

I used to use it, but when I got my dual standard it was better to use the
modem at 9600 than poke along at 2400.  The 30FRNs/mo was better spent on
the long distant charges plus my time is worth something.  Why spend 4 time
as long downloading a file?  Also when I tried to discontinue the service
it took 3 to 4 months for them to stop billing my credit card, another
story.

Dave
From: wtm@uhura.neoucom.edu (Bill Mayhew)
Newsgroups: comp.dcom.modems
Subject: Re: 10 seconds wait to hang up Telebits (was Optimizing Telebits)
Date: 13 Sep 92 14:00:01 GMT
Organization: Northeastern Ohio Universities College of Medicine

It is not the basic S register that is probably the culprit but
more likely the delay imposed by the error control protocol
deciding that the link is down and it's time to bail out.

It looks like the Worldblazer has a multitasking kernel.  I base
that on my observation of the somewhat asynchronous reporting of
DIALING, RING, RRING messages.  It looks like carrier dropping is
is not embedded in the error control task, so the port handler has
to wait for a message to come in from the error control task to
decide it is legal to go ahead to drop the line relay.  Note: this
is speculative based on observing the behavior of the modem, rather
than familiarity with the code, so believe at your own risk.

It would make sense to have a modular multitasking control kernel
in the modem becuase that is in keeping with the planned
extensibility to handle fax and future protocols.

Try picking a different error control protocol.  I'm not in a
convenient palce to experiment right now.... but try changing the
error control from MNP5 to LAP-M or vice versa.  I forget which one
is the better.  I suspect MNP5 is quicker, since it supports
extensions for passing administrative data (e.g. being able to do
AT% commands to the other modem).  Hopefully, the protocol sends a
hang-up message across the link when the other end wants to drop
gracefully -- such as DTR going low, + + + ATH0 or whatever.

--Bill

-- 
Bill Mayhew      NEOUCOM Computer Services Department
Rootstown, OH  44272-9995  USA    phone: 216-325-2511
wtm@uhura.neoucom.edu   (140.220.1.1)
Newsgroups: comp.dcom.modems,comp.unix.sysv386,comp.protocols.misc,biz.comp.telebit
From: okabe@unixg.ubc.ca (Ian Okabe)
Subject: file transfers with USRobotic Sportster 14.4K 
Organization: University of British Columbia, Vancouver, B.C., Canada
Date: Sun, 6 Sep 1992 05:55:31 GMT

Being a neophyte I am having difficult transfering files with my new
14.4K Sportster. I can log on ok to the remote modem at high speed,
but when I try to transfer any file (text or binary) using kermit, xmodem,
or ymodem (built in to the Versaterm comm program) it seems to choke.
What kind of initialization string do I need? Right now I just use the
default AT&B1&H1
By the way its a Powerbook if thats any use logging in to a unixg box.
Thanks in advance.
-- 
Ian T. Okabe (okabe@unixg.ubc.ca)
Atmospheric Sciences, University of British Columbia, Vancouver, Canada
Newsgroups: comp.dcom.modems
From: winslade@cwis.unomaha.edu (John Winslade)
Subject: What exactly is the v.32 'buzz saw' ??
Keywords: v.32
Organization: University of Nebraska at Omaha
Date: Thu, 10 Sep 1992 14:21:56 GMT

Here's a question I was asked last night and I had to admit that I just
did not know.

When two v.32 modems connect, occasionally (more often than not on long
lines) the hissing and screeching will turn into a very distinct 'buzz'
for a second or two.  I'm sure most of you have heard this.
 
Does anyone know what is happening when this occurs ??    A guess would
be that it has something to do with the echo cancellation, since it seems
to happen mostly with long-distance connections.
 
Anyone know for sure ??
 
Thanks      Good day       JSW

Newsgroups: comp.dcom.modems,comp.unix.sysv386,comp.protocols.misc,biz.comp.telebit
From: anton@analsyn.gts.org (Anton J Aylward)
Subject: Re: uucico w/v32bis vs zmodem w/v32bis
Organization: ASCI: UNIX Database and Communications
X-Newsreader: Tin 1.1 PL4
Date: Sun, 6 Sep 1992 20:30:25 GMT

larry@gator.rn.com (Larry Snyder) writes:
: gert@greenie.ucrc.sub.org (Gert Doering) writes:
: 
: >anton@analsyn.gts.org (Anton J Aylward) writes:
: 
: >>"If Z-modem is so good, why not tell us how to put a plug-in replacement
: >> for UUCP based on Z-Modem, which interfaces to news and mail in just
: >> the same way....."
: 
: >Various people are working on a Z-Modem-like protocol for Taylor-UUCP.
: 
: regular zmodem doesn't do so how with todays high speed modems with
: DTE speeds > 38400.  For example, with my TurboPEP modems, zmodem maxes
: out at around 2100 cps while ymodem-g can exceed that.  What we need is
: a large packet zmodem (like Wazoo -- from Fidonet) with 8K packets to
: take advantage of todays modems and 115200 baud DTE speeds

I'll ask again.... any ideas about plugging zmodem in as a dial-in
replacement for UUCP?  Not as "another"  UUCP protocol, but a bit of
encapsulation with C or shell.

Main problem is that while I can set up a "BBS" interface, or even a 
login that drops you straight in to zmodem, the beauty of UUCP is that
it is fully autonomous - the C. D. and X. remove the need for human
intervention.  Its not just upload-download.  The X. can say to ram the
D. through rmail/rnews etc.  

The other alternative, which I discussed briefly with perher h. once but
never did anything with, is to have dynamicaly extendable protocol
suites.  Imagine the upper layes of uucuci being a collection of
{shell,perl} scripts and there being a set of programs "g", "f", "x" "t"
(etc) which get called at a lower level to do the work:

	/usr/lib/uucp/protocols/g/cico [-t n] [-x n] [-r 0|1] C.files.....

and so on.

This would make applying upgrades to protocols easier... and alalow
people to experiment with new protocols without having to have all of
the rest of the program to worry about.

In fact the upper layers can be divided up like this too.  
All the classical justifications about visibility and maintainability
apply.  LRUs for upgrades, changes, enhancements, logging...

Ian, are you listening ?
--
Anton J Aylward
From: cary@aurora.Colorado.EDU (John R. Cary)
Newsgroups: comp.dcom.modems
Subject: Modem failure to negotiate through campus switches
Date: 15 Sep 92 05:12:08 GMT
Organization: University of Colorado, Boulder

I have recently purchased two TwinCom 14400 (v.32bis, v.42bis) modems, one
to use on my Mac II at home through Versaterm and System 7, the other
attached to an IBM RS6000/220 running AIX3.2 at work.  Both system
are set to run rts/cts.

I have continually had problems making the connection.  Roughly 1/4 of the
time the two modems find the proper protocol (after the second tone) and
begin communicating at 14400 bps.  The rest of the time they beep
at each other until they give up and disconnect.

My home modem has no problem connecting to a US Robotics on another line.
When I am on campus (inside the phone switches) I have no problem makeing
the modem to modem connection with these same two modems.

So I am beginning to suspect the phone line onto the campus..  The response
of our wonderful Telecom Department was to call up the line, say "Can
you hear me?"  After hearing yes, he said, "All we guarantee is voice
communication."

My question: How can I check for data quality?  What other mysteries
of phone technology might be interfering with my modems?

Thanks...John Cary
-- 
--------------------------
John R. Cary                                  cary@boulder.colorado.edu
Department of Astrophysical, Planetary and Atmospheric Sciences
University of Colorado, Boulder, CO 80309-0391
ph. (303) 492-1489                                   fax (303) 492-0642
From: tnixon@hayes.com
Newsgroups: comp.dcom.modems
Subject: Re: v.fast
Date: 8 Sep 92 13:16:54 EDT
Organization: Hayes Microcomputer Products, Norcross, GA

In article <gk9JqB1w164w@uuisis.isis.org>, evanc@uuisis.isis.org
(Evan Champion) writes: 

> Is there some way to find out about what goes on at these meetings (ie: 
> minutes or something of the sort) or are they fairly "closed"?  I would like 
> to find out atleast about the options that the comittee is debating over.

Generally, guests are permitted to observe meetings, although
participation is usually limited to members of the sponsoring
organization. Minutes are kept, and are available if you can find
someone to copy them for you. In this case, the best source for
information is probably Communications Standards Review, a
newsletter on modem, fax, and digital cellular standards committee
activities.  CSR has the actual minutes available (as well as copies
of all documents presented at the meetings), and also publishes
summaries of the meetings in the newsletter.  Unfortunately, it's
not cheap; I think their current subscription rate is around $700
per year.  But that's a lot cheaper than going to even one meeting
in person! 

For more information on CSR, contact them at +1-415-856-9018 voice, 
+1-415-856-6591 fax, or kkrechmer@attmail.com.

-- 
Toby Nixon, Principal Engineer      | Voice   +1-404-840-9200  Telex 401243420
Hayes Microcomputer Products, Inc.  | Fax     +1-404-447-0178  CIS   70271,404
P.O. Box 105203                     | BBS     +1-404-446-6336  AT&T    !tnixon
Atlanta, Georgia  30348             | UUCP uunet!hayes!tnixon  Fido   1:114/15
USA                                 | Internet                tnixon@hayes.com