Roger Deschner wrote this back in 2002. Here it is:
I used Romney White's VMFTP to build a program that does just that. Some tips: In order to use VMFTP, you must have CMS be the client, and your target system (PC, Unix...) be the FTP server. There are free FTP daemons for Win95, such as War FTP. I used a commercial one from Hummingbird that came with their fine Host Explorer telnet product. Beware of VMFTP macros - they are Rexx programs running with ADDRESS VMFTP in effect. Do not attempt to change this permanently with the ADDRESS statement. That means, for instance, that to run a pipe you must ADDRESS COMMAND 'PIPE... VMFTP tells you a lot via return codes. Don't ignore them; check them. They can vary depending on which FTP server you are talking to. VMFTP needs numeric IP addresses. Look 'em up with a PIPE. Use a PIPE XLATE stage to turn your EBCDIC plain text files into ASCII. This way you can strip trailing blanks, and have total control over the translation process. Then FTP with binary. Use only XLATE FROM 1047 TO 819!!! THERE IS NO OTHER VALID TRANSLATION FOR FILES! The only way to achieve this desired translation is within a CMS PIPE. I could, and have, written volumes about this, so I won't bore you here. Some programs (Eudora, for instance) care that empty lines must be exactly length 0. That is, they must be CR LF CR LF, not CR LF SPACE CR LF. They are not recognized as blank lines if they are length one which is a space character. You must strip trailing blanks - all of them. Zero-length lines are invalid in CMS files. Fortunately, a zero-length line is valid within a pipeline, so this can be dealt with, using the above technique of building the ASCII file on CMS and then transferring it as a binary file. The myth of the "Standard ASCII computer" is just that - a myth. You will have to deal with the differences in lineneding characters between Unix (LF), Mac (CR), and DOS-Windows-OS/2 (CRLF). Build a list of files to FTP and then have your VMFTP macro read that file. It is inevitable that long FTP transfers will be interrupted and will need to be restarted. When that happens, just comment out or delete the files in this driver file which have already been transferred. If you don't use this technique, you'll never make much progress and you will frustrate yourself trasnferring the same files over and over again. Don't let minor net glitches bother you. If you get a return code from a PUT that suggests a network error, simply CP SLEEP 30 SEC and then try it again. Then if it doesn't work the second time, worry. Within a VMFTP macro I was able to find only one way to issue a CP SLEEP: ADDRESS COMMAND 'CP SLEEP 30 SEC' I don't know why this is, but that's a way I found that worked. ADDRESS CP did not work - it didn't fall asleep. Keep your spooled console files and inspect them. This is critical for restarting a failed transfer or for figuring out the myraid of other ways things can go wrong with this. Even on Windows 98+, the ancient MS/DOS file name restrictions apply. I wouldn't mention this if it hand't bitten me - hard. The rule is, files with filenames AUX CLOCK$ COM1 COM2 COM3 COM4 CON LPT1 LPT2 LPT3 PRN LST NUL and with a filetype three characters or shorter, cannot be represented on a DOS or Windows system. You will need to check for CMS files which fall into this category and rename them as you download them - I simply padded the filetype to four characters with $. The error messages will be completely misleading when this occurs, so prevention is the only cure. The : (colon) character is valid within CMS fileids, but not on other systems. I translate it to % (percent). There are a lot of special files that you'll need to deal with. SPSS, SAS, VMARC, NETDATA, and binary files need to be located and converted to a more portable format, or transferred as binary. When I had to do this for several hundred users, I simply wrote the files to Joliet-format CDs which we mailed to them. It's archival, and getting the files from a CD to other systems is easy. Windows can simply open a Joliet CD as though it were a Zip disk or whatnot, so "uploading" from a CD consists of simply copying. Beware that copies of files from any CD will have the Read-Only Attribute. Zip disks or floppy disks could also be used, but are smaller, not archival, and are costlier. I could go on. If you need more details, or if you need specific help with something when you're in the middle of it, send me email off-list. Roger Deschner University of Illinois at Chicago [EMAIL PROTECTED] ==== A carelessly planned project will take three times longer than ==== == expected; a carefully planned project will take only twice as long. ____________________________ Jim Hughes 603-271-5586 "There's no sense in being precise when you don't even know what you're talking about." John von Neumann ________________________________ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Wednesday, December 05, 2007 1:56 PM To: IBMVM@LISTSERV.UARK.EDU Subject: FTP We have a one-time need to FTP thousands of files to an MVS system from VM. Is there any way to coax FTP to read a file for its subcommands? I see nothing in the syntax that performs the same function as the Windows switch -s:fileid. Is it really necessary to stack all of the subcommands before issuing the FTP command? Regards, Richard Schuh
