a_dent@mail.uwa.oz (05/13/88)
We run a moderate sized network of CASE muxes off DECServer 200's
DECSserver 200 - DCX840 ------ DCX840 ----- local term/print
------ DCX840 ----- DCX825 ----- local term/print
----- DCX815 --- local
etc...
We have had no problems with flow control until the problems with LATSYM
started and I think they are more due to software bugs.
The CASE documentation is LOUSY but there are a couple of "course notes" type
documents that you may be able to obtain that clear things up:
DCX: What you always wanted to know ...
DCX ADVANCED (course notes)
Basically, the mux has two forms of flow control, set by the SYSTEM OPTIONS
NOTE that it allows you to define XON/XOFF as either DC1/DC2 or DC1/DC3.
The standard (as used by DEC) is DC1/DC3.
BOP flow control is Buffer Overflow Protection and enables the MUX to protect
it's buffers against an external source (cpu or terminal).
TFC flow control is Terminal Flow Control and makes the MUX respond to local
flow control exerted by the external device (ie: you don't have to wait for
your XON/XOFF to get all the way back to the Host cpu).
The usual setup is:
CPU end: BOP = DC1/DC3, TFC disabled
terminal/printer BOP disabled, TFC = DC1/DC3
However, if you are doing uploads from PC's to/from the host you may need to
set BOP & TFC = DC1/DC3 at both ends!
NOTE: The flow control characters are handled as in-band characters which
means they aren't picked out of the data-stream by the mux but sit behind all
the other characters. Thus, you can sometimes get the XON stuck behind a load
of data, in a buffer that has been XOFFED and the link is STUCK !!!!!
Luckily, the port reset is handled out-of-band so will clear the problem, in
extreme cases may need to reset port at both ends.
Hope this helps:
Andy Dent | Username A_DENT
VAX Operations Controller | MAILVAX
Griffin Coal Mining | University of Western Australia
28 The Esplanade |
Perth 6000 |
Western Australia |