[comp.windows.ms] It looks like a flow control problem with Win3

cids05@vaxa.strath.ac.uk (@Dr Stephen K Tagg@) (02/05/91)

In article <606@twg.bc.ca>, bill@twg.bc.ca (Bill Irwin) writes:
> I have configured a Non-windows application to Win3 as the
> execution of a communication program, TERM (from Century
> Software).  TERM has been told to use Xon/Xoff terminal
> handshaking.  I have configured, through the Control Panel, COM1
> to be 19,200bps with Xon/Xoff.
> If I terminate Win3 before running TERM it will connect and run
> at 19200 perfectly.  It seems that having the data flow from the
> Xenix port, through TERM communications program, through Win3 to
> the monitor is causing flow control problems when Win3 is part of
> the route.
> 
> Anyone have any config ideas that I have missed?

Maybe no help, but winqvt runs fine at 19,200 to our vax, unless I try to
send files via Kermit. Then I have to revert to 9600. I just imagined it was a
limit to the effective baud rate somewher in windows....

DLB@psuvm.psu.edu (Dan Bernitt) (02/06/91)

No help but the same problem with a different program.  I still use YTERM, an
emulation program from Yale, to connect to a host computer running VM/CMS.  It
has a modest script language that allows embedding a logon procedure (starting
with loading the emulator, dialing the number, etc.) in a BAT file.  I have
almost no luck running the BAT file in enhanced mode.  Works fine in standard
mode but the script part that carries out the interaction with the modem and
the connecting data switch invariably gets interrupted and fails.  I can then
continue the logon process manually and have no further trouble either with the
rest of the procedure or with the CMS session once I get connected.

It appears that Windows preemptively interrupts the admittedly non-robust
script program.  Haven't tried changing all the possible parameters but the
XON/XOFF doesn't help.  I'll still do a bit more checking but will appreciate
any other insights.