TCP connection status

A TCP connection progresses through a series of states during its lifetime. The following diagram illustrates the possible states for a TCP connection and how the states transition based on various events from either the network or from the local TCP sockets application.

Figure 1. TCP state transition diagram

Table 1. TCP state transition description table

TCP connection state	Abbreviation in MVS™ console	Abbreviation in TSO or UNIX shell	Description
LISTEN	Listen	Listen	Waiting for a connection request from a remote TCP application. This is the state in which you can find the listening socket of a local TCP server.
SYN-SENT	SynSent	SynSent	Waiting for an acknowledgment from the remote endpoint after having sent a connection request. Results after step 1 of the three-way TCP handshake.
SYN-RECEIVED	SynRcvd	SynRcvd	This endpoint has received a connection request and sent an acknowledgment. This endpoint is waiting for final acknowledgment that the other endpoint did receive this endpoint's acknowledgment of the original connection request. Results after step 2 of the three-way TCP handshake.
ESTABLISHED	Estblsh	Establsh	Represents a fully established connection; this is the normal state for the data transfer phase of the connection.
FIN-WAIT-1	FinWt1	FinWait1	Waiting for an acknowledgment of the connection termination request or for a simultaneous connection termination request from the remote TCP. This state is normally of short duration.
FIN-WAIT-2	FinWt2	FinWait2	Waiting for a connection termination request from the remote TCP after this endpoint has sent its connection termination request. This state is normally of short duration, but if the remote socket endpoint does not close its socket shortly after it has received information that this socket endpoint closed the connection, then it might last for some time. Excessive FIN-WAIT-2 states can indicate an error in the coding of the remote application.
CLOSE-WAIT	ClosWt	ClosWait	This endpoint has received a close request from the remote endpoint and this TCP is now waiting for a connection termination request from the local application.
CLOSING	Closing	Closing	Waiting for a connection termination request acknowledgment from the remote TCP. This state is entered when this endpoint receives a close request from the local application, sends a termination request to the remote endpoint, and receives a termination request before it receives the acknowledgment from the remote endpoint.
LAST-ACK	LastAck	LastAck	Waiting for an acknowledgment of the connection termination request previously sent to the remote TCP. This state is entered when this endpoint received a termination request before it sent its termination request.
TIME-WAIT	TimeWt	TimeWait	Waiting for enough time to pass to be sure the remote TCP received the acknowledgment of its connection termination request.
CLOSED	Closed	Closed	Represents no connection state at all.

Clients or Users

For various reasons, TCP/IP refers to MVS jobs or address spaces that use TCP/IP services as clients or users of TCP/IP services. The term client in this context has nothing to do with the traditional client/server roles of a network application. Both local server programs and local client programs on z/OS® are clients or users of TCP/IP services. For most purposes you can substitute Client name, User ID, and User in the Netstat reports with MVS jobname.

UDP socket status

UDP, unlike TCP, does not operate with strict states. The state that is shown in the various Netstat reports is always UDP for UDP sockets.

Client ID or Connection number

A generated number that uniquely identifies a socket endpoint that might represent a connection on this TCP/IP host. This number can be used to drop a socket or connection with the Netstat DROP/-D parameter.

Client name or User ID

The client name from a TCP/IP perspective is in general the job name of the address space that owns the socket. For batch jobs this is the job name. For TSO users, this is the TSO user ID. For UNIX processes this is the job name as determined during process creation, either by appending a digit to the job name (INETD creates INETD1) of the parent process or by setting the job name to the value of the _BPX_JOBNAME environment variable. For started tasks, the job name is generally the procedure name. If a procedure is started with the JOBNAME keyword (S procname,JOBNAME=myjob), then the job name becomes the value that was specified on that JOBNAME keyword. If a procedure is started with a start modifier (S procname.modif), then the modifier is what is shown as the TCP/IP client name.

Local IP address

A socket might have no address information at all (right after it has been created by a program using the socket() call); it might have just a local address (a local IP address and/or a local port number) that was set using a bind() socket call; or it might have both a local address and a remote address, in which case it represents a connected socket (a socket that is in connection with a remote socket).

The local IP address of a socket is either zero (not bound to any local IP address) or it is an IP address that is in the HOME list of this TCP/IP host.

The listening socket of a server program has only the local address filled in. If the local IP address of the server's listening socket is zero, then remote clients are allowed to send connection requests to any IP address that is in this TCP/IP host's HOME list. If the local IP address of the server's listening socket is nonzero, then remote clients can connect to this server only by sending connection requests to that specific IP address. A connected socket has both the local and the remote address filled in.

Foreign/remote IP address

The remote IP address is present for connected sockets and represents the IP address that is associated with the remote socket endpoint to which this socket is connected. A connected socket might be one of the following sockets:

• A server socket where the remote client that is represented by this remote IP address connected to a server on this TCP/IP host.
• A socket belonging to a client program on this TCP/IP host that is connected to a server on the remote TCP/IP host that is represented by this remote IP address.

Local port

The local port is part of the local address of a socket. For a server's listening socket, the port represents the specific server. If remote clients need to use the services of this server, they send a connection request to this TCP/IP host to this server's specific port number.

Connected sockets might represent one of the following case:

• A connection with a local server from a remote client, for example, the local port number is the same port number that appears on the server's listening socket.
• A local client connected to a remote server, for example, the port number could be any port number the TCP/IP host found available when the connection was being established (also known as an ephemeral or short-lived port number). This is typically a port number higher than 1024.

Foreign/remote port

The remote port is part of the remote address of a socket and is present only for connected sockets. It represents the port number of the remote socket that is connected to this socket. If the connected socket belongs to a client program on this TCP/IP host, then the remote port number identifies the server on the remote TCP/IP host to which this client program is connected.

Local socket

The IP address and port number to which the application on the local stack was bound.

Foreign socket

The IP address and port number to which the application on the remote host was bound. For UDP sockets, the foreign socket field that is shown in the various Netstat reports is displayed as *..* if the socket is not connected. For connected UDP sockets, the foreign socket field shows the remote IP address and port specified on the connect request. When a UDP socket is connected, it accepts packets only from the specified remote IP address and port.

Last touched time

For TCP, the last time one of the following events occurred to the connection:

• The server side receives a connection request.
• The server side accepts the connection request.
• Either the server or client side of a connection receives a packet.
• Either the server or client side of a connection sends a packet.

For UDP, the last time one of the following events occurred to the connection:

• Either the server or client side of a connection receives a packet.
• Either the server or client side of a connection sends a packet.

Redirecting Netstat output:

Netstat screen output can be redirected for all Netstat reports. The following example uses the BYTEINFO report:

From TSO environment:

• You can redirect TSO NETSTAT screen output to a disk file by appending a REPORT option.

  NETSTAT BYTEINFO REPORT

  The data set MVSUSER.NETSTAT.BYTEINFO (where MVSUSER is the user ID) is created containing the screen output from a BYTEINFO command. See Netstat command output for more description of the REPORT option.

• You can also redirect TSO NETSTAT screen output to the TSO data stack by appending a STACK option.

  NETSTAT BYTEINFO STACK

  Causes the report, stripped of title lines, to be placed in the TSO data stack containing the screen output from a BYTEINFO command. See Netstat command output for more description of the STACK option.

From z/OS UNIX shell environment:

You can redirect the netstat screen output to a file by using the redirect function (>) in the following format:

netstat -b > byteinfo

The file byteinfo is created in your current directory containing the screen output shown previously.

Time stamp

The time stamp displayed in the header for each Netstat report is in local time. The time field displayed in reports ALL/-A, BYTEinfo/-b, CLients/-e, HOME/-h, RESCache/-q, ROUTe/-r, SLAP/-j, UP/-u, and VIPADyn/-v is Coordinated Universal Time (UTC). UTC time does not take leap seconds into account.