

3. PERFORMANCE ANALYSIS TOOLS › 3.1 Batch Initiator Simulation › 3.1.2 Usage Guidelines
3.1.2 Usage Guidelines
The Batch Initiator Simulation inquiry operates under the
following assumptions.
o Job execution times and queue times are rounded to the
next multiple of the value specified in the clock
update exit (documented in Section 3.1.6.2.4). If you
do not specify a value using the exit, the inquiry
defaults to the largest value that is less than or
equal to the 20th percentile of the incoming data.
This means that simulated data is pessimistic for
initiators that serve a high percentage of very short
jobs.
o The inquiry assumes that the runtime of each job under
the new initiator structure will be approximately
equal to the execution time in the original
environment. Because job execution times are rounded
up as described above, the inquiry allows for small
increases in runtime.
o The inquiry assumes that the number of initiators in
the simulated environment is less than or equal to the
number of initiators in the measured environment.
This assumption minimizes the potential of significant
changes in the characterization of the job mix.
If you expect the mix of jobs to change, use the
Specify Job Input exit documented in Section 3.1.6.2.2
to create new job classes. This allows you to
determine the impact of the new job mix.
o The initiator structure proposed will not result in
resource demands that exceed the available number of
physical resources like mountable tapes or disks.
o When reviewing the reports produced by the simulation,
remember that the jobs processed by the simulation
inquiry are not subject to external dependencies or
operator holds like those experienced by production
jobs.
o The simulation inquiry assumes that two different jobs
with the same job name will not be running in the
system at the same time. If the simulation inquiry
attempts to take a job from the job queue and assign
it to an initiator and finds that a job with the same
name is already assigned to an initiator, it assumes
the second job to be a duplicate and temporarily skips
it. When the first job completes its execution, the
second job becomes eligible for selection. This
mechanism is the same one used by JES2 for managing
duplicate job names.
Copyright © 2014 CA.
All rights reserved.
 
|
|