snyde_sl@tsca02.uucp (Steve Snyder) (05/25/91)
Our site recently established a newsfeed. We are running C news (last patch date is 24-Mar-91) and rn (last patch date is 01-Jan-91, # 54) on an Apollo DN3000 under Domain/OS SR10.2 (sys 5.3 environment). The ASCII terminals we have are connected to Black Box terminal servers. The problem we are having concerns using rn over a telnet or rlogin connection to the news server. It seems that regardless of what type of terminal (VT100, VT320, PC, SUN SPARC2, HP9000/380, or even another Apollo bitmap display) I use to telnet to the news server, this problem occurs. The problem is that rn repeatedly displays the first '--read now? [npq]' prompt (beeping every time) as shown below: Unread news in comp.ai 34 articles Unread news in comp.ai.edu 3 articles Unread news in comp.ai.neural-nets 38 articles Unread news in comp.ai.shells 4 articles Unread news in comp.arch 128 articles etc. ******** 34 unread articles in comp.ai--read now? [ynq] Type h for help. ******** 34 unread articles in comp.ai--read now? [ynq] Type h for help. ******** 34 unread articles in comp.ai--read now? [ynq] Type h for help. ******** 34 unread articles in comp.ai--read now? [ynq] Type h for help. So I just have to quit and get out of rn. This problem with rn does not occur on Apollo bitmap displays that access the news server through the Domain file system. (I have symbolic links set up from all of our other Apollos to the necessary files and directories on the news server.) Although from these workstations I can generate the same response by typing control characters that rn does not accept. As far as I can determine there are no control characters being sent by the remote terminal. (I have saved a terminal session in a file and done a hex dump of this file.) The readnews reader (distributed with C news) works fine from remote terminals over telnet, but I'd really like to give every user the ability to use rn from any remote terminal or workstation. I believe that rn is running in curses cbreak mode at the above prompt, whereas readnews is probably not. Any ideas why rn responds this way over a telnet connection, or possible solutions to this problem? I've run out of ideas. I posted this previously to news.software.b and news.newusers.questions but got no responses. Should I be using rrn and NNTP? (I answered no to Configure's "Do you want this built as remote rn (rrn)?" question.) Does rrn let you run rn over a telnet connection to a news server? I'd prefer responses by email, but I'll continue to watch the newsgroups where I posted this if you'd rather post a reponse for the benefit of others who might have a similar problem and questions. Thanks. -- Steve Snyder | You've got to know when to code 'em, Electronic Data Systems | know when to modem, know when to load 'em, snyde_sl@otsc.eds.com | and know when to run. uunet!tsca02!snyde_sl | --Anonymous
kevin@cfctech.cfc.com (Kevin Darcy) (05/30/91)
In article <1991May24.212235.8187@otsc.eds.com> snyde_sl@tsca02.uucp (Steve Snyder) writes: >Our site recently established a newsfeed. We are running C news (last >patch date is 24-Mar-91) and rn (last patch date is 01-Jan-91, # 54) >on an Apollo DN3000 under Domain/OS SR10.2 (sys 5.3 environment). >The ASCII terminals we have are connected to Black Box terminal >servers. > >The problem we are having concerns using rn over a telnet or rlogin >connection to the news server. It seems that regardless of what type >of terminal (VT100, VT320, PC, SUN SPARC2, HP9000/380, or even another >Apollo bitmap display) I use to telnet to the news server, this >problem occurs. The problem is that rn repeatedly displays the >first '--read now? [npq]' prompt (beeping every time) as shown below: > > [example given] > >So I just have to quit and get out of rn. [further details] > >Any ideas why rn responds this way over a telnet connection, or >possible solutions to this problem? I've run out of ideas. I posted >this previously to news.software.b and news.newusers.questions but got >no responses. We've seen identical behavior from rn and trn over AT&T Starlan connections on 3B2's. My guess is that the pty driver used by your telnetd is based on STREAMS, and the rn/trn code is known to not handle STREAMS-based tty drivers quite correctly in O_NDELAY mode. Specifically, the code doesn't respect the following critical distinction (this is a quote from the read(2) section of a vendor manual): When attempting to read a file associated with a tty has no data currently available: If O_NDELAY is set, the read will return 0. [...] When attempting to read a file associated with a _stream_ that has no data currently available: If O_NDELAY is set, the read will return a -1 and set errno to EAGAIN. We have a local hack that works around this problem. I can send it to anyone who is interested. Followups to news.software.b and/or comp.unix.programmer. >Steve Snyder | You've got to know when to code 'em, >Electronic Data Systems | know when to modem, know when to load 'em, >snyde_sl@otsc.eds.com | and know when to run. >uunet!tsca02!snyde_sl | --Anonymous ------------------------------------------------------------------------------- kevin@cfctech.cfc.com | Kevin Darcy, CFC Unix Systems Administrator ...sharkey!cfctech!kevin | MIS/Technical-Services/Distributed-Systems Voice: (313) 759-7140 | Chrysler Corporation Fax: (313) 758-8173 | 25999 Lawrence, Center Line, MI 48015 -------------------------------------------------------------------------------