504: Server SBSENDEOL must be CRLF for stream mode restart of RETR command

Explanation

The server sends this reply to the client when all these conditions are true:
  • The type is ASCII and the mode is STREAM.
  • The SBSENDEOL setting is not CRLF.
  • The server has just processed a REST command while type is ASCII and mode is STREAM.
  • The server is now processing a RETR command.

The server rejects the RETR command with this reply when the FTP client is trying to restart a file retrieve transfer in stream mode. For z/OS® FTP client users, the client tries to restart a file retrieve when the user issues an srestart get subcommand. Stream mode restart of file retrieve is not supported by the z/OS FTP server when the SBSENDEOL setting has been changed from CRLF.

System action

The RETR command is rejected by the server.

User response

You must transfer the file again in its entirety instead of restarting the file transfer. If you continue to experience this error, report the error to the system programmer.

System programmer response

Most clients and servers do not tolerate an SBSENDEOL setting other than the default, CRLF. When you code SBSENDEOL as a different value in the server's FTP.DATA, or send a SITE SBSENDEOL command to the server to set the value to anything besides CRLF, your users will not be able to restart a file retrieve in stream mode. If your installation requires the alternate server SBSENDEOL setting for only certain file transfers, code SBSENDEOL CRLF in the server's FTP.DATA and instruct your users to send a SITE SBSENDEOL command to the server just prior to those file transfers. The users will be able to restart stream mode file transfers that are interrupted before resetting SBSENDEOL.

Advise your users not to trick the FTP server into restarting a file retrieve that failed while the server's SBSENDEOL value was not CRLF because the result will likely be corrupted files.

Also, consider whether block or compressed mode file transfers would be appropriate for your installation. Block mode transfers can be restarted, provided you have initiated checkpointing before the file transfer. See the information about restarting a failed data transfer in z/OS Communications Server: IP User's Guide and Commands for more information.