Steps

It is a z/OS® UNIX® System Services application. It can be started within an MVS™ environment, but it does not remain there long. It immediately forks itself into the z/OS® UNIX® environment and tells the parent task to kill itself.

The FTPD task could be executed by using /usr/sbin/ftpd and a few organizations probably do just that. The FTP server can be autologged by the TCP/IP started task that uses JCL. The best way to start the FTP daemon is to use JCL. Such as this example:

//FTPD PROC MODULE='FTPD',PARMS=''

//FTPD EXEC PGM=&MODULE,REGION=4096K,TIME=NOLIMIT,

// PARM='/&PARMS'

//SYSFTPD DD DISP=SHR,DSN=SYS1.TCPPARMS(FTPSDATA)

SYSFTPD DD statement

Of interest to this discussion is the SYSFTPD DD statement. This DD points to the FTPD configuration file, usually referred to as the FTP.DATA data set. Like the TCP/IP started task itself, the FTP server searches other locations to locate the FTP.DATA configuration data set if SYSFTPD is not defined. In most cases, by using the SYSFTPD DD is the preferred method. There is a search order hierarchy for finding the FTP.DATA file for the FTP client as well.

The FTP.DATA configuration data set is optional. The FTP daemon searches for this data set during initialization.

FTP.Data server search order

The FTP server search order is:

• A data set specified by the //SYSFTPD DD statement
• ftpserve_job_name.FTP.DATA
• /etc/ftp.data
• SYS1.TCPPARMS(FTPDATA)
• hlq.FTP.DATA data set

FTP parameters have default values, and you can change these defaults by using statements in the FTP.DATA configuration data set. It is not necessary to include all statements in the FTP.DATA data set.

FTP.Data Guidelines:

• Include statements only if the default value is not what you want because the default is used for any statement not included in the FTP.DATA data set

• The FTP client and server read FTP.DATA once at initialization. Therefore, any changes you make to FTP.DATA are not applied until the next time you start the FTP client and server
• Use separate FTP.DATA data sets for the FTP client and the FTP server to specify any conflicting statements
• When you share the FTP server FTP.DATA data set with the FTP client, understand that some of the values for the statements in the FTP.DATA data set have different meanings in the two environments. If the files are shared, error messages could be generated or values that are not valid could be used for each client by using the FTP.DATA data set containing server-only statements

Some FTP server parameters can be changed during an FTP session by issuing the SITE command from the FTP client. Likewise, FTP client parameters can be changed during an FTP session by issuing the subcommand from the FTP client. See the z/OS Communications Server: IP User's Guide and Commands for more information about the SITE command and the LOCSITE subcommand.

information defined in the FTP.DATA data set

A hallmark of the z/OS® operating system is configurability and the FTP server is no exception.

Here is a partial list and brief description of some of the more significant items that can be controlled:

• Banner page. Standard FTP server capabilities such as a banner page file are fully supported
• Anonymous configuration. Several levels of anonymous logon control can be configured
  • When defined to ANONYMOUSLEVEL 3, an FTP user is given a unique root directory (a chroot command to change the root directory is executed by the FTP server)
  • Further restrictions can be placed on other elements of the environment
• Data set defaults. Data set attributes (block size, record format and much more) can be specified. An FTP client can override these attributes while in an FTP session
• The FTP server messages destined for syslogd are redirected to the z/OS® system log when syslogd is not running
• Tracing and logging, Logging of users and detailed debug information can be activated. Output goes to syslogd (the z/OS® UNIX® log daemon). If syslogd is not running, then messages are automatically redirected to the z/OS® system console log
• File system. When an FTP client logs on, the user can automatically be placed into either the z/OS® UNIX® hierarchical file system or else into the z/OS® file system
• Connections to the FTP server can be a secure session
  • It can be optional or required by using SSL/TLS
• JES® and DB2® environments. An FTP client can be used to interact with JES® or DB2® on z/OS®
• FTP.DATA DEBUG parameter can be helpful troubleshooting any problems

See appendix A for the summary of FTP server parameters.

In common with FTP clients found on other platforms, the subcommand set has many similarities as well as a few commands specific to the z/OS® platform. A summary of those subcommands can be found in Appendix B.

FTP language support notes

The z/OS® FTP client supports English as well as Kanji, Chinese, JIS83KJ, JIS78KJ, and KSC5601 language types. Readers familiar with FTP on other platforms recognize many of the commands listed in Appendix B.  

Unique related z/OS® commands

There are some commands in z/OS® FTP that are unique to the z/OS® platform those commands include the following:

The MVSGet subcommand is used to transfer MVS® data sets from a z/OS® FTP server to a z/OS® FTP client without knowing the details of the server data set allocation. The MVS® data set can be one of the following data set types:

• z/OS® physical sequential data set
• z/OS® PDS or library
• z/OS® generation data set reference

The MVSPut subcommand transfers MVS® data sets from a z/OS® FTP client to a z/OS® FTP server without knowing the details of the client data set allocation. The MVS® data set can be one of the following data set types:

• z/OS® physical sequential data set
• z/OS® PDS or library data set
• z/OS® generation data set reference

FTP.DATA client parameter search order

The FTP client uses one of the following search orders to obtain the local site parameter values:

See Appendix C for error codes that can be encountered.

FTP Active mode is the original behavior. It starts with the connection request from the client but then the server initiates a connection back to the client. Passive FTP is useful because some firewalls are configured to allow connection requests in one direction.

z/OS® FTP port usage configuration

The FTP server in z/OS® can be configured to use only a specific range of ephemeral ports for the data connection that are compatible with what was configured for the firewall.  Code the PASSIVEDATAPORTS statement in FTP.DATA. See z/OS Communications Server: IP Configuration Reference for information about the PASSIVEDATAPORTS statement. Alternatively, the range of ephemeral ports that are available to TCP/IP can be restricted by coding the EPHEMERALPORTS parameter on the TCPCONFIG configuration statement. See the description of the EPHEMERALPORTS parameter in the TCPCONFIG configuration statement section in z/OS Communications Server: IP Configuration Reference about EPHEMERALPORTS parameter.

FTP Configuration Parameters:

  .-PASSIVEDATACONN UNRESTRICTED------.   

>>-+-----------------------------------+-----------------------><

   '-PASSIVEDATACONN--+-UNRESTRICTED-+-'   

                      '-NOREDIRECT---'  

UNRESTRICTED

The server accepts a passive data connection from any IP address and is the default parameter

NOREDIRECT

The server verifies the peer address of the data socket is the client's IP address. If it is not, the server closes the data socket.

>>-PASSIVEDATAPORTS (low_port, high_port)----------------------><

FTP Server Port Parameters

low_port

The lowest port number the FTP server is allowed in creating a listening data socket. The lowest number allowed for low_port is 1024.

high_port

The highest port number the FTP server is allowed in creating a listening data socket. The highest number allowed for high_port is 65535.

 .-PASSIVEONLY FALSE------.   

>>-+------------------------+----------------------------------><

   '-PASSIVEONLY--+-FALSE-+-'   

                  '-TRUE--'     

FTP Server Mode Parameters

FALSE

Data connections for the client are not passive mode only

When passive mode attempt fails, the client tries active mode and is the default parameter

TRUE

Data connections for the client are passive mode only

FTP connection processing

Active Mode—The client issues a PORT command to the server signaling that it “actively” provides an IP and port number to open the Data Connection back to the client.

Passive Mode—The client issues a PASV command to indicate that it will wait “passively” for the server to supply an IP and port number after which the client creates a Data Connection to the server.

Note: the port command format is:

            PORT <h1, h2,h3,h4,p1,p2>

The numbers used for the values of h1-h4 constitute the IP address the server connects on. The numbers used for the values of p1-p2 are used to calculate the port number. In order to get the decimal value of the port, the following formula is used: (p1 * 256) + p2 = data port. The same information is returned in message 227.

Restarting a failed transfer

FTP supports two subcommands for restarting data transfers that fail. Select the appropriate subcommand based on the data transfer mode at the time the data transfer failed.

• If stream mode data transfer was used, use the SRESTART subcommand to restart the data transfer. See SRESTART subcommand—Restart a stream data transfer for a description of stream mode restart
• If block or compressed mode was used, use the restart subcommand to restart the data transfer. See RESTART subcommand—Restart a checkpointed data transfer for a description of block or compressed mode restart
• More information on these subcommands can be found in Appendix B

To restart a block or compressed mode data transfer, checkpointing must be initiated before the start of the transfer. You can use either the LOCSITE or SITE subcommands to initiate checkpointing.

• The LOCSITE subcommand parameter CHKPTINT controls the checkpoint interval at the client, and the parameters CHKPTPREFIX and RESTGET control the naming of the client checkpoint data set
• The SITE subcommand parameters CHKPTINT and RESTPUT control the checkpoint and restart processing at the server

Each of the LOCSITE/SITE parameters is also supported in the FTP.DATA file.

If the local file or the remote file is a z/OS® UNIX® named pipe, do not use the SRESTART or restart subcommands to restart the file transfer. File transfers that are binary and are a named pipe, use the restart instructions that follow. The following instructions can also be used to start the transfer again.

The RESTART command gives the ability to manually restart an FTP transfer. The restart takes place from a saved point in the transfer. There are IBM® and non-IBM® products known as "Managed" FTP servers that provide automatic restart support.