Filtering options when recording the trace

Options for filtering include the following:

Component: Required - SYSTCPIP for SOCKAPI.
Subtrace: Required - TCP/IP stack name.
Trace option: Highly recommended to limit the tracing to the SOCKAPI option. You can also filter on this option when formatting the trace.
Jobname: Highly recommended for socket applications to limit the trace to one application. You can also filter on this option when formatting the trace.
ASID: Highly recommended as an alternative to the job name if the application has already started running (otherwise, the ASID is unknown). You can also filter on this option when formatting the trace.
IP address: Recommended only for certain scenarios (see discussion below). The IP address is a filtering option when formatting the trace.
Port: Recommended only for certain scenarios (see discussion below). The port number is a filtering option when formatting the trace.

If trace data for multiple applications is collected in the same data set or in a dump, the trace output should be filtered so that application programmers see only the data for their applications for security reasons.

Use the IP address and Port options to filter the trace, both when collecting the trace and when formatting the trace. Generally, it is best to collect all the application records to avoid having to re-create the problem. After the records are collected, you can filter the records various ways when formatting the trace.

An example scenario in which you would only want to collect records for one IP address is if there is a problem with a particular remote client, and the local application has many clients. If you tried to record the trace records for all clients, there could be a lot of data and the trace could wrap, thus overwriting older records. Note that if you specify an IP address when collecting the trace, the trace records with no IP address are also collected. So you get all the records for the problem client, and some other client records.

An example scenario, in which you would only want to collect records for one port number, is if there is a problem with a server on one port. If you specify a port number when collecting the trace, the trace records with no port number are also collected. You get all the records for the problem server application, and some other applications' records.

IP address/port filtering, when specified, has a varying effect depending on the type of socket call being traced. Table 1 describes the effect of IP address/port filtering for the different types of socket API calls. The Yes or No specified in columns 2 and 3 indicates whether local port filtering and remote IP address filtering can be activated for the socket calls in column 1. Yes means that if a filter is set, only the calls matching that filter are collected. No means that whether a filter is specified, all the calls are collected (no filtering is done).

Table 1. IP address and port filtering effect on different types of socket API calls
Socket call	Filtering active?
Socket call	Local port	Remote IP address
ACCEPT	Yes	No (1)
BIND	Yes/No (2)	No
CONNECT	Yes/No (3)	Yes
CANCEL FREEADDRINFO GETADDRINFO GETCLIENTID GETHOSTBYADDR GETHOSTBYNAME GETHOSTID GETHOSTNAME GETNAMEINFO INITAPI RECVFROM RECVMSG SELECT SELECTEX SENDMSG SENDTO SOCKET TAKESOCKET TERMAPI	No	No
LISTEN	Yes	No
CLOSE GETPEERNAME GETSOCKNAME GETSOCKOPT GIVESOCKET FNCTL IOCTL READ READV RECV SHUTDOWN SEND SETSOCKOPT WRITE WRITEV	Yes	Yes

Where Yes is indicated in Table 1, the assumption is made that the information necessary for the filtering option is available. For example, if a SEND is issued on a socket that is not bound or not connected, no filtering takes place. In addition, the following describe some of the special considerations for the different socket calls in the previous table.

Even though the remote IP address is available after an ACCEPT call, it is not used for filtering the exit ACCEPT trace record. This is done to avoid confusion where the entry trace record for ACCEPT would not be filtered, but the exit trace record would.
Assumes a BIND issued for a nonzero port. If a BIND is issued for port 0 (meaning an ephemeral port is assigned by TCP/IP), no filtering takes place for this BIND call.
If the socket is bound at the time of the CONNECT, local port filtering is honored. Otherwise, the CONNECT is not subject to local port filtering.