Fast path support

For applications that have strict communications path length requirements, a fast path extension is provided to further reduce z/OS® UNIX-to-TCP/IP stack communications. This extension is available to applications that use the UNIX System Services socket API, the z/OS XL C/C++ Runtime Library functions, and the native MVS™ socket APIs (such as C/C++, EZASMI macro, EZASOKET, REXX, or CICS® socket APIs) provided by the Communications Server. It is not available to applications that are using the Pascal API.

With fast path support, communications are reduced for the following socket system calls:

send()
recv()
sendto()
recvfrom()
sendmsg()
recvmsg()

These performance enhancements are also available for the corresponding socket system calls on the z/OS UNIX asynchronous socket interface (BPX1AIO).

Rule: Automatic fast path support is activated by default.

Automatic fast path support does not have the limitations that exist with the fast path support that requires activation (see Activating fast path support). Most notably, automatic fast path supports POSIX signals.

Restriction: Because automatic fast path supports POSIX signals, applications that cannot handle interruptions by signals must continue to explicitly activate fast path support to use it. For more information about explicitly activating fast path support, see Activating fast path support.

Activating fast path support

You can activate this feature for an entire z/OS UNIX process by using the z/OS UNIX environment variable _BPXK_INET_FASTPATH. The value of this variable determines whether a socket application is marked fast path. An XL C/C++ application can set the variable by using the setenv function, or you can export the variable to the z/OS UNIX shell environment before the socket application is started. An application that is using the z/OS UNIX API can set this variable by using the BPX1ENV service.

Rule: z/OS UNIX environment variables have a process-wide scope only; that is, they usually affect a single MVS address space only. For multiple UNIX processes within a single address space, the setting of this environment variable might vary for each process within the address space. It is not a problem if some of your applications use fast path services and others do not.

If you are using the _BPXK_INET_FASTPATH environment variable, the following restrictions apply to applications that are using the UNIX System Services socket API or the z/OS XL C/C++ Runtime Library functions:

Applications are not compliant with the X/Open Portability Guides (XPG), and POSIX signals are not supported. Applications can be interrupted only with the SIGKILL terminating signal.
You cannot use the interactive z/OS UNIX DBX debugger to debug an application. However, you can use the DBX debugger to develop and test an application without setting the environment variable, and then run the application in production with the environment variable set.

For environments that do not use common INET, set the value of this variable to the name that is specified on the TYPE parameter of the FILESYSTYPE statement in the BPXPRMxx parmlib member.

For common INET environments, the value that is used to set the environment variable depends on whether the application is using the TCP or UDP protocols. In a common INET environment, set the variable as follows:

For UDP applications, set it to the name of the TCP/IP stack as specified on the NAME parameter of the SUBFILESYSTYPE statement in the BPXPRMxx parmlib member. The socket application is explicitly associated with the TCP/IP stack name specified in the environment variable. This means that the socket application can communicate with accessible partners only through the specified TCP/IP stack interfaces. For UDP, the environment variable overrides the common INET support. Take this contingency into account before you activate fast path for a UDP application.
Rule: You must use the _BPXK_INET_FASTPATH environment variable for UDP applications that require fast path support and affinity to a specific TCP/IP stack. If a UDP application establishes affinity to a specific TCP/IP stack by using other means, such as by setting the _BPXK_SETIBMOPT_TRANSPORT environment variable or by using setibmopt() or BPX1PCT, the setting of the fast path variable is ignored.
For TCP applications, you can set the variable to an asterisk (*) to associate the application with any TCP/IP stack in the common INET configuration. This method allows all TCP/IP stacks that support the fast path model to obtain the fast path performance benefits automatically. TCP servers are not bound to a specific TCP/IP stack, even if the server specifies a specific TCP/IP stack name on the environment variable; instead, the server can listen for inbound connections across all TCP/IP stacks. When a connection arrives from the TCP/IP stack that is named in the environment variable at the time of the accept() call, it is automatically marked as fast path. Connections that arrive from TCP/IP stacks that are not named by the current environment variable value are not marked as fast path.
Guideline: Certain TCP/IP API functions, such as the resolver services [gethostbyname(), gethostbyaddr(), getaddrinfo(), and getnameinfo()] and the network interface identification services [if_nameindex(), if_nametoindex(), and if_indextoname()] use UDP sockets internally for their processing. If a specific TCP/IP stack name is specified on the environment variable, these hidden UDP sockets are associated with only the named TCP/IP stack, which might have undesirable effects. For example, any resolver API queries that result in communications with a domain name server occur only over the specified TCP/IP stack. As a result, it is best that TCP applications set the environment variable to the special asterisk (*) value. If the application requires affinity to a specific TCP/IP stack, it can do so by using any of the facilities that are provided by z/OS UNIX, such as setibmopt() and BPX1PCT. For more information about establishing affinity to a specific TCP/IP stack, see z/OS UNIX System Services Planning.

Applications can also enable fast path processing for a single socket by issuing the Iocc#FastPath IOCTL for the socket, or by using the w_ioctl() or the BPX1IOC APIs. This IOCTL is effective only if it is issued against a socket that is already associated with a specific TCP/IP stack. Sockets are considered associated with a specific TCP/IP stack if they meet any of the following conditions:

The application has explicit process affinity to a specific TCP/IP stack by setting the _BPXK_SETIBMOPT_TRANSPORT environment variable, or by using setibmopt(), BPX1PCT, or other methods.
TCP/IP stack affinity is explicitly established for this socket by using the SIOCSETRTTD IOCTL.
A bind() is already issued for the socket with a specific IP address, and not the IPv4 INADDR_ANY address or the IPv6 unspecified address, in6addr_any.
A TCP streams socket that is connected, which includes TCP sockets that are returned as a result of accept() or sockets for which a connect() is issued.

The Iocc#FastPath constant is defined in the BPXYIOCC. This IOCTL requires a 4-byte argument as input. Set this argument to a nonzero value to activate fast path, or a zero value to disable fast path on the specified socket.