The TCP/IP daemon

The single entity that handles, and is required for, all IP-based communications in a z/OS environment is the TCP/IP daemon itself. The TCP/IP daemon implements the IP protocol stack and runs a huge number of IP applications to the same specifications as any other operating system might do. That's the beauty of TCP/IP.

For example, you can run FTP, telnet, SNMP, sendmail, NFS, HTTP servers, rlogin, SSH, BIND DNS (and the list goes on). All these are standard implementations, and many of these applications are ported from the industry standard source code. Any of these applications interact with the same applications running on essentially any other operating system.

Though TCP/IP sounds familiar, on z/OS there are differences.

First of all, TCP/IP does not really run as a daemon. That term was used in the first paragraph because from a casual viewpoint, the TCP/IP started task is the same as a daemon. It starts up and stays running for as long as the operator wants it to. It handles service requests of various kinds from within the operating system environment and from the network. So why, you may ask, can't these z/OS people just call it a daemon?

Control issues and the TCP/IP stack

Calling the TCP/IP started task a daemon is a little like calling a professional quality sound system a radio. It's a question of configurability and control. A daemon is started by a simple command line in a script file. There are few environment variables that can be specified.

By contrast, the TCP/IP started task is started as a program using Job Control Language (JCL). The capability of specifying parameters in JCL opens the door to a level of environmental control and configurability that cannot be matched in a daemon environment. Much of this section touches upon the JCL environment and how it can affect the way TCP/IP runs.

As an example, the z/OS environment can support more than one instance of a TCP/IP started task. The tasks are completely isolated from one another. In fact, you need to define links, either externally or internally, if you want the two TCP/IP tasks to have IP connectivity to each other. Without the JCL and the inherent z/OS underpinnings, such a scenario would be impossible.

The other reason why we call TCP/IP a started task is because the z/OS environment really does run daemons. In fact, we discuss the z/OS UNIX System Services telnet daemon in another topic.

But we're not through with the TCP/IP started task just yet. TCP/IP is a layered protocol, and networking professionals want to keep that in mind. Consequently, the most commonly used term for the TCP/IP started task is the TCP/IP "stack." This is the terminology used in this section.