The Job Analyzer initiators

Define the BMC ThruPut Manager Analyzer Initiators

BMC ThruPut Manager uses the analysis process to collect information about a job and capture that data to pass along to the installation in the JAL (Job Action Language). For installation and verification of the install, you do not require any JAL however you do require a JOB Analyzer Class and an Initiator to process that class.

Do not add other classes to the initiator selecting jobs for the Job Analysis Class or Deferred Analysis Classes. Should such an initiator select a long-running job, no Job Analyzer processing can occur until the long-running job terminates.

If an initiator selecting the Job Analysis Class is started and TMSS is not active, a console message is generated. Job Analysis is suspended until TMSS is started, and no jobs are selected for analysis. When TMSS is started, the Job Analyzer deletes the message and work proceeds. For the Job Analyzer to process jobs, the following conditions must be satisfied:

There is at least one job class to be selected by BMC ThruPut Manager.
An initiator has been assigned the Job Analysis Class.
TMSS is active.

Duplicate Job Names

If your installation has chosen to suppress duplicate job name processing $TJOBDEF,DUPL_JOB=NODELAY, the following comments are irrelevant. If, however, duplicate job name processing is enabled, BMC ThruPut Manager relaxes the JES2 duplicate job name serialization somewhat:

For Job Analysis only, BMC ThruPut Manager can select a job that has the same name as a job that has already been selected for execution or Job Analysis.
For execution, BMC ThruPut Manager extends JES2 to select a job with the same name as one that has already been selected for Job Analysis.

Using JES2 Initiators for Job Analysis Classes

This is the simplest choice because there is no change to the way the Job Analyzer works. Issue $TIn,CLASS=c where "c" is the BMC ThruPut Manager Analysis Class. The number of required BMC ThruPut Manager analyzers depends upon the rate of job submission.

Normally a couple of analyzers active on each member of the JESplex is adequate to keep up with job submission. If you determine there are times when there is a queue waiting for analysis, you may add additional analyzer initiators.

For BMC ThruPut Manager customers, Dynamic Analyzer initiators may be defined.

When the number of Dynamic Analyzer initiators set to a non-zero value, TM will automatically start analyzer initiators. The specified number of analyzers will be started for every 100 jobs in the queue up to the maximum number of analyzers allowed. The installation does not need to set a specific number of initiators (JES2) or a maximum (WLM). The TMPARM ANALYZER= keyword specifies the number of Dynamic Analyzer initiators to be started per 100 jobs on the queue, and the minimum and maximum number of analyzers allowed.

By default, the number of Dynamic Analyzers initiators is 0. This can be altered temporarily via the TM INITS ANALYZERS(n) command or permanently by setting the ANALYZER= keyword of the TMPARM initialization statement.

Details of the TMPARM initialization statement can be found in Section 3: Section 3: TMPARM Initialization Statement.

Using WLM Initiators for Job Analysis Classes

If you choose to allow WLM to manage the Job Analyzer initiators, there are some considerations:

Dynamic Analyzers are functionally disabled and are not used for job analysis processing. This is because Dynamic Analyzers execute under JES2 initiators and will not select jobs for analysis from a WLM job class. If you are using WLM initiators for job analysis processing issue command TM INITS ANALYZERS(0) MIN(0) MAX(0) – or specify TMPARM ANALYZER=(0,0,0) - to turn off the Dynamic Analysis facility.
You should define a WLM service class that handles the Job Analysis class. The goals for this service class should be suitable to deliver fast service to short-running transactions. The service class routine should ensure that jobs in the Job Analysis job class are assigned the Job Analysis service class. Do not use this service class for purposes other than Job Analysis.
WLM controls the number of Job Analyzer initiators only at the JESplex level. You control the total number of Job Analyzers by setting the XEQCOUNT for the Analysis Class, but control at the member level is not available. Additionally, there are a few caveats to using WLM Analyzer initiators.

The TYPHOLD Analysis function does not work with WLM initiators. This is the feature that allows TM to select jobs for analysis despite TYPRUN=HOLD being specified for the job. Without this feature the job will wait on the analysis queue until the end user releases it at which time it will analyze and then be made eligible for execution.
BMC ThruPut Manager support for CNVT_SCHENV=HONOR|IGNORE does not work with WLM initiators. If the job analysis class is a WLM job class, any job that specified a Scheduling Environment will only analyze on a system where the Scheduling Environment is active. If the Scheduling Environment is not active anywhere in the Jesplex, the job waits in the analysis queue until the Scheduling Environment is activated.

BMC AMI Ops Automation for Batch ThruPut customers the recommendation is to make use of Dynamic Analyzers rather than WLM initiators for analysis.

Using JES2 Initiators for Deferred Processing Classes

This is the simplest choice, as there are no changes to the way things worked previously.

Using WLM Initiators for Deferred Processing Classes

If you allow WLM to manage the initiators for your Deferred Processing class, there are several considerations:

You can assign the Job Analysis WLM service class or define a separate WLM service class for the Deferred classes. Because deferred jobs by definition do not need immediate service, a separate service class can have less aggressive goals but still should deliver fast service to short-running transactions. The service class routine should ensure that jobs in the Deferred Processing job class are assigned the correct service class. Do not use this service class for purposes other than Job Analysis.
WLM controls the number of Deferred Processing initiators only at the JESplex level. You can control the total number of Job Analyzers by setting the XEQCOUNT for the Deferred class. Control at the system level is not available.
You can also control the availability of Deferred Processing initiators by defining a scheduling environment for the Deferred Processing class that is not always available.
Because Deferred Processing accumulates jobs, consider the potential WLM reaction when the Deferred jobs are eligible for processing. For example, even if you choose to control the Deferred analysis by the availability of a scheduling environment, you might want to set the XEQCOUNT for the Deferred class to a value that ensures that WLM does not start too many initiators. You might also consider a WLM service class that ignores queue time (e.g., velocity-based).
The same caveats that apply for WLM analysis classes also apply to WLM Deferred analysis classes.

JES2 CNVT_SCHENV Parameter and TM Analysis

The JES2 JOBDEF CNVT_SCHENV parameter indicates to JES2 whether the scheduling environment affinity should be considered for JES2 conversion processing. TM also uses this setting when considering where a job is eligible for Job Analysis.

If CNVT_SCHENV=HONOR is coded, then TM analysis will only occur on systems that match the job's scheduling environment affinity.

If CNVT_SCHENV=IGNORE is coded, then TM analysis will occur on any system that matches the job's system affinity (SYSAFF)

TM provides a customization option to allow TM analysis on any system that matches the job's system affinity (SYSAFF) regardless of what has been defined on the JES2 JOBDEF CNVT_SCHENV keyword. Contact TM Technical Support for more details.

In considering a job's affinity for analysis, an installation should also review the AFFINITY= keyword coded on the TMPARM JES2 initialization statement.