Rule TSO212: The maximum MPL probably is too low for TSO domain
Finding: CPExpert has determined that a potential cause of unacceptable
response is that the maximum MPL is too low for the domain
servicing TSO trivial transactions.
Logic flow: The following rules cause this rule to be invoked:
TSO001: TSO response time is unacceptable
TSO100: TSO transactions are swapped out
TSO200: TSO transactions are swapped out in Active State
TSO210: The target MPL is too low for TSO domain
Discussion: The maximum MPL establishes the upper limit of a domain's target
MPL. The target MPL is the maximum number of transactions that
may be swapped in at any one time.
If the domain's maximum MPL does not allow that target MPL to
rise high enough to accommodate all ready TSO transactions,
newly-ready transactions must wait until either (1) the SRM allows
an Exchange on Recommendation Value swap or (2) transactions in
storage complete.
Exchange on Recommendation Value swapping of TSO trivial
transactions is extremely detrimental to performance in systems
without extended storage. The exchange swapping should be
prevented by specifying an ISV value greater than the DUR value (or
allowing the ISV to default to 100,000 service units). The SRM
Component of CPExpert will fire a rule if the ISV for TSO Period 1
or Period 2 is too low. Following the recommendations associated
with this rule will prevent Exchange on Recommendation Value
swaps for TSO trivial transactions.
If newly-ready transactions must wait until transactions in storage
complete (because the ISV value prevents an exchange), the delay
could cause unacceptable response.
CPExpert computes an estimate of the maximum number of ready
TSO users. This computation is the sum of the maximum number
of logically-swapped ready users (SMF70LMM) plus the average
number of active TSO users (SMF72ACT/SMF72INT).
RULE TSO212 fires if the estimated maximum number of ready TSO
users is larger than the maximum multiprogramming value specified
in the CNSTR keyword for the domain serving trivial TSO
transactions.
Suggestion: CPExpert suggests that the maximum multiprogramming value in the
CNSTR keyword for the domain serving TSO trivial transactions be
increased to the value displayed with this rule.
This recommendation is simply a rule-of-thumb. The
recommendation may or may not improve TSO performance. Under
most conditions there is little to be lost by raising the maximum
MPL for TSO Period 1, and (as explained in the discussion section
above) there is much to be lost by having more ready TSO users
than can be accommodated by the target MPL of the domain.
There are at least three circumstances under which a smaller
maximum MPL might be desirable: (1) the burst rate of ready TSO
users creates excessive memory demands, (2) management might
decide that there should always be a limit on the amount of
resources used by TSO, and (3) non-interactive users might use
TSO Period 1 or Period 2.
- Burst rate of ready TSO users. Situations can occur in which
many TSO users come ready within a short period. For
example, the release of a file on which many TSO users are
enqueued might generate a burst of ready TSO transactions
within a short period. This sudden arrival of many TSO
transactions could be more than the real memory could handle,
without causing severe performance problems.
- The SRM certainly can handle memory constraints over a
period of time. However, the SRM is not easily able to
respond to sudden radical changes in demand. If such a
"burst rate" situation occurs, a maximum MPL level might be
desirable even for TSO Period 1. (Some analysts suggest that
60-100 page frames per TSO user should be used to get a
general idea of the total memory requirements implicit in the
maximum MPL of TSO domains. Perhaps a better approach is
to assess the average size of physically swapped users. This
value is computed by dividing the number of physically-
swapped users into the total pages swapped out.)
- Management objectives. The TSO Component of CPExpert
analyzes performance assuming that TSO should be given the
resources required to satisfy interactive transactions. In some
installations, TSO does not have primary priority (e.g., CICS
might be considered higher priority).
In these installations, management might decide to limit the
share of the system's resources that TSO can acquire, even
for the short time that should be required to service interactive
TSO transactions. In these installations, a maximum MPL
might be specified for TSO Period 1 and Period 2 to
deliberately limit the access to system resources provided to
TSO users.
- Non-interactive users execute in Period 1 or Period 2.
In some installations, the IEAICSxx member of SYS1.PARMLIB does not
adequately separate interactive and non-interactive TSO
transactions. In these installations, non-interactive TSO users
can execute work in the performance group periods and
domains assigned to TSO Period 1 and Period 2. In these
cases, a maximum MPL for TSO Period 1 and Period 2 might
be used to constrain the number of users, and thus constrain
the overall demand on system resources. Of course, a much
better alternative is to separate TSO interactive and non-
interactive transactions.
The SRM Component of CPExpert will detect any non-TSO
workloads sharing domains with TSO Period 1 or Period 2, and
issue a rule advising that this sharing not be done. However, non-
interactive work can be submitted under TSO. The SRM
Component is unable to detect this possibility based on its analysis
of the SYS1.PARMLIB members.
There is no information in the RMF Monitor I reports upon which to
base a firm recommendation about the maximum MPL for the
domain serving TSO trivial transactions. CPExpert recommends that
the information be obtained from RMF Monitor II by the following
steps:
- Review the RMF Monitor II Domain Activity report during
periods of high TSO activity.
- Examine values in the "MAX" (maximum MPL) and "MPLT"
(current target MPL) columns opposite the domain serving TSO
trivial transactions.
- If the "MPLT" value is at (or even near) the "MAX" value, the
maximum MPL level should be increased unless management
wishes to restrict TSO use of system resources.
| 