Design your workload categorization

With ThruPut Manager AE, your Policy is your datacenter's statement of intent or commitment to meet specific goals for a category of batch work, while giving that category precedence, relative to other categories, in accordance with its importance. You determine how to classify work into each category, and, for each category, set its service levels and importance.

We call the category of work a Service Group. When assigned to a Service Group, a job inherits its goals and importance level.

Your task is to define a sufficient number of Service Groups to distinguish between the service one category receives compared to another; too many and it's unmanageable; too few and you miss favoring important work during outages or high volume situations.

There are two types of Service Groups: Production Service Groups and General Service Groups. You can have a mix of the two. In either case you use JAL to assign a job to its Service Group.

The substantive differences that may affect your decision are:

Feature/Treatment	PS work	GS work
Name of Service Group	One level name, maximum of 8 characters.	Two level names, each level with up to 8 characters
Support for sets of service groups	n/a	First level of the name, the control center, provides for a “set” of service groups; settings for a control center are inherited by its service groups (set of second level names that share a first level name).
Queue behavior	PS jobs don’t stop aging while waiting for resources such as data sets.	GS jobs do stop aging while waiting for resources such as data sets.
Resource Contention	When waiting for data set recalls, VVS Staging, or enqueue on a data set, PS work with Imp=1 is favored over GS work with Imp=1, and PS (Imp=2) is favored over GS (Imp=2) and so on.
Aging Limit	All PS work ages to Critical	GS work may stop aging at Acceptable. A Critical service time must be explicitly provided.
Aging to critical behavior	Once PS work reaches Acceptable threshold it is optionally placed at one of the Critical thresholds	GS work ages to Critical in the time, if specified, associated with the Service Group
Selection process	Default is for (eligible) PS work to be selected before (eligible) GS work at the same threshold in their respective queues.
Service Class assignment	PS work that reaches a Critical threshold is automatically assigned the Service Class mapped to the next level of importance, i.e., a job with imp=3 is assigned the service class mapped to importance 2.	GS work uses the Service Class mapped to their importance level, regardless of their position in the queue.
Feedback Dialog	Feedback panel for PS work is Production Services Job Display.	Feedback panels for GS work include General Services Job Display, as well as six panels describing the aggregate workload.
Late Job Acceleration	For jobs submitted by supported Job Schedulers, such as Control-M, SLM obtains the time that the job must start and the duration the job is expected to execute.  If the job runs past the must start time plus the duration, it will be assigned the Service Class and mapped to the next level of importance even when the job is executing.	Not applicable to GS work.
Feedback (UDF and Job Summary)		UDF and Job Summary information includes how the job did with respect to its service times.

Production service groups

A production service group is defined in the SLM dialog. For example, the following groups represent a subset of one installations banking specifications: BNKDB for the banking database updates, BNKEXPR for frequent inquiries to refresh various industry indices, BNKPAYR for exceptional payment remittances; BNK as a default for other banking jobs.

Choose names that represent the category of workload. Include a service group to act as a default for this application or collection of jobs. In this way you can start with a few service groups and add more when warranted.

Production service groups are intended to be used for a separation between your scheduled batch and adhoc. While you can use generic queue times within SLM, it is your job scheduler that has the most accurate information about how quickly a job needs to begin execution. Therefore, obtaining timing information from the scheduler allows SLM to better manage production jobs. Regardless of when the job is submitted, it will be aged in the queue based on the specific needs of that specific job. Currently, the job is aged based on the generic target and acceptable times that are defined in the SLM policy. Scheduler intelligence uses scheduler provided job information to calculate the specific target and acceptable times for any given job.

Production services is used to provide this scheduler information to SLM. To activate, an SLM policy must define production service groups. Additionally the job action language, must be used to associate scheduled jobs with these production service groups. Any target or acceptable times that might be provided for these PS groups will be ignored in favor of the specific information the scheduler provides automatically. Of course JAL can be used to honor these hard-coded queue times from the policy instead if the installation desires.

General service groups

A General Service Group is identified by a Control Center and, within that Control Center, a Type. Ideally, your datacenter aligns your General Service Groups with their appropriate business Control Centers. This "business-centric" work categorization is straight-forward if you already have (or are about to take advantage of ThruPut Manager AE to implement) Service Level Agreements (SLAs) with your datacenter's users.

Type is whatever makes sense to your datacenter and its users. In the example, the some of the ad hoc workload for the Banking application is categorized as QA for the quality assurance test runs, DEV for compiles and other development tasks, and, DBUPLOAD for jobs that repopulate test databases.

(As an "easing-in" tactic, General Service Groups can also be based on job class and, optionally, priority. See JobClass-Based Service Groups in the Elective Features section.)