When using the z/OS or z/VM FTP client, performing a PUT (or MPUT) operation causes a SITE command to be sent to the server. The server's response is to reject the command (usually, this will be a 500 response code), but the subsequent transfer completes successfully.
Output is similar to the following:
EZA1701I >>> SITE FIXrecfm 80 LRECL=80 RECFM=FB BLKSIZE=32720
500 'SITE FIXRECFM 80 LRECL=80 RECFM=FB BLKSIZE=32720': command not understood.
EZA1701I >>> PORT 9,37,254,4,10,89
200 PORT command successful.
EZA1701I >>> STOR MYFILE
150 Opening ASCII mode data connection for MYFILE.
226 Transfer complete.
EZA1617I 2413 bytes transferred in 0.005 seconds. Transfer rate 482.60 Kbytes/sec.
This occurs because the server does not support one (or more) of the options specified on the SITE command. These options are unique to the z/OS and z/VM FTP servers, and the 500 code is a proper (and expected) response from a server that does not recognize these options. However, that does not affect the remainder of the transfer operation.
The SITE command is implementation specific, and servers have to tolerate commands that they don't recognize (but still report the fact that they did not).
Resolving The Problem
The sending of a SITE command is the default operation for the FTP client when processing a PUT subcommand. It is intended to ensure that the receiving side (if it were another z/OS or z/VM system) will recreate the same format data set. The SITE command can be suppressed for FTP to servers on other platforms by adding a SENDSITE subcommand to the input stream before the PUT subcommand. The SENDSITE subcommand is a toggle; adding a second SENDSITE subcommand to the input stream restores the sending of the SITE command during PUT subcommand processing.
FTPD UNIX Windows Linux AIX pseries AS/400 iseries Apple ZOSFTP
16 November 2020