A client attempt to transfer files from an Alpha Micro computer to a PC using ZTERM, on the way to their happy future with A-Shell, reports the following:
I am not having much success with ZTXFER. I have programmed and built command files for porting over my clients files from the Alpha to a Win7 Pro workstation using the ZTXFER program. Major issues. It runs exceeding slow, maybe 2 kbs per second. It also fails about every 5th transfer. It especially fails on .dat and .mmo files (do I need the /C switch?), however some port ok. Most frustrating is if it fails there is no way to either cancel , exit, reset terminal, etc. If I use task manager to end task it will stop but as soon as I open ZTERM again it just keeps going until it fails again.
Our response to the client was:
The /C switch for ZTXFER only applies when copying to AMOS, not from, so that's not an issue here.
Our best guess as to the cause of the lockup is handshaking, i.e. that the serial connection from the ZTERM workstation to the Alpha is not wired for RTS/CTS handshaking, and/or ZTERM has not been configured for that handshaking. As a rule, XON/XOFF is not reliable with file transfers, and file transfers are not reliable without working handshaking. The symptom is typically the one reported, i.e. it works for a few files and then locks up.
A good way to test handshaking is with a barber pole display, like this one:
program BARBER,1.0(100) ! barber poll
MAP1 I,F
MAP1 BAR$,S,79
? tab(-1,99); ! smooth scroll (probably not supported, but no harm to try)
FOR I = 33 TO 111
BAR$ = BAR$ + chr(I)
NEXT I
FOR I = 1 TO 1000
? BAR$
BAR$ = BAR$[2,-1] + BAR$[1,1]
NEXT I
END
That should output about 80K characters, which should take about 40 seconds as 19200 baud, or 20 at 38400. If the handshaking isn't working, it will probably become scrambled noticeably after several seconds. Until you can get that to work reliably, file transfer is going to be painful.
Other than improving the baud rate, about the only other thing you can do is run it on multiple terminals at the same time in parallel. I remember once doing a conversion like this with 5 transfers running, and me going around from one to the next to check on them, move to new PPNs, restart after errors, etc. for the better part of a weekend.)
Of course getting ethernet working will make it a hundred times faster, at least, so it's worth a little effort. But I don't know much about the hardware of a 2000VME machine. One tip: if you do get it working, you will need to add the -n switch to the FTPD startup so that FTP will be compatible with the DevPPN syntax.
