acc@virginia.acc.virginia.edu (ACC) (12/03/88)
my local UNIX mainframe, and from there to m PC. For anybody
else who has the same problem, the procedure is this:
From: lhb6v@watt.acc.Virginia.EDU (Laura H. Burchard)
Path: watt.acc.Virginia.EDU!lhb6v
ftp to SIMTEL20
set filetype to tenex (just type 'tenex')
get files
exit ftp
make sure that your modem is set to 7E1.
set kermit file type to binary (on both PC and mainframe)
send files to PC
if you cannot connect to the mainframe at 7E1
set kermit file type to binary
send files
wait for burst of noise that indicates kermit is sending
switch modem setting to E71
when file is finished, switch ettings back to 8n1
Laura
Laura Burchard
lhb6v@virginia.edu
Other pathways too, I just haven't figured them out yet.
Cute little quote under construction. holtz@odin.ucsd.edu (Fred Holtz) (12/03/88)
In article <1383@virginia.acc.virginia.edu> lhb6v@watt.acc.Virginia.EDU (Laura H. Burchard) writes: >my local UNIX mainframe, and from there to m PC. For anybody >else who has the same problem, the procedure is this: > >ftp to SIMTEL20 >set filetype to tenex (just type 'tenex') >get files >exit ftp >make sure that your modem is set to 7E1. >set kermit file type to binary (on both PC and mainframe) >send files to PC > This procedure will work, but sending a file using binary kermit is slower than uuencoding the file, sending it via text kermit, then uudecoding on the PC side. The uuencoding increases file size about 50%, but it has been my experience that binary kermit file transfers are > 90% longer than text mode transfers. I don't know why kermit has such a large overhead for binary file transfers; any kermit gurus out there that can clue me in?? Fred Holtz holtz@sdcsvax.ucsd.edu --or-- sdcsvax!holtz (last week anyway :-)
ttp@beta.lanl.gov (T T Phillips) (12/08/88)
In article <5616@sdcsvax.UCSD.EDU>, holtz@odin.ucsd.edu (Fred Holtz) writes: > In article <1383@virginia.acc.virginia.edu> lhb6v@watt.acc.Virginia.EDU (Laura H. Burchard) writes: > >my local UNIX mainframe, and from there to m PC. For anybody > >else who has the same problem, the procedure is this: > > > >ftp to SIMTEL20 > ... > > This procedure will work, but sending a file using binary kermit is slower > than uuencoding the file, sending it via text kermit, then uudecoding on > the PC side. The uuencoding increases file size about 50%, but it has been > my experience that binary kermit file transfers are > 90% longer than text > mode transfers. I don't know why kermit has such a large overhead for binary > file transfers; any kermit gurus out there that can clue me in?? I have had the exact same experience, but I always assumed the slow transfers had something to do with the elaborate multiplexing, encryption, decryption, de-multiplexing link up that our communications go through. Perhaps the slow transfer is a characteristic of all error checking protocols. The uuencoding-ascii transfer scheme works great for downloads, but I haven't been able to find an equivalent scheme for uploading. It would be very nice to have a small unix routine that would set up a large memory buffer area to accept high speed uploads of ascii files. I know that if I try to upload this way into a text editor, I quickly overload the input buffer and start losing characters. Obviously this would only work for highly reliable links, but that would be fine for me. I think that at least 99% of the binary files that I download as uuencoded ascii arrive perfectly. Does anybody out there have an uploading program such as I described? Terry Phillips Los Alamos National Laboratory ttp@beta.lanl.gov
bobmon@iuvax.cs.indiana.edu (RAMontante) (12/08/88)
You might try using zmodem/ymodem protocols for host-to-pc transfers. Doesn't require uuencoding, and I routinely get better than 230 chars/sec at 2400bps. Unix systems should have the rz/sz program. For a PC, procomm supports ymodem, I think pibterm does, dsz and zcomm both support zmodem.
pjh@mccc.UUCP (Pete Holsberg) (12/09/88)
In article <15632@iuvax.cs.indiana.edu> bobmon@iuvax.UUCP (RAMontante) writes:
=You might try using zmodem/ymodem protocols for host-to-pc transfers.
=Doesn't require uuencoding, and I routinely get better than 230
=chars/sec at 2400bps.
=
=Unix systems should have the rz/sz program. For a PC, procomm supports
=ymodem, I think pibterm does, dsz and zcomm both support zmodem.
My understanding is that DSZ is not a stand-alone progarm but must be
invoked by something like ProComm or Boyan as an external protocol.
Also, I was under the impression that it was not possible to transfer
files with DSZ on a PC and SZ/RZ on a Unix computer. Have you done
this? If so, what does it entail?
Pete
--
Pete Holsberg UUCP: {...!rutgers!}princeton!mccc!pjh
Mercer College CompuServe: 70240,334
1200 Old Trenton Road GEnie: PJHOLSBERG
Trenton, NJ 08690 Voice: 1-609-586-4800ttp@beta.lanl.gov (T T Phillips) (12/10/88)
In article <15632@iuvax.cs.indiana.edu>, bobmon@iuvax.cs.indiana.edu (RAMontante) writes: > You might try using zmodem/ymodem protocols for host-to-pc transfers. > Doesn't require uuencoding, and I routinely get better than 230 > chars/sec at 2400bps. My circumstances are a little peculiar in that our line to our Unix mail server passes through a couple of computers, encryptors and decryptors, multiplexers and demultiplexers. All that hardware between us and our Unix machine raises havoc with error correcting packet type protocols. By trial and error, I have found that the largest packet that can be passed reliably is 24 bytes. Larger packets clobber the link and you have to start over. The system is very reliable, however, for ascii transfers at 9600 baud. I get about 700 chars/sec downloading ascii files, but as I mentioned in an earlier posting, I don't have a way to upload ascii characters rapidly. I may try to write something. Incidentally, if I use a telephone link directly to the Unix computer, I can use sz and rz very effectively. I would still like to find a small Unix program that sets up a large buffer and accepts ascii transfers at high speed.
simon@ms.uky.edu (Simon Gales) (12/11/88)
In article <485@mccc.UUCP> pjh@mccc.UUCP (Pete Holsberg) writes:
!
!My understanding is that DSZ is not a stand-alone progarm but must be
!invoked by something like ProComm or Boyan as an external protocol.
!Also, I was under the impression that it was not possible to transfer
!files with DSZ on a PC and SZ/RZ on a Unix computer. Have you done
!this? If so, what does it entail?
!
Well, DSZ can be involked from the command line, or you can call it
from within another program. It also has its own primitive terminal
mode.
My problem is that my dsz and sz/rz won't work together. I gave up
on them long ago, they always have errors and never finish a xfer.
I know this is supposed to work, any ideas on why it won't????
--
/--------------------------------------------------------------------------\
Simon Gales@University of Ky UUCP: {rutgers, uunet}!ukma!simon
Arpa: simon@ms.uky.edu
MaBell: 263-2285/257-3597 BitNet: simon@UKMA.BITNET news@spool.cs.wisc.edu (The News) (12/13/88)
To invoke it from DOS,
dsz CON port 1 speed 2400 d t
will get you going. This will put you on COM1, 2400 baud , disable
carrier detect and put you in terminal mode.
Then, just dial out with ATDTphone number.
From: thaler@speedy.cs.wisc.edu (Maurice Thaler)
Path: speedy!thaler
rz,and sz work fine with it. Personally, I prefer ZCOMM (I actually paid
for it), which is the most ROBUST modem program I have run into, if a
little arcane.
It is perfect for a unix environment.
I often keep a copy of DSZ on a disk I take to consults, so if I need to
use their modem, I know I have a reliable, small modem program with me.
Maurice Thaler SYSOP Audio Projects BBS (608) 836-9473
SYSOP Power Board BBS (608) 222-8842