Figure 1. Overview of the performance procedure

The following procedure describes each step shown in Figure 1.

1. Get LOGREC output.

   Performance problems are often caused by hardware errors. These hardware errors cause software error recovery processing to occur, which degrades system performance. For this reason, you should get the LOGREC output. LOGREC might show many hardware errors for a particular device or group of devices. If the errors are limited to a single device, a hardware error is probably the cause. If the errors are displayed on many or all terminals of one type, software is more likely to be the problem, although hardware might still be at fault. If you suspect a particular device type, add it to your documentation list.

2. Examine the system console log.

   The system console log might contain messages that help diagnose a problem. Add the message ID to your documentation list. The message prefix is IST, IUT, IVT, ELM, or IKT.

   The system console log might also contain information about command problems. For example, operator commands might be taking too long to complete. Add the command name (for example, VARY ACT) to your documentation list.

3. For TSO/VTAM, see Collecting documentation for TSO/VTAM problems.

   If you are using TSO/VTAM, go to Performance problems. If you cannot resolve the problem with that procedure, return to this procedure.

4. Get tuning statistics.

   If the performance problem is associated with traffic through a channel-attached host, a channel-attached communication controller, a channel-attached SNA physical unit, or multipath-channel-attached resources, it might be helpful to get tuning statistics for VTAM. (For more information about tuning statistics, see Modifying tuning statistics.)

5. Get output from the SMS (buffer use) trace.

   You might have enough information to identify the problem. If so, go to Reporting the problem to IBM. If you do not, continue with this step.

   1. Buffer pool expansion can cause performance problems. During VTAM initialization, error recovery, and VARY command processing, buffer usage is higher than normal. If buffer expansion is used, buffer pools should not expand except during such peak periods. Thus, what appears to be high buffer usage could be normal depending on the level of system activity.

      Run the buffer use trace (TYPE=SMS). For information on how to start the trace and examine the output, see SMS (buffer use) trace. Coding the SNAPREQ start option causes trace entries to be written more often, providing a more comprehensive picture of buffer usage.

   2. Using the time stamps in the system console and buffer use trace, correlate an excessive number of buffer pool expansions or large number of buffers used from a single pool with network activity recorded on the console. Constant high usage of a buffer pool might show that not enough buffers were allocated at VTAM initialization to properly support the level of network activity. Also look for a buffer pool that continually grows; buffers might not be released by some VTAM routines. Add the name of an active buffer pool (for example, LPBUF or IOBUF) to your documentation list.
6. Get output from the network controller line trace.

   If an IBM® 3710 Network Controller is installed, start the network controller line trace. This traces information passing over the lines to and from a 3710. [For more information about this trace, see Network controller line trace (3710 only).] Print the trace output with TAP.

7. Get additional documentation.

   If no solid indication of a problem is apparent, run the VIT with OPT=(PSS,API,SSCP,PIU ) and MODE=EXT. This creates a history of VTAM activity. At the time of performance degradation, stop VIT and take a console dump of VTAM. (See your operating system manuals for information about how to take a dump.) Load the dump and trace output for future reference.

8. Report the problem.

   Go to Reporting the problem to IBM.