How to run "set file/attrib" from an FTP client?

[Matthew Beermann]

I'm writing a program that will be uploading files via FTP from a Microsoft Windows box to OpenVMS. I've noticed that the resulting file ends up with the wrong attributes. Specifically, I need to run set file/attrib=(rfm:stmlf,rat:cr) afterwards.

My question is, how do I do this from the FTP _client_, or get VMS to choose the correct format in the first place? I have to assume that in general no interactive login to the OpenVMS box will be available, and thus I can't issue the command from the console.

I apologize if this has been asked before, but I couldn't find the answer in the Ask the Wizard archives...

Client: Microsoft Windows SP2 FTP
Server: OpenVMS 7.3-2, MultiNet V4.4(91)

[Jan van den Ende]

Matthew,

I know of no way to do that (but I do not know Multinet, if someone knows a Multinet solution..?)

However, we have a solution for automatically processing files received via ftp, and your request amounts to simple processing.
This assumes:
- a dedicated account to receive the files.
- no other uses for that account.
Since you are now writing the program, I will asume that you can (arrange to) meet these requirements.

The account will have NETWORK and BATCH access, but NO INTERACTIVE. The SYS$LOGIN has (at least) two subdirectories.
The files are ftp'd to one of those.
The account will have a LOGIN.COM which,
IF F$GETJPI("","mode") .eqs. "NETWORK"
submits a batchjob /AFTER=
The batchjob will test the existence of the network job, if present, just wait a little and retry.
RENAME the received file away from the tranfer directory, and do you thing with it. (Maybe you need to do more processing? This is also a nice way to get rid of the ugly polling for a received file, and just get riggered by the receipt of the file.

I leave it up to you to do the checking for multiple simultanious files etc.

Succes!

Proost.

Have one on me.

jpe

[Thomas Ritter]

Matthew, we perform these types of activities. Write a DCL command procedure to perform the FTP. After successfully getting the file execute the appropriate DCL commands.
Some advice: always "get" files using some temporary name. Only after a successful "get" or "put" rename the file to that expected. This way should the transfer be interrupted, the receiver will not process an incomplete file. We perform hundreds of FTP per day. Simple things like this can prevent a lot of time wasting.

Some example code:
$ ftp 192.168.0.1/username=secret/pass=secret
get data.txt data.tmp
bye
$ if $severity .and. 1
$ then
$ rename data.tmp *.txt
$ endif
$ set file ...
$ ...

[Jan van den Ende]

Thomas,

in principle, that WOULD work, but if, and ONLY if, the receiving {VMS) system would/could somehow be in control.
If, however, the transfers are generated "just when", you would need quite elaborate procedures to login to VMS and get this done, which WOULD conradict the prerequisites if I read them correctly.

Proost.

Have one on me.

jpe

[Steven Schweda · Accepted solution]

Should we assume that you're using type
ASCII FTP transfers, and getting attributes
like "Record format: Variable length"? If
not, what should we be assuming?

I know nothing about the MultiNet FTP
server, but a quick Google search for

vms OR openvms multinet ftp server file format

found "Chapter 18, MultiNet v4.4
Installation and Administrator's Guide",
which mentions the "site" command, and it
seems to offer some hope. I quote:

SITE SPAWN command

Spawns a subprocess and uses the rest of the
line as a VMS DCL command. Not valid for
CAPTIVE processes.


If that does what I think it might, then it
looks as if it might be able to handle a SET
FILE /ATTR command. I don't have a
convenient MultiNet FTP server on which to
test my hypothesis. (I assume that if you
can manage a PUT command from your program,
that you can also manage a (fancy) SITE
command.)

Apparently, SPAWN enablement is optional,
and may be set independently for individual
users.

Nothing similarly fancy seems to exist for
the HP TCPIP FTP server.

[Thomas Ritter]

Use ftp> help/remote to see what multinet can support with the "quote" command.
On VMS we have

FTP> help/remote
214-The following commands are recognized:
USER TYPE RETR RNFR NLST PWD ALLO EPSV
PASS STRU STOR RNTO CWD CDUP SYST QUIT
SITE PORT STOU DELE MKD NOOP STAT HELP
MODE EPRT APPE LIST RMD ABOR PASV
214 End of Help.

[Steven Schweda]

> Use ftp> help/remote [...]

Except that this tells you about FTP
commands, which is not what we want here
(at least so long as it includes SITE, which
_is_ what we want here).

Note that "help/remote" on the TCPIP FTP
client is equivalent to "quote help" on
practically any other FTP client. (And
"quote help" works on the TCPIP FTP client,
too.)

What would be more useful would be:
ftp> site help

which might give a more helpful response
than this one from my TCPIP V5.4 - ECO 5 FTP
server:

214-The following SITE commands are recognized:
214 VMS +VMS+ ULTRIX UNIX NONE

That's where it'll say SPAWN (if anywhere),
and if it does, then you should be in
business.

[Steven Schweda]

> ftp> site help

Oops. Make that:

ftp> quote help site

This stuff isn't complicated. Really.

[Richard Whalen]

The "SITE SPAWN SET FILE/ATTRIBUTE..."
will do the job, but make sure that you need to do this. If you are doing a (default) ASCII upload to VMS from Windows, then the FTP server is converting the FTP text stream to the common VMS format of a variable length record, carriage return carriage control file. If you really want a stream file to be written, then you need to use the SITE RMS STREAM ON command.

[Steven Schweda]

Plus, if you expect SET FILE /ATTR to work,
then an ASCII file transfer would be the
wrong thing to do. After an ASCII transfer
which produced a RFM:VAR file, you'd need to
CONVERT it, not just change its attributes.

After a _binary_ transfer the bits should be
ok, but the attributes may be something like
fixed-512 instead of Stream_LF, and in that
case, SET FILE /ATTR could do the job.

But, yes, after a little more manual reading,
it sure looks as if SITE RMS STREAM ON would
be _the_ thing to do.

As usual, it helps to ask for the best
solution to the problem, _not_ for the best
way to implement a sub-optimal solution to
the problem. But sometimes you get lucky,
and someone (else, in this case) provides the
answer to the un-asked question instead of
the asked question.