z/OS constraints

Table 1 contains z/OS constraints information. These actions should be weighed against any increase in z/OS storage they may require.

Table 1. z/OS constraints symptom and action information
Symptom	Action
High CPU utilization with low aggregate throughput	ACTION 1: Increase z/OS TCP/IP send and receive buffers - There are other applications besides z/OS NFS which are dependent on the z/OS TCP/IP application. Some applications have different tuning requirements. The default values for udpsendbfrsize (or tcpsendbfrsize) and udp udprcvbrfsize (or tcprcvbrfsize) is 16 KB. It may be useful to increase these parameters up to 64 KB for better throughput with large files. ACTION 2: Increase z/OS TCP/IP UDP queue - Another area to consider is the z/OS TCP/IP UDP queue. As discussed in section NFS client system performance tuning, NFS responses are dropped when network adaptor queues are full. A similar situation occurs when the UDP queue of z/OS TCP/IP is full; in this case incoming NFS requests are dropped. The noudpqueuelimit keyword in the assortedparms section of the TCP/IP profile data set can be specified to enable the z/OS TCP/IP server to accept incoming UDP datagrams. Without specifying this keyword, the default queue length of 30 may not be sufficient. ACTION 3: Modify NFS and TCP/IP dispatching priorities - It is recommended that the z/OS NFS procedure have a relative dispatching priority less than that of TCP/IP. This is important because the MVS mean time to wait dispatching priorities are adjusted based on increased I/O activity. Since TCP/IP has higher network I/O than z/OS NFS, the TCP/IP dispatching priority is lowered. Assigning fixed dispatching priorities, with TCP/IP dispatched at a higher relative value than the z/OS NFS, can ensure this situation. ACTION 4: Select transport protocols - z/OS NFS supports TCP and UDP as transport protocols for the server, for both NFS Version 2 and Version 3 protocols. For the Version 4 protocol, NFS supports only TCP as a transport protocol. UDP is primarily used for its efficiency on high bandwidth, low latency networks, such as LANS. TCP is used for its efficiency on low bandwidth, high latency networks, such as WANS.
Constrained throughput with low CPU utilization	ACTION 1: - See Subtasking.
High DASD utilization and NFS command response time	ACTION 1: Evaluate placement of z/OS catalog data sets - The performance of z/OS NFS will be impacted when serving files located on heavily utilized storage devices or devices behind congested storage controllers. Before deciding whether or not to move data or upgrade storage systems, make sure system catalogs are not on heavily utilized devices. Many of the NFS commands that are executed for z/OS conventional MVS data sets involve catalog access. In fact, listing directories, one of the most commonly executed commands on NFS client systems, accounts for a significant portion of the NFS get attribute and lookup commands. Such commands not only cause the z/OS catalog to be accessed but might also cause the entire file to be read depending on: z/OS NFS processing options Prior access by z/OS NFS Whether or not files are DFSMS-managed ACTION 2: DFSMS-managed data accessed from the network - Files that are primarily accessed by way of z/OS NFS should be DFSMS-managed for improved performance. The z/OS NFS maintains file attributes for DFSMS-managed data sets when the z/OS NFS nofastfilesize processing option is specified. The nofastfilesize processing option provides exact file size determination rather than approximating file size as with the fastfilesize processing option. DFSMS management also provides improvements in terms of better storage utilization and specification of service levels. ACTION 3: Evaluate placement of data accessed from the network - While deciding whether or not to access DFSMS-managed files using z/OS NFS, consider also the placement of such files. Files with critical performance requirements should be placed on the appropriate devices by using the storage class parameters. If reallocation is necessary, you might also consider allocating sequential access method striped data sets for larger files or a z/OS UNIX file for smaller files. If you elect to maintain data set organization, you may choose to reblock the data set to a more optimal block size, such as half track blocking. You may even determine for some files that the best alternative is to store the files locally on the NFS client system.