[comp.sys.ibm.pc.misc] Starlan MS-DOS client doesn't like RN

kherron@s.ms.uky.edu (Kenneth Herron) (02/15/91)

Sorry to post to so many groups; there's no one group devoted to starlan
and there's more than one approach to the problem.

I'm a technical consultant for some academic sites running Sysv/386 3.2, 
scattered over several states.  One of these sites has installed C news
and rn (patchlevel 47, I believe) from installation kits I've put 
together.  Most of the users of this machine use a DOS machine to connect,
via a starlan client.  The DOS starlan software apparently included a
version of kermit which can connect over the network, and a terminfo
description called "kermit" to go with it.

The problem:  Rn works fine from the 6386 console, but goes crazy when
run from a terminal session on one of the DOS systems.  From the
description, it appears that rn sends lots of nulls and possibly other
characters that the DOS end can't handle.  We've tried other terminfo
files, including simple ones like "tty" and "printer"; they all produce
different but no better behavior.  On a couple of tries, rn has acted
as though commands were typed when they weren't, so the DOS end may be
generating false keystrokes as well.  The behavior also changes when they
use -T or -v when starting rn.

They've never seen anything like this with any other software, including
vi.

I know that rn prints a lot of nulls (or some other "nothing" character) 
for some reason when it is between articles; I've seen it happen when 
running rn over a modem.  I suspect this is at least part of the problem.

The last part of the story is that this site is a few states away, and
all I have is e-mail, uucp, and voice telephone between here and there.
Nobody at the site would qualify as a unix wizard, so they won't be able
to solve this problem themselves.  And we don't have a starlan here,
so I don't have much access to starlan documentation.

So, 
1)  Has anyone seen a problem like this?  Better yet, has anyone
    solved it?
2)  Does anyone have a better terminfo for kermit over starlan, or
    can anyone recommend a better client?  Are there possibly some
    settings that can be changed within kermit to improve things?
3)  Is there another news reader available that doesn't try to be
    so cute with the terminal?  I'd like to avoid nn because of the
    database it requires.

If anyone can shed some light on this, I'll thank you, and my children
will thank you, and my children's children will thank you...Seriously,
the (small) CS department at this site is trying to get more students
interested in telecommunicating, but USENET is pretty much useless to
them at the moment.

Please reply to me rather than post; I'll summarize and post if 
anyone else is interested (yeah, right).
-- 
Kenneth Herron                                            kherron@ms.uky.edu
University of Kentucky                                        (606) 257-2975
Department of Mathematics 
                                "Never trust gimmicky gadgets" -- the Doctor

les@chinet.chi.il.us (Leslie Mikesell) (02/15/91)

In article <1991Feb14.174210.5636@ms.uky.edu> kherron@s.ms.uky.edu (Kenneth Herron) writes:
>Sorry to post to so many groups; there's no one group devoted to starlan
>and there's more than one approach to the problem.
>
>I'm a technical consultant for some academic sites running Sysv/386 3.2, 
>scattered over several states.  One of these sites has installed C news
>and rn (patchlevel 47, I believe) from installation kits I've put 
>together.  Most of the users of this machine use a DOS machine to connect,
>via a starlan client.  The DOS starlan software apparently included a
>version of kermit which can connect over the network, and a terminfo
>description called "kermit" to go with it.

>The problem:  Rn works fine from the 6386 console, but goes crazy when
>run from a terminal session on one of the DOS systems.  From the
>description, it appears that rn sends lots of nulls and possibly other
>characters that the DOS end can't handle.  We've tried other terminfo
>files, including simple ones like "tty" and "printer"; they all produce
>different but no better behavior.  On a couple of tries, rn has acted
>as though commands were typed when they weren't, so the DOS end may be
>generating false keystrokes as well.  The behavior also changes when they
>use -T or -v when starting rn.

The problem is on the unix side - the same thing happens if you use
cu to connect over starlan from another unix machine.

The Starlan tty emulation is STREAMS based and returns the STREAMS-flavor
return value from a read() when you have set the O_NDELAY flag and
no data is available.  Personally, I think that when you push the
tty emulation module on a stream you should get the tty-flavor of return
value, but it's been this way for years now.  Apparently the developers
don't read news with rn...
See read(2): return from tty device == 0, streams == -1.

>They've never seen anything like this with any other software, including
>vi.

GNU emacs will do it as well.  

>1)  Has anyone seen a problem like this?  Better yet, has anyone
>    solved it?

The work-around is to check the return value from read for negative
values before trying to use the value as a valid count of returned
characters.  This is straightforward in emacs, but as I recall the
tty read() in rn is hidden in a couple of macros and you either
have to make a new function or use a global variable as a temporary
value.

>3)  Is there another news reader available that doesn't try to be
>    so cute with the terminal?  I'd like to avoid nn because of the
>    database it requires.

As long as you are changing things, you should look at trn,  being
based on rn it will probably need the same fix, but the indexing
really speeds up news reading and the threads database is not as
large as nn requires.

>Please reply to me rather than post; I'll summarize and post if 
>anyone else is interested (yeah, right).

This comes up at least couple of times a year and probably bothers other
people that don't post about it, so I'm posting in hopes that it will
embarass AT&T into fixing the bug in tty emulation.

Les Mikesell
  les@chinet.chi.il.us