Path: utzoo!utgpu!watserv1!watmath!att!att!pacbell.com!mips!bridge2!jarthur!nntp-server.caltech.edu!gumby.cs.caltech.edu!newton
From: newton@gumby.cs.caltech.edu (Mike Newton)
Newsgroups: comp.sys.m88k
Subject: A question about IO under DG/UX
Summary: Does anything work?
Keywords: buffering, IO, RTS, SysV, ioctl, BSD
Message-ID: <newton.659014534@gumby.cs.caltech.edu>
Date: 19 Nov 90 11:35:34 GMT
Sender: news@nntp-server.caltech.edu
Organization: California Institute of Technology, Pasadena
Lines: 49
Nntp-Posting-Host: gumby.cs.caltech.edu



This may be a general SysV / BSD question, but for now i'll try just asking
this list.  On DG/UX 4.30 i would like to 

	[1] have two open file descriptors (numbers unimportant):
		#1 : opens (for writing) the ttypN side of a pty/tty pair
		#2 : opens (for reading) /dev/tty01

	[2] i do not want _any_ character interpretation on either line.
		(ie: 'raw' mode is great, but 'cbreak' with all special
		 processing characters turned off is also ok.  equiv is
		 true of ATT mode).


	[3] i dont care if i have to use SysV semanics or BSD, though
		i prefer BSD.

Now comes the hard part:

	[4] when (system) buffers fill up i want the IO to stop.
		 ie: if  what is on 'tty01' is sending characters
		 too fast, i'd like the terminal driver to de-assert
		 (turn off) RTS until there is buffer space. i dont
		 want ^g (bells) as one normally gets in BSD cooked mode.

		 Additionally, i'd like something similar for
		 the pty pair.

Is this possible?  I've tried many ways, all w/o luck.
I know that I can peek at the number of chars that the system thinks
is in the buffer, but at 19200, i'd rather not do the extra context
switching.

Many thanks,
- mike (newton@gumby.cs.caltech.edu)


ps: has anyone actually played with the modem signal lines as defined
in the DG/UX /usr/include/sys/_int_bsd_tty_ioctl.h ?  
(ex: TIOCCBRK	(clear break cond.),  TIOCM_LE (line enabled)
     TIOCM_DTR (data terminal ready), TIOCM_RTS (request to send)...??)
If so, how'd you do it????


ps: i've (w/ help from a friend) written a replacement for 'cu' on DG/UX.
It runs a little faster/more reliably, and can actually send (ok: fake)
breaks (the DG version doesnt seem to do this!).  But even with all this
I need to have hardware flow control in order to hope to run at 19200.