When a client hang occurs, the general UNIX netstat (or TSO netstat or z/OS shell onetstat) command can be used to determine whether this could be a socket hang problem. If the netstat command is issued on the failing client system and it shows that a very large number of TCP sockets are in CLOSEWAIT state with the destination IP address of the z/OS NFS server, it indicates that sockets are probably hung (z/OS NFS server may not accept new TCPIP connections). In this case, it is very probable that the diagnostic trace data recorded by the z/OS NFS Server is already lost by the time that the hang is recognized at the client. The only thing that can be done to resolve the immediate situation is to restart the z/OS NFS server.

Once the z/OS NFS server is restarted, it is recommended that the MODIFY sockhang command is used to help capture the necessary diagnostic data before it is lost the next time that this situation occurs. This command tells the server to monitor the server's sockets for potential hang conditions and to create a dump when a hang is suspected so that the diagnostic trace data can be captured before it is lost. For details on the MODIFY sockhang command, see Entering operands of the modify command for diagnosis.

z/OS NFS client users can also experience a hang when trying to update a data set concurrently on an NFS mount point that was mounted with the text processing attribute and the attrcaching(y) parameter while the same data set is also being updated by users and applications via mechanisms outside of the NFS protocol. To avoid this hang situation, the following is recommended:

1. If possible, avoid simultaneous concurrent updates to a data set by users and applications through NFS protocol and non-NFS protocol methods.
2. Otherwise, establish the corresponding NFS mount point with the attrcaching(n) parameter or the binary processing attribute.

For other possible causes of a client hang, standard problem analysis techniques should be used.