[comp.dcom.modems] Transferring files using sz/rz between Microcoms V.32 modem

Gary_Edmunds_Miller@cup.portal.com (09/18/89)

 Ralph E. Yozzo  wrote:
>Has anyone been successful 
>transferring files using sz/rz between Microcoms V.32 modems 
 
No problems! I do it all the time.  Could you be more specific
about your problem? 
..
RGDS
GARY

yozzo@arnor.UUCP (Ralph Yozzo) (09/20/89)

For anyone that is interested, 
(many thanks to Jacob Parnas), Jacob and I 
got the Microcoms transferring files correctly. 
 
There was a number of things that we did: 
 
 - We SET XON/XOFF off  ( this screws up Zmodem ) 
 - We log on at N,8,1   ( E,7,1 screws up Zmodem ) 
 - We got the latest copy of sz and rz from uunet. ( the old rz was screwed up ) 
 
Here are some observations: 
 - Logging on at 38400, we get up 2500 CPS when transferring large files. 
 
Here are some questions: 
 - We tried adding Hardware Serial Flow (AT\Q3) bidirectional Hardware serial 
   flow.  We thought this would speed up the transfer since Zmodem 
   transfers with serial flow control OFF, causes Zmodem to 
   do a lot of error correcting when the buffers overflow. 
 
   Well, to make a long story short, (AT\Q3) bidirectional Hardware serial 
   flow causes Zmodem file transfers to fail. 
 
   Does anyone have any ideas why 
    "(AT\Q3) bidirectional Hardware serial 
     flow causes Zmodem file transfers to fail." ? 
 
 - Does anyone know of an OS/2 communications program 
   that supports 38400 baud? 
 
 
The following is a configuration that works: 
 
MODEM BPS      9600   AT 
MODEM FLOW     OFF    AT\G0 
MODEM MODE     AUT    AT\N3 
AUTO ANS       ON     ATS0=1 
SERIAL BPS     9600   AT 
BPS ADJUST     OFF    AT\J0 
SERIAL FLOW    OFF    AT\Q0 
PASS XON/XOFF  OFF    AT\X0 
PARITY         7E     AT 
INDP S/M SPD   OFF    AT%G0 
 
 - STRIKE ANY KEY TO CONTINUE - 
 
BREAK          5      AT\K5 
EXIT CHAR      043    ATS2=43 
CMD ECHO       ON     ATE1 
RESULTS        OFF    ATQ1 
RESULT TYPE    MNPL   ATV1\V1 
CONN MNP-      OFF    AT-M0 
DATA ECHO      OFF    AT\E0 
INACT TIMER    00     AT\T0 
AUTO RETRAIN   ON     AT%E1 
FALLBACK       0      AT-Q0 
COMPRESSION    ALL    AT%C3 
MAX BLK SIZE   256    AT\A3 
AUTO BUFF      0      AT\C0 
AUTO CHAR      000    AT%A0 
 
 - STRIKE ANY KEY TO CONTINUE - 
 
EMULATING HP   OFF    AT\H0 
PAUSE TIME     002    ATS8=2 
DTR            2      AT&D2 
CARR DET       1      AT&C1 
DSR            0      AT\D0 
RING IND       1      AT\R1 
SPKR CTRL      1      ATM1 
DISC DELAY     000    AT%D0 
REM CHAR       042    AT*S42 
REM ENABLE     OFF    AT*E0 
REM SEC        OFF    AT*R0 
LEASE LINE     OFF    AT&L0 
 
 - STRIKE ANY KEY TO CONTINUE - 
 
SIM RING       0      AT:R0 
CD DELAY       000    AT:U0 
CTS DELAY      000    AT:V0 
DSR DELAY      000    AT:X0 
ASYNC/SYNC     0      AT&M0 
CTS/RTS        ON     AT&R0 
RDLB ENABLE    ON     AT&T4 
DIAL MODE      4      ATX4 
PULSE DIAL     US     AT&P0 
GUARD TONE     0      AT&G0 
PAR CHK        0      AT-P0 
MANUAL DIAL    OFF    AT:D0 
BELL           ON     ATB1 
EQUALIZER      ON     AT:E1 
SPEED MATCH    1      AT%L1 

------------------------------------------------------------------------------
| Ralph E. Yozzo                     | DISCLAIMER: The opinions expressed    |
| IBM Thomas J. Watson Research Ctr. | herein are the Authors.               |
| Arpanet: yozzo@ibm.com             | And are not necessarily those of his  |
|                                    | employer.                             |
| Bitnet: yozzo@yktvmx.bitnet        \---------------------------------------|
| Home: ..!uunet!bywater!acheron!larouch!yozzo  | Phone: (914) 945-3634 work |
|                                               | Phone: (914) 564-4731 home |
------------------------------------------------------------------------------

Gary_Edmunds_Miller@cup.portal.com (09/21/89)

>For anyone that is interested, 
>(many thanks to Jacob Parnas), Jacob and I 
>got the Microcoms transferring files correctly. 
> There was a number of things that we did: 

>- We SET XON/XOFF off  ( this screws up Zmodem ) 
No, Xmodem/Ymodem need this but NOT Zmodem.

>- We log on at N,8,1   ( E,7,1 screws up Zmodem ) 
This is always a good idea.

>- We got the latest copy of sz and rz from uunet.(the old rz was screwed up ) 
Also a good idea to have the latest software before complaining!
 
>- Logging on at 38400, we get up 2500 CPS when transferring large files. 
What sort of files? Data, text, compressed? What sort of host?
 
>   We thought this would speed up the transfer since Zmodem 
>  transfers with serial flow control OFF, causes Zmodem to 
>  do a lot of error correcting when the buffers overflow. 
Obviously, if you disable XON/XOFF *and* hardware flow control, then
your COMM software had better be GREAT to handle 2500cps!!
 
>  Well, to make a long story short, (AT\Q3) bidirectional Hardware serial 
>  flow causes Zmodem file transfers to fail. 
No, I ALWAYS have AT\Q3, and never have a problem.  Maybe your TTY driver
is sick?
 
>- Does anyone know of an OS/2 communications program 
>  that supports 38400 baud? 
OS/2, TOPVIEW for the '90s!  Try ZCOMM/PRO-YAM under DOS. 
 
RGDS
GARY

Geoffrey.Welsh@p0.f171.n221.z1.fidonet.org (Geoffrey Welsh) (09/21/89)

 > From: yozzo@arnor.UUCP (Ralph Yozzo)
 > Message-ID: <402@arnor.UUCP>
 
 >    Does anyone have any ideas why
 >     "(AT\Q3) bidirectional Hardware serial
 >      flow causes Zmodem file transfers to fail." ?
 
   Ideas, yes. Answers, no. It could be that your hardware - or the device 
drivers - simply don't support it, or that their configuratrion would require 
substantial revision (when I plugged a TrailBlazer Plus into an AT&T 3B4000 on 
a lark a few weeks back, I had to make a few "adjustments" to the TB's config 
to make up for what the 3B4000 WASN'T doing with the port...)
 
 >  - Does anyone know of an OS/2 communications program
 >    that supports 38400 baud?
 
   Colin Sampaleanu (author of Telix) was told not to expect anything over 
4800 bps to work reliably under OS/2. I suspect that this was a worst case 
scenario, probably assuming a 286 and that a compatability box would be 
running at the same time and introducing the old 286 mode-switching fun...



--  
Geoffrey Welsh - via FidoNet node 1:221/171
UUCP: {{uunet!}watmath!xenitec!}zswamp!171.0!Geoffrey.Welsh
ARPA: Geoffrey.Welsh@p0.f171.n221.z1.fidonet.org