The Suite Spot

(Originally posted 2017-01-15.)

What is a batch suite?

That might seem like a silly question to ask but it’s inspired by some significant enhancements to our Batch reporting. Dave Betten and I have worked hard on these as time permitted over more than a year.

Traditional Definition Of A Suite

Traditionally, a batch suite is a set of related jobs, usually with some kind of a naming convention that makes them recognisable.

Such a naming convention might be ‘all jobs whose names begin with “XYZ” comprise the XYZ suite’.

Now, following a naming convention like this doesn’t guarantee relatedness. And not all naming conventions look like this. In fact many don’t.

Our Traditional Suite Reporting

Our motivation for reporting at a suite level is twofold:

• Customers understand suites – because that’s how they designed their batch.
• It’s a mid-way point in the hierarchy – between batch service classes / workloads and individual jobs.

So we use suites as a way of structuring the batch conversation.

We produce suite-level reporting (for the past 25 years) comprising such elements as:

• A summary of the suite
• Which jobs in the suite are released together
• Job statistics
• Step statistics
• Job start delays
• Data sets accessed by the suite
• DB2 access by the suite

This set of reports has evolved somewhat over the years, and I’m skipping a lot of the detail.

What hadn’t changed was how we determined which jobs were in the suite: We were restricted to:

• An explicit list of jobs – cumbersome to compile and manage.
• Jobs with a single specific leading character string – in the spirit of “XYZ” above.

Neither of those is entirely satisfactory – so we got to work.

Enhancements To Our Tooling

• As well as filtering on leading characters of a job name we can also filter on trailing characters (which we call “suffixes”).

Originally we only allowed one suffix. Now we allow multiple. For example “D”, “M”, “W”, “Q”.

• We allow filtering on Service Class and Report Class
• We allow filtering on Elapsed Time and CPU Time

As we’ve done this we’ve slowly re-architected the code and tweaked a few things, too. So, for example, we see all the RACF userids and group names.

How This Refines Our View Of A Suite

I guess we’re getting away from real suites with some of this. And this is a good thing:

• A question we get asked a lot is how to reduce CPU – usually for software billing purposes – and so a pseudo-suite called “Big CPU Burners” is really handy.
• When trying to reduce someone’s batch window a pseudo-suite called “Long Elapsed Time Jobs” helps.
• Knowing which jobs are in e.g. “PRDBATHI” Service Class can be useful.

But we also have much more flexibility in defining real suites:

• We have the extensions to job name filtering I mentioned above.
• Sometimes customers will define a Report Class for a particular application.

So I think we’ve made real progress and it’ll enable us to help customers much better.

But I share all this because it might get you thinking about how to analyse and manage your batch estate better, too. For example, making more use of Report Classes to document suites could be handy. That would require cross-functional cooperation – between the people who create the JCL and the schedule and the WLM Keeper.

But a parting word on the value of real suites:

It’s really handy, when doing deeper analysis, to see a job’s predecessors and successors. So a pseudo-suite of “high I/O jobs”, for example, is unlikely to include many neighbours like that.