FTP OpenVMS7.3-2 to Windows Server

[tobyjug]

Thanks for all your help. For the record we have the symbol co*py = copy/log

Moving on, the output string is giving me grief. I made a cutnpaste error first time which almost worked;
$ copyx/ftp/ascii/log *.txt 10.76.12.15"FTPAHMIS AHMISFTP"::"/e:ahmis_ftp
%TCPIP-S-FTP_COPIED, AHS_DISK:[AHS.V4_5N_RELEASE.TFR]AHS_EXTRACT_ACT.TXT;1 copie
d to 10.76.12.15"FTPAHMIS password"::"/e:ahmis_ftp.TXT" (116310524 bytes)
%TCPIP-S-FTP_COPIED, AHS_DISK:[AHS.V4_5N_RELEASE.TFR]AHS_EXTRACT_CAR.TXT;1 copie
d to 10.76.12.15"FTPAHMIS password"::"/e:ahmis_ftp.TXT" (16434 bytes)

As you can see ALL files were being copied to e:ahmis_ftp.txt
BUT there is NO ahmis_ftp.txt anywhere on the windows server. ahmis_ftp is the windows share name.

Any other variation eg "/e:ahmis_ftp/" .OR. "/e:ahmis_ftp/ "
all fail with cannot establish /e:ahmis_ftp/

[Hoff]

So you used a different command, and got a different result. Ok. Try this command:

$ COPY /FTP /ASCII this*.txt host"user pass"::

That command typically targets the default directory for the specified username and password on the target host.

You may need to alter the target specification to aim at another directory. Now if your login for FTPAHMIS is that
/e:ahmis_ftp default directory, then leave it off and let the ftp server apply its defaults.

Another option here (given that Windows tends to strip metadata off the files) is to zip the data - using zip "-V" to preserve the metadata, and yes that "-V" is quoted in the command - and transfer over files as one big zip archive. That also tends to be faster, as there's less data headed over, and fewer file operations.

[John Gillings]

>As you can see ALL files were being copied
>to e:ahmis_ftp.txt
>BUT there is NO ahmis_ftp.txt anywhere on the
>windows server. ahmis_ftp is the windows share
>name.

Your windows file specification is illegal. e:ahmis_ftp.txt appears to be a file name, but it contains a ":" character. This has some kind of weird special meaning to Windows, which I've never been able to figure out. The effect from an FTP perspective is to apparently create the file, and accept all the data, and report success back to the sender, but the created file name is only up to the ":" character and is always 0 bytes long. I have no idea what Windows does with all the stuff it was sent, or why it defines this behaviour as "successful", but that's just the way Windows works.

Assuming you mean to store the file on the root of E drive, try "e:\ahmis_ftp.txt" as your target file specification.

[John Gillings]

Just realised, since this is a wildcard filespec, you may want to specify just a target directory. Try:

"e:\somedir\" as the output specification. The input file names should then be used for the output files.

[tobyjug]

Thanks for all your help. I have got the batch job now working.

Output string needed to be:
"" "\"windows share name"