Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!UMIX.CC.UMICH.EDU!hyc
From: hyc@UMIX.CC.UMICH.EDU (Howard Chu)
Newsgroups: comp.sys.atari.8bit
Subject: OmniCom Kermit Troubles
Message-ID: <8612171830.AA20961@umix.cc.umich.edu>
Date: Wed, 17-Dec-86 13:30:41 EST
Article-I.D.: umix.8612171830.AA20961
Posted: Wed Dec 17 13:30:41 1986
Date-Received: Thu, 18-Dec-86 07:07:01 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 23

Summary of problem - with OmniView, OmniCom, and P:R Connection running
with the "standard" RS232 device handler, Kermit uploads hang OmniCom.

Mediocre solution - use PRC.SYS instead of the 850 RS232 handler.

Gripes - the 850 RS232 handler signals when its buffer overflows, allowing
OmniCom to send an XOFF until it catches up. The PRC.SYS does not. This is
usually not a problem, but I also run OmniCom over a 9600 baud line, and
it becomes pretty important then. The display seems to max out at about 2700
baud, so buffer overflows mean garbled text. With the 850 handler, the XOFF
takes care of things just fine. With PRC.SYS, I get a mess. And, of course,
with the 850 handler, I can only receive files, whereas the PRC.SYS will
allow both sending and receiving with no problem. This seems to only be a
problem with OmniCom and the 850 handler, I don't recall it happening with
the PD Kermit.

I'm curious, Dave, what is it about OmniCom that makes it so incompatible
with the P:R Connection? The initial version wouldn't work at all without
PRC.SYS, while the version I got recently works "most of the time..." (I'm
also curious as to what you used to write it; the load vectors for that
thing are horribly inefficient!)
  -- Howard Chu
	hyc@umix.cc.umich.edu