FTP refuses to get data in ASCII mode

[Hans Adriaanse]

Hi,

I am trying to get a file in ASCII mode. I have a file with the following commands:
DISABLE VMS_PLUS
SET TYPE ASCII
SET PASSIVE ON
SET DEFAULT "/home/hadriaan/ss"
SET DEFAULT/LOCAL "DSA4:[STEP_HARM.TMP]"
GET *.*
EXIT
Using this file with FTP I get logged:
230 Login successful. Have fun.
VMS Plus mode disabled.
200 ASCII tastes bad, dude.
Passive is ON.
250 Directory successfully changed.
Local directory now DSA4:[STEP_HARM.TMP]
227 Entering Passive Mode (10,17,6,212,237,65)
150 Opening BINARY mode data connection for 20050925_SPC_20051001.xml (1185599 b
ytes).
%TCPIP-E-FTP_OUTPROCF, error processing output file DSA4:[STEP_HARM.TMP]20050925
_SPC_20051001.xml;1
-RMS-W-RTB, 61440 byte record too large for user's buffer
426 Failure writing network stream.

So it says "Opening BINARY mode data connection" while I wanted ASCII.

Has anyone a solution for this.

Thanks in advance,
Hans

[Ian Miller.]

I guess the local system is VMS running TCPIP Services for OpenVMS(what version?) and the remote system is unix (vsFtp ?)

[comarow]

Perhaps you could backup the file or zip it?

[Hans Adriaanse]

Sorry, the versions: OpenVMS 7.3-2, TCPIP 5.4 - ECO 4.
The remote system is a Linux system (I think Suse 9).
When the remote system is also a VMS system, the problem does not occur.

[Hans Adriaanse]

Backup or zip are no options. The remote system is a customer site. Now it is an OpenVMS system, but that will change in the near future. That is why I am testing with OpenVMS and Linux as remote systems.

[Richard Whalen]

I would say that the remote system has an FTP implementation that is not compliant with RFC 959. (see section 5.1 MINUMUM IMPLEMENTATION)

5.1. MINIMUM IMPLEMENTATION

In order to make FTP workable without needless error messages, the
following minimum implementation is required for all servers:

TYPE - ASCII Non-print
MODE - Stream
STRUCTURE - File, Record
COMMANDS - USER, QUIT, PORT,
TYPE, MODE, STRU,
for the default values
RETR, STOR,
NOOP.

The default values for transfer parameters are:

TYPE - ASCII Non-print
MODE - Stream
STRU - File

All hosts must accept the above as the standard defaults.



The FTP server on the remote system should be replaced.

[Steven Schweda]

Clearly, the subject here should be "(Lame)
FTP server refuses to provide data in ASCII
mode", as the (lame) FTP server is the real
source of this problem. Any program which
puts out a message which says "dude" is not
one I'd trust for any serious work.

That said, it's possible that Wget would do
better than your VMS FTP client in this case.
("It's possible" means that you'd need to
run the experiment to find out.) Even if it
works better, you might still need to do
some sort of SET FILE /ATTRIBUTES operation
on the result of the binary transfer.

For a good time, consider a visit to:
http://antinode.org/dec/sw/wget.html

No bets.

[Sebastian Bazley]

GET *.*
should probably be
MGET *.*
but I doubt that's anything to do with the problem at hand.

[Ian Miller.]

curl is also worth trying
http://curl.haxx.se/download.html#VMS

but I think the ftp server is faulty.

[Wim Van den Wyngaert · Accepted solution]

On Linux you can find FTP servers that only support binary transfers because only Linux exists according to them. Everyone speaks French, no ?

Wim

[Hans Adriaanse]

I am confused, but it seems to be a Linux problem indeed. I have tried it on several Linux systems and they all have the same problem. If I FTP to a Windows 2003 server, there is no problem at all. So not completely proven, but it looks like a server problem. I'll try to live with that.

Thank you all.

[Wim Van den Wyngaert]

But it seems that zipping the file would help.

Wim

[Richard Brodie_1]

If it's vsftpd on the Linux side, then the FTP server is configurable but ignores ASCII mode by default.

See: http://vsftpd.beasts.org/vsftpd_conf.html