3. PERFORMANCE ANALYSIS TOOLS › 3.1 Batch Initiator Simulation › 3.1.4 Analytic Technique Tutorial

3.1.4 Analytic Technique Tutorial

An initiator is a multiclass server that selects jobs for
processing by an MVS system.  By specifying the number of
initiators and the job classes each serves, you can limit the
number of jobs given access to the system (that is, the
system's multiprogramming level), provide different levels of
service to various job classes, and allow the operating
system to perform the majority of the job scheduling
functions.

Because the behavior of an initiator structure that is
comprised of many multiclass initiators is difficult to
predict, the CA MICS Performance Manager Option includes an
initiator simulation that allows you to determine the
behavioral characteristics of alternative initiator
structures at your installation.

One of the most extensive uses made of initiator structures
is to provide various levels of service to job classes in
testing environments.  The model provided by the CA MICS
Performance Manager Option defines service as the length of
time between when a job arrives and when it is selected for
execution (that is, the input delay).

You should not use the model to evaluate initiator structures
for production jobs because the flow of production jobs is
constrained by dependencies and operator-imposed holds rather
than by the availability of initiators.

In developing the model, one important decision was to select
the level of detail at which the initiator process would be
modeled.  Basically, this was a choice of whether or not to
model the execution (server holding time) of jobs in detail.

Using highly complex queuing models, other investigators have
concentrated on the effects of job interactions on execution
time.  However, in a testing environment, job execution times
are often quite small in comparison to their input queuing
delay.

To allow the investigation to concentrate on modeling the
input queuing delay phenomenon, the model provided by the
CA MICS Performance Manager Option assumes that the execution
time of a job is unchanged when executed under a new
initiator structure with a multiprogramming level less than
or equal to the environment in which the jobs were originally
executed.

Although this assumption initially seemed quite weak,
investigations of average execution times of a number of
resource-limited job classes revealed only small variations
in execution time for a variety of multiprogramming levels.
Moreover, actual experiences with the model, which are
discussed in the case study in Section 3.1.5, have shown the
effects to be negligible when the multiprogramming level
decreases or is unchanged, provided that each class consists
of jobs that have relatively small, homogeneous resource
demands.

The input data for the model is selected from the DETAIL
timespan of the CA MICS BATJOB and BAT_JS Files. These files
contain one record for each job executed by the system.  The
model uses the following data elements:

  o  JOB - job name

  o  JOBPRTY  - the priority at which the job was submitted

  o  JOBCLASS - job class

  o  JOBINQTM - job input queue time, T1

  o  JOBENQTM - job enqueue time, T2

  o  JOBALCTM - job allocation time, T3

  o  JOBEXCTM - job execution time, T4

  o  ENDTS - execution end time stamp, T5

When the job records for a system are sorted in ascending
order by reader time, they provide a stream of arrivals for
driving a simulation model.  A job's actual queuing delay is
T1, server holding time is measured as T2+T3+T4, and actual
throughput is estimated using T5.  As previously stated, the
simulation model assumes that a job's server holding time
remains unchanged, and the model determines the queuing delay
under the new initiator structure.

Based on the simulation clock step value (see Section
3.1.6.2.9), job execution times are rounded.  This makes the
results of the model somewhat pessimistic and reduces the
execution time of the model.  Moreover, rounding the
execution times upward elongates the execution time of each
job by a few percent, allowing for small changes in execution
time that may result from new job mixes.

There are a number of influences on initiator and job
activity that are not recorded in the SMF log file and thus
cannot be accurately reproduced by the model.  These
influences are introduced by operator and user interactions
with the system.  For instance, the operator or user may:

  o  Modify the priority of a job to change its position in
     the input queue.

  o  Put a job into a hold status to prevent or delay its
     execution.

  o  Modify the initiator structure.

Generally, these operator and user interactions are minimal
in a well-managed system.  For any given system, you can
determine the usual extent of these activities by
investigating the console log where operator actions are
recorded.