Re: ENDTCPSVR hang on NFS

On 23-Mar-2015 10:06 -0500, Jim Franz wrote:

On 23-Mar-2015 09:21 -0500, Jim Franz wrote:

Last night the ENDTCPSVR hung on the ENDNFSSVR area for over 6 hrs
<<SNIP>>
My question is - NFS is not a TCP Application one can flag as
Autostart *NO (or at least, not on CFGTCP menu option 20).
<<SNIP>>

I had just found the Ops Nav place to not start the server. I still
need to find a system file or API to determine if existing mappings
exist.

The NFS Properties screen:

Remote procedure call started 1
Generic security service started 1
Registry started 1
Block I/O started 1
Server started 2
Mount started 1
Network Status Monitor started 1
Network lock manager started 1

AFaIK the Add TCP/IP Server (ADDTCPSVR) would have defined the various NFS-related servers, including whether to be AutoStart or not, such that those identified with AUTOSTART(*YES) would start with the Start TCP/IP (STRTCP) request when Start Application Servers (STRSVR) specification is *YES; effectively, User-Defined Servers /hitching/ on to the TCP/IP server capabilities for defining and effecting [auto]start and end. The Change TCP/IP Server (CHGTCPSVR) can be used to change them; or of course, the iNav interface already used. The file QATOCSTART in library QUSRSYS and member SERVERS serves as a record of those requests. Although I had always been concerned the program(s) that process those add&chg requests may effect similar changes elsewhere to reflect the changes made visible as records in that DataBase File, e.g. updates to a stream file or an internal data area, such that directly modifying only the data in that DBF may be insufficient, I verified that the docs suggest the use of UPDDTA FILE(QUSRSYS/QATOCSTART) is supported [though for lack of any constraints and triggers, apparently the onus is on the user to provide only supported\valid values]:
<http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/rzaku/rzakuservertable.htm>
_Server table_
"You can use this server table as a reference to find out how servers, server jobs, job descriptions, and subsystems are mapped to one another. ..."

An example of data seen in a member QUSRSYS/QATOCSTART.SERVERS [noting that a later column has the End Cmd showing the matching ENDNFSSVR]; your system may have had AutoStr=*YES for the *NFSSERVERS or one or more of the others?:

Typ Server AutoStr Pgm Lib Start Cmd et al
U NFSBIO *NO *NONE QSYS/STRNFSSVR SERVER(*BIO)
U NFSRPC *NO *NONE QSYS/STRNFSSVR SERVER(*RPC)
U NFSSERVERS *NO *NONE QSYS/STRNFSSVR SERVER(*ALL)
U NFSSMNT *NO *NONE QSYS/STRNFSSVR SERVER(*MNT)
U NFSSNLM *NO *NONE QSYS/STRNFSSVR SERVER(*NLM)
U NFSSNSM *NO *NONE QSYS/STRNFSSVR SERVER(*NSM)
U NFSSVR *NO *NONE QSYS/STRNFSSVR SERVER(*SVR)

<http://www.ibm.com/support/docview.wss?uid=nas8N1016214>
_Description of TCP Servers_
Reference #: N1016214
Historical Number: 330086847
Modified date: 2012-08-25
"...
• NFSBIO : Block I/O Daemon) handles caching and routing to the server when the iSeries is the client. The QNFSNFSD is the server side job on the iSeries.
• NFSRPC RPC : Binder Daemon is the port mapper job and determines the port of a specified RPC service; in this case, NFS.
• NFSSERVERS : All NFS SERVERS
• NFSSMNT : Mount Daemon listens for client requests involving mounting. It is used with every mount or unmount. This job checks to see if the client is allowed to mount over the file system they are requesting.
• NFSSNLM : Network Lock Manager Daemon locks a file system while it is in use.
• NFSSNSM : Network Status Monitor Daemon monitors the status of all clients connected and notifies all interested parties when the state of a client changes.
..."

The Start NFS Server (STRNFSSVR) and End NFS Server (ENDNFSSVR) commands document the additional daemons "Generic Security Service (GSS) daemon" and "Name Registry (RGY) daemon".
<http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/cl/strnfssvr.htm>
<http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/cl/endnfssvr.htm>

The ENDNFSSVR has a Timeout For End of Daemon (ENDJOBTIMO) parameter with a default value of 30 seconds, such that if the specified length of time is exceeded, the command should fail [although the documented escape messages does not list any seemingly applicable to a timeout condition] rather than be in an apparent hang [perhaps due to an excessively long wait time being allowed]. Perhaps worth review if the parameter default was changed to *NOMAX to indicate "Wait forever for daemons to end; do not timeout."