Path: utzoo!utgpu!water!watmath!clyde!rutgers!im4u!ut-sally!husc6!hao!oddjob!gargoyle!ddsw1!igloo!jjw
From: jjw@igloo.UUCP (John Welch)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Background file transfer WANTED
Summary: The CORRECT way to do it
Message-ID: <359@igloo.UUCP>
Date: 14 Jan 88 23:59:18 GMT
References: <2341@cup.portal.com> <804@pilchuck.Data-IO.COM>
Reply-To: jjw@igloo.UUCP (John Welch)
Organization: igloo, Northbrook, IL
Lines: 25

In article <804@pilchuck.Data-IO.COM> jgray@toad.pilchuck.Data-IO.COM (Jerry Late Nite Gray) writes:
>I suspect there may be a basic problem with background file transfers in that
>you would have to be very carefull about what you are running in the foreground
>and the TSRs you have active. The luxury of background file transfers might
>have to be paid for with a low bandwidth (read set port to 4800 baud or less)
>transfers. I can just see VMUSIC being run during background file transfers.
>
>Any comments anyone?

Well, you're right about being careful about TSRs. Some of them are downright
HOSTILE to the system. However, for protocol transfers, if the program running
in background is interrupt-driven and has a fairly sizable buffer (as does 
BackComm, which I wrote part of) you can run as fast as you want. The CPU
time for BC is configurable, and at 2400 baud in background the throughput goes
down slightly, and the keyboard response lags (sometimes by 2 characters) but
it runs.
	The thing is, use a program that's INTERRUPT driven and MADE to work
in background, and not something written in BASIC that polls INT 14 for its
input.

-- 
==========================================================================
  John Welch                             ..{codas,ihnp4}!ddsw1!igloo!jjw
  "I will not be pushed, filed, stamped, indexed, briefed, de-briefed or
   numbered. My life is my own; I am a free man!" - #6