🚀 go-pugleaf

Some IACs don't support hardware flow control (IAC8?) so you can set characetristsicsa until you're blue in the face and it makes no difference whatsoever.
---


Regards,

Hugh.
------------------------------------------------------------------
I don't speak for Xerox, nor they for me.

Rank Xerox European Systems Centre, Welwyn Garden City, Herts., UK.
Mail to; Huge.wgc1@rx.xerox.com, whatever it says in the header.

In article <1992Nov9.114616.18566@spectrum.xerox.com>, hdavies@rx.xerox.com 
(Hugh J.E. Davies) writes:
> Some IACs don't support hardware flow control (IAC8?) ......
> ---


It's been a while but I think Hugh has it backwards.  The IAC-8's are the ones
with "full modem" support and thus do handle DSR/DTR.  I think some of the larger
IAC's (16's and 24's) are "null modem" and thus don't support hardware flow
control.

Tom Green (tomg@code3) wrote:
: We are trying to get hardware flow control going on an AOS/VS II system and
: are having some trouble.  We set the HIFC and HOFC characteristics on the
: con we are using, but it doesn't seem to be using regular rtc/cts signalling.
: We are trying to talk to a SCO unix box.  Anyone have any suggestions which
: pins are really being used, or if we are off base totally in the first place?
: 
: Thanks.

My experience is 6 years out of date, but as I recall the IACs really badly
wanted ALL the hardware protocols implented.  If your cables are not using
pins 1 through 8 and 20, you'll probably have trouble.

Are you running custom programs setting the values at run-time?  If not,
are you setting the DEFAULT characteristics from the console?  I don't
remember the details, just that there is a difference between setting the
char's for the current session, vs. as default...

In article <BxBGB4.84w@hsi.com>, tomg@code3 (Tom Green) writes: 
> We are trying to get hardware flow control going on an AOS/VS II system and 
> are having some trouble.  We set the HIFC and HOFC characteristics on the 
> con we are using, but it doesn't seem to be using regular rtc/cts signalling.
> We are trying to talk to a SCO unix box.  Anyone have any suggestions which 
> pins are really being used, or if we are off base totally in the first place? 

Sorry, I couldn't reply by email. 

Possibly pin 20* (and 6&8) are changing (in some ways this is closer to what
the original RS232 standard expected). But the best idea is to put a break-out
box with LED indicators between the two. Watch not only to see what handshaking
signals change, but whether something is sending an extra byte (XOFF). Is the
problem that the AOS system gets overloaded with input, or the SCO? - Or some
other problem? I had a printer on a DG box which kept getting too many
characters for its input buffer - the problem turned out to be the output
stopped from the DG a few characters after the printer said "please stop". The
moral of the story is that many, many things can be wrong with serial
communications. Expect a re-write of Murphy's Law real soon now, concentrating
on RS232!

* pin numbers refer to a DB25, not what comes out of the side of the mux.

Mark Aitchison, University of Canterbury, New Zealand.
(It's a while since I used AOS/VS - I upgraded to RDOS years ago :-).

mikel@networx.com (Mike Lempriere) writes:

>Tom Green (tomg@code3) wrote:
>: We are trying to get hardware flow control going on an AOS/VS II system and
>: are having some trouble.  We set the HIFC and HOFC characteristics on the
>: con we are using, but it doesn't seem to be using regular rtc/cts signalling.
>: We are trying to talk to a SCO unix box.  Anyone have any suggestions which
>: pins are really being used, or if we are off base totally in the first place?
>: 
>: Thanks.

>My experience is 6 years out of date, but as I recall the IACs really badly
>wanted ALL the hardware protocols implented.  If your cables are not using
>pins 1 through 8 and 20, you'll probably have trouble.

>Are you running custom programs setting the values at run-time?  If not,
>are you setting the DEFAULT characteristics from the console?  I don't
>remember the details, just that there is a difference between setting the
[...]

Well it need not be the console...
Having the System Manager priv, you can set default CHARs from any
Terminal. ( Dont forget do dis/enable the console you set the characteris-
tics of... )
Turning on the SysMgr attribute :
:CLI32    PRIV SYS ON
:CLI16    JPI something
          ( Ignore the error message. the "something" should be written
            as <something>, which is anything except a valid JP-id.
            Feel free to put four letter words there... )
  Jens

v
>char's for the current session, vs. as default...