Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.PCS 1/10/84; site mtuxo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!houxm!mtuxo!hfavr
From: hfavr@mtuxo.UUCP (a.reed)
Newsgroups: net.unix-wizards
Subject: Re: Testing XMODEM programs
Message-ID: <1402@mtuxo.UUCP>
Date: Wed, 12-Mar-86 14:50:36 EST
Article-I.D.: mtuxo.1402
Posted: Wed Mar 12 14:50:36 1986
Date-Received: Fri, 14-Mar-86 05:13:26 EST
References: <191@decvax.UUCP>
Organization: AT&T Information Systems Labs, Holmdel NJ
Lines: 29

> How does one go about testing the various XMODEM programs, such as
> "xm", "UMODEM", and "YMODEM"?  Some people have told me that you simply
> ask a friendly CP/M user to dial into your system and see if he can do
> up/downloads.  There's got to be a better way than that.
> 
> For instance, I'm using a VAXStation II/GPX running MIT's 'X' windows under
> Ultrix-32.  It seems like it should be possible to set up two terminal
> emulator windows that run the XMODEM programs talking back to back to each
> other via pseudo tty's.  I've tried various combinations of re-directed
> stdin and stdout for the programs, but none gives the desired results.
> Does anyone have any ideas?
> 
> Mike Gancarz
> Ultrix Engineering Group
> Merrimack, New Hampshire 03054
> decvax!gancarz
> +---------------------------------------------------------------------------+
> + My hacking is not to be construed as a commitment by my employer, etc.    +
> +---------------------------------------------------------------------------+

I was faced with the same problem when developing the modem-protocol
upload-download capability for AT&T MAIL. I solved it by adding the
	~+ cmd
transmit-process command to cu. This disables the receive-process,
executes cmd with stdio to and from remote, and re-enables the
receive-process on termination of cmd. The current version of cu,
as distributed with HDB, includes ~+ although it is not documented
except in the source.
			Adam Reed (ihnp4!npois!adam)