The FTP server

FTP, like some other IP applications, is actually a z/OS UNIX System Services application. It can be started within an MVS environment, but it does not remain there very long. It immediately forks itself into the z/OS UNIX environment and tells the parent task to kill itself.

A note on "MVS" versus "z/OS UNIX": The z/OS operating system has existed in one form or another for decades, and has been known by many other names since it was introduced in 1964 as "OS/360." The most common of these older names is Multiple Virtual Storage or MVS. Even today, you will often hear z/OS system programmers use the term "MVS" to mean "z/OS." It is not surprising that MVS is so deeply ingrained because the MVS era (1974-1992) was a major phase in z/OS history, and gave us innovations like multiple address spaces and virtual storage, among many others.

The z/OS operating system still provides the interfaces and system services of the original MVS operating system, but adds many other functions, including extensive support for UNIX interfaces and system services. z/OS essentially adds a UNIX environment through a system component called z/OS UNIX System Services.

For the purposes of this information, we still need to keep the MVS term around. We use the term "MVS services" in discussions of UNIX System Services whenever we need to refer to z/OS functions that operate aside from the UNIX environment in z/OS. The term "MVS" is important because it can be used to differentiate what would be "kernel" services in some other operating systems from "other" services (including UNIX ones). We use the term MVS services to include, for example, the z/OS system services provided by the z/OS base control program (BCP), and we refer to system error messages as MVS messages.

Because UNIX is an operating system on other platforms, you might wonder which of the two - MVS or z/OS UNIX System Services - is the real operating system. The answer is both, actually. MVS services and z/OS UNIX services are two sets of services available in z/OS and there are many others (such as TSO/E services and JES services). Most system functions of z/OS fall under the MVS heading, but the z/OS UNIX environment forms a significant subset.

Understanding this dual nature of z/OS is important to your ability to master the operating system. In this information, some applications are "MVS applications" in the sense that they do not use the z/OS UNIX environment. Other applications are "z/OS UNIX applications" because they must run as a UNIX application in the z/OS UNIX environment. Additionally, all socket communications are handled by z/OS UNIX services, not MVS services. Thus, you often see IP applications like FTP starting in the MVS environment and moving to the z/OS UNIX environment.

The FTPD task could very well be executed using /usr/sbin/ftpd and a few organizations probably do just that. However, the FTP server can be autologged by the TCP/IP started task if JCL is used. So, the FTP daemon is best started using JCL. An example can be found in Figure 1.

Figure 1. FTPD started task JCL

 //FTPD   PROC MODULE='FTPD',PARMS=''
 //FTPD   EXEC PGM=&MODULE,REGION=4096K,TIME=NOLIMIT,
 //       PARM='/&PARMS'
 //SYSFTPD DD DISP=SHR,DSN=SYS1.TCPPARMS(FTPSDATA)

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. However, in most cases using SYSFTPD is the preferred method.

What type of information is 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) and 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.
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.
SSL/TLS. A secure session can be optional or required when connecting to the FTP server.
JES and DB2 environments. An FTP client can be used to interact with JES or DB2 on z/OS.

A small sample of an FTP.DATA file is shown in Figure 2. Any configuration statements not defined are assigned default values.

Figure 2. Sample FTP.DATA statements

 BANNER /etc/ftp.banner
 ANONYMOUSLEVEL 3
 ANONYMOUSFILEACCESS HFS
 FTPLOGGING TRUE
 STARTDIRECTORY HFS

As mentioned, FTP server messages destined for syslogd are redirected to the z/OS system log when syslogd is not running. Tracing and logging of the FTP server can produce a significant amount of output. If the syslogd daemon is stopped, such FTP messages, while not harmful, could be an inconvenience.

Reminder: Syslogd on z/OS UNIX is the same daemon you find running on any other UNIX-style platform. It is a central repository to which applications on the host or network can direct messages. Messages can be classified by the type of message or the priority of a message.

Character sets - FTP server

From an end-user standpoint, FTPing into the z/OS UNIX HFS and FTPing into, say Linux, appears identical. The FTP subcommands are the same and the directory structures are displayed in the same fashion.

However, there is one fundamental difference between z/OS UNIX and all other UNIX style operating systems: z/OS UNIX does not use the ASCII (American National Standard Code for Information Interchange) character set. Instead, z/OS UNIX is implemented using the EBCDIC (Extended Binary Coded Decimal Interchange) character set.

What are the implications? The conversion in most contexts is transparent: messages and commands are automatically translated going in either direction. An end user of an ASCII FTP client would see no difference of appearance between a z/OS FTP server and any other FTP server.

For file transfers, the translation is automatic when using ASCII mode (also called character mode or text mode). If an FTP client sends an ASCII encoded file to z/OS (either to the HFS or the MVS file system), the file is translated into EBCDIC prior to being written to disk. If an FTP client retrieves such a file, it is automatically translated back into ASCII after being read from disk but prior to transmission. An FTP client would never know the other endpoint was storing the file as EBCDIC.

With a binary transfer, no translation occurs. Consequently, if an FTP client sends an ASCII file in binary mode to the z/OS host, this file does not display correctly when viewed on the z/OS host. If the FTP client retrieves an EBCDIC file using a binary transfer type, then the file does not display correctly when it arrives at the host of the ASCII FTP client.

As z/OS continues to evolve, some limited localized support of native ASCII is available. One example is referred to as file tagging, which can be used to identify a file's character set.