Previous Topic: 3.1.1 Functional DescriptionNext Topic: 3.1.3 Standard Output


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.