FTP OpenVMS7.3-2 to Windows Server

[tobyjug]

I can do 1 file at a time but I want to set up a batch job to move all 26 files in 1 hit. All files are .TXT and all are version 1.
For some reason I can't use the * wild card. It errors with cannot file file name *

Thank You

[Hein van den Heuvel]

Did you try Mget ?
Be sure to also read up on the "SET PROMPT"

Hein.

[Steven Schweda]

> Did you try Mget ?

Or "mput".

> Be sure to also read up on the "SET PROMPT"

FTP> set prompt
%CLI-W-IVKEYW, unrecognized keyword - check validity and spelling

Well, "prompt":

FTP> prompt
Interactive mode off.
FTP> prompt
Interactive mode on.

The help in the FTP client program would not
win many awards (from me) for quality or
utility.

[Steven Schweda]

> For some reason I can't use the * wild
> card.

I got so excited about "SET PROMPT" that I
forgot that we really don't know how you're
trying to do this. "FTP /INPUT"? If so,
then you might do better (or more easily)
with "COPY /FTP". As usual, many things are
possible.

[Hoff]

Start with this DCL command:

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

and see how far you get with the Windows ftp server.

You may need to tweak some logical names on OpenVMS as the Windows ftp tools can be incompatible with ftp on OpenVMS.

[tobyjug]

Cannot find help for structure of the mget or mput commands
Copy/ftp help only indicates the receiving host as being VMS. I need to go to a windows share. Failed anyway
$ copy/ftp/assci/ *.txt windowshostIP "username password"
%DCL-I-IGNQUAL, qualifiers appearing before this item were ignored
\FTP\

[Hoff]

The DCL command COPY /FTP functions as listed and as documented; somebody appears to have defined a symbol that interferes with it.

Probably COPY, or maybe a substring.

$ SHOW SYMBOL COPY

If so...

$ DELETE /SYMBOL [/GLOBAL] COPY

That DELETE command can fail for the same reason that the COPY command is probably failing here; because somebody has established a DELETE symbol.

Setting up DCL symbols that exactly match DCL commands is generally not recommended for just this reason.

[John Gillings]

COPY/FTP works between dissimilar systems, as long as the syntax is correct.

There are several issues with your attempt:

$ copy/ftp/assci/ *.txt windowshostIP "username password"
%DCL-I-IGNQUAL, qualifiers appearing before this item were ignored
\FTP\

First problem. You have a symbol "COPY" which defines qualifiers. The -I- (Informational) message is telling you they are ignored. This may or may not matter. Syntactically, the /FTP qualifier is required to be first. Try:

$ COPYX/FTP

the trailing X will override your symbol definition.

Second problem, /assci is misspelled. It should be /ASCII. I'm a bit surprised this error didn't generate a warning message like:

%DCL-W-IVQUAL, unrecognized qualifier - check validity, spelling, and placement
\ASSCI\


third problem, there's a trailing "/" on the command line. This should also have generated a warning message:

%DCL-W-IVQUAL, unrecognized qualifier - check validity, spelling, and placement
\*\

(because spaces between the "/" and the qualifier name are allowed, the command is parsed assuming the "*" is the qualifier).

fourth problem, the syntax for the target file specification is incorrect. It should be:

$ COPY/FTP/ASCII *.TXT node"user password"::"remote filespec"


For example - this is a cut & paste of an actual transfer from an OpenVMS V8.3-1H1 system to a windows server:

$ copyx/ftp/ascii/log send*.txt 10.2.21.133"anonymous junk"::"/~support/vmsxfer/"
%TCPIP-S-FTP_COPIED, DISK$USERS:[GILLINGS]SEND_SEMF.TXT;2 copied to 10.2.21.133"anonymous password"::"/~support/vmsxfer/send_semf.txt" (2809 bytes)
%TCPIP-S-FTP_COPIED, DISK$USERS:[GILLINGS]SEND_SMS.TXT;5 copied to 10.2.21.133"anonymous password"::"/~support/vmsxfer/send_sms.txt" (137427 bytes)

This is a "put" from OpenVMS to windows. Reverse the file specifications for a get.

[Hoff]

And ps: COPY /FTP works with most any FTP server; I use it regularly with Mac OS X and with various Unix and Linux boxes. The salient difference here can be in the syntax of the target specification; that can potentially need to be quoted, when it's not native OpenVMS filename syntax. And which is why I specified the COPY /FTP command as I did, with no target file specification. This should drop the files in the target directory.

COPY /FTP also allows symbol substitution and other DCL programming techniques, which the FTP utility does not; to get around this, you'll have to write and @-invoke runt files with the FTP utility to perform various of these operations.

Whether COPY /FTP works with the ftp server within the Microsoft Windows Server platform, I don't know. Windows client and Windows server are not in regular use here.

[RBrown_1]

It looks to me like you have defined a symbol for COPY

$ SHOW SYMBOL C*

Is there any COPY, COP*, CO*, or C* that does a COPY with some qualifiers?

And for good measure

$ SHOW NETWORK

[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"