Through NETCON, an online user can enable and disable lines and otherwise affect a line's availability, and can change FEP control parameters that will influence performance characteristics.
The NETCON commands used to modify the network and their functions are listed below:
Command CONFIG
DELETE
116
Change Function
Change line configuration parameters (i.e .• the default flags and parameters in a FEP
Channel Table that specify how the channel is to be used.
Delete a node or pseudo resource.
Maintenance Through NETCON Module 5-1
CE6e-ee
DISABLE DISCONNECT ENABLE KILL DISPLAY
PARTITION RETURN SELECT SET
Change channel line availabi lity.
Display the current values of boot information, the network nodes, pseudo-resources, or NETCON
control led parameters.
Remove channels from system use and make them avai lable for test and diagnostics. and return them to system use.
Select a network node or handler for display/
change operations.
Change NETCON control led parameters on a per host, per FEP or per handler basis.
Note that the CONFIG, DISABLE, DISCONNECT, ENABLE, KILL. PARTITION. and RETURN commands can all identify terminals. controllers. and subdevices via:
o a hexadecimal channel number (which must be preceded by a period) that is the address of the physical channel corresponding to the terminal.
o the terminal name as defined via SUPER.
Changing Line Configuration Parameters
Line configuration options define the class of device. set line values such as buffer sizes, character transmission blocks. line status, input/ output characteristics, CP-6 environment characteristics (the logon, the profi Ie) for the I ine and many others. The NETCON Line Configuration Option Table in the System Support Reference Manual details the options and the parameters that they control.
Changing Boot and Handler Parameters
The procedure to change a node definition is to:
1. Use the NETCON processor SELECT command to select the node.
2. Use the NETCON processor SET BOOTINFO command to change the handler or other boot information.
In online mode. the user is prompted to enter the information. As each item is prompted for, its current value is listed.
The NETCON processor SET command can also be used to change a number of boot-time control parameters, general handler parameters. ASYNC-specific handler parameters, FEI handler parameters. and node administrator parameters. These parameters are al I described in the SET Command Parameters table in the NETCON section of the System Support Reference Manual.
CE60-00 Changing Boot and Handler Parameters Module 5-1
117
Module 6-1
Introduction to Response and Throughput Tuning Tools
This module introduces the reader to various tools contained in the CP-6 system that are used to obtain the maximum performance from a CP-6 system. System tuning techniques differ depending on how the CP-6 installation has been configured and the nature of the
inefficiencies the tuning is meant to correct. But. the basic approach for use of the tools introduced in this section is always the some: the recommended CP-6 system tuning approach involves establ ishing a basel ine .of performance for a part icular CP-6
installation. and then recognizing deviations from this baseline.
Once the baseline is establ ished. the deviations need to be examined more closely:
first. determining the type of problem which has presented itself; then. focusing even more closely in order to determine the couse. and thus the remedy. for the deviation.
Occasionally the detecting of problems is not quite so analytical. and requires vigilance and intuition to ferret out the cause.
This module:
o categorizes the kinds of system performance problems that can arise and
o identifies in a general way procedures and tools available for detecting these problems.
Module 6-2 is an example of how system statistics used in analyzing system performance problems can be gathered. Module 6-3 is a more detailed examination of how CP-6 processors can be used to tune a system.
There are several aspects to performance of a CP-6 system. Each aspect may exhibit itself as a different type of problem. even though the problems may superficially appear to be the some. It is very important to identify the particular type of problem. in order to administer the proper corrective action. The following aspects of performance will be examined in this Introduction:
o Responsiveness o Throughput
o Memory utilization o Input/output throughput o FEP throughput
As a general technique it is recommended that most CP-6 installations constantly run STATS as a batch or ghost job to keep a log of system performance activity. Module 6-2 contains an example of how to run STATS as a ghost job. If a STATS log of system performance activity is maintained. STATS can be used to analyze the normal operating profile of the installation. This technique can also be used to assist in predicting the need for additional equipment.
Given that STATS is being used to analyze the normal operating profile of an
installation. the next step is to identify the existence of problems. Basically. there are two ways to do this. The first and recommended approach is to regularly watch the statistics being gathered to detect anomalies. The second. and generally less
satisfactory. is to wait for complaints from the user of the system.
CEse-ee
Introduction to Response and Throughput Tuning Tools 119 Module 6-1Once a problem has been identified. the next step is to classify the problem into one of the five areas mentioned above. For each type of problem. the next step is to use the tools to focus in on the particular problem. solve the most severe problem. and then re-examine the situation to see if a serious problem still exists.
Ways to recognize each of the types of problems are discussed below. The discussions which follow al I assume that a system is adequately configured and has experienced adequate performance. The techniques given are intended to identify changes in performance characteristics in a system and to assist in obtaining the maximum from a CP-S system.
Responsiveness
CP-S responsiveness performance can be divided into three areas: time-sharing responsiveness. batch responsiveness. and transaction processing responsiveness.
Tme-shamg Responsiveness
Time-sharing responsiveness ("Gee. the system seems to be responding slowly today") can be divided into three categories:
o Host response o FEP saturation
o Input/output bottleneck
This section examines Host response problems. If a time-sharing responsiveness problem is not related to host response. then it is related to either FEP saturation or an input/output bottleneck. These aspects of performance are discussed as separate topics.
below.
A host response problem manifests itself in one of two ways: slow response to trivial tasks. and slow response to more substantial compute-bound tasks. The response time to trivial tasks is the response time printed by the STATS processor. and problems of this type can be diagnosed directly from STATS. If this value is not in a desirable range.
it can be affected by adjusting the various QUAN. QMIN. and PRIO values using the CONTROL processor (see Module 6-3).
The response time to more substantial tasks is reflected in the ETMF (Elapsed Time Multiplication Factor) figure as reported by STATS. Abnormally high ETMF values signify
throughput problems which are discussed below.
TP Responsiveness
This class of problems can be due to Host transaction bottleneck. FEP saturation. or on input/output bottleneck on the files or database in question.
If a number of transactions are not queuing up in the host for processing. then the problem must be an FEP saturation problem. The FPL programs should be examined for inefficient code.
If the problem is not in the FEP. the problem may be caused by an input/output
bottleneck contention for TPAPs or a throughput problem. Input/output bottleneck and throughput problems are discussed in a separate topic. below. If the problem is due to contention for TPAPs. the transaction load should be analyzed carefully. and the most heavily used TPAPs should be considered for PERM status. (Refer to the publication CP-S TP Administrator Guide (CES0) for more information on TPAPs and PERM status.)
120 TP Responsiveness CESe-e0
Module 6-1
Batch Responsiveness
Batch responsiveness is basically batch turnaround. The CONTROL processor can be used for batch turnaround problems to examine the particular definitions and the number of jobs running in each partition. Consideration should be given to establishing express partitions for fast turnaround of jobs with I imited resource requirements.
Throughput
This section is concerned with CPU uti I ization problems and CPU users that create such problems. Generally, a CPU throughput problem is signal led by anomalously high ETMF.
The high ETMF is usually due to one or more heavi Iy used programs that are somewhat inefficient. To proceed further in this kind of problem analysis, the heaviest user of CPU time must be identified. The program ST.X(H) is the most useful tool for this
purpose. ST.X(H) wi I I take a 30-second snapshot of the system, and report the top six users of CPU time, memory, and input/output.
Having identified the suspects, the next step is to determine whether the problem is an execution time or service time problem. The easiest way to make this determination is with ST.X (sysid), which wi I I report the usage of a particular user of execution and service time.
If it is determined that the throughput problem is a service time problem with a
particular user, the best way to proceed is to use the MOUSE feature of STATS, reporting on the user in question. MOUSE provides a report of al I of the monitor services used, along with various statistics about the monitor services. (Refer to the CP-6 System Support Reference (CE41) for more information on the MOUSE feature of the STATS
processor.) The program can then be analyzed to determine if it is doing unnecessary or inefficient operations.
If it is determined that the throughput problem is an execution time problem, the best way to proceed is to use PMON.X to determine the execution time profi Ie for the program.
Usually, these steps will be enough to locate the problem so that the inefficient code can be eliminated without further difficulty. After having el iminated the principal offenders, the program should be re-examined for further problems.
Frequently, a program wi I I have a problem with both service and execution time, in which case both of the just described techniques should be used.