Batch Architecture, Part One
MartinPacker 11000094DH Visits (11103)
First a word of thanks to Ferdy for his insightful comment on Batch Architecture, Part Zero. And also to my IBM colleague Torsten Michelmann for his offline note on the subject.
As I indicated in Part Zero I hoped to talk about jobs in a subsequent post. And this is that post. In particular I want to discuss
Grouping Jobs Into Applications
There are lots of ways of grouping jobs into applications...
Most installations claim a job naming convention. For example:
Your workload scheduler may well have different names for operations (in Tivoli Workload Scheduler parlance) so some care is required with those.
An interesting question is how well an installation observes their naming convention. As the old joke goes "we love naming conventions: We've got lots of them". Analysis of SMF 30 should give you view of whether the naming convention is being observed.
As well as job names it's sometimes interesting to see which userid(s) jobs are submitted under. Often Production batch is submitted from a single userid, according to Type 30. Similarly you can see which job class, WLM workload, service class and report class a job runs in.
Sometimes the programmer name field in Type 30 reveals application information.
Within a window it is occasionally the case that when a job runs is closely related to which application it's in, though usually applications are intermingled in time - to some degree.
... And the above are just examples of characterisation information.
Understanding Individual Jobs - At A High Level
Whether you've grouped jobs into applications or are just looking at individual jobs it's useful to characterise them. Typical characterisations include:
A lot of the characterisation of jobs is centred around standards. For example, how jobs are set up by the installation features heavily in the above list. Other sorts of standards can only be seen in things like JCL.
While the above obviously applies to individual jobs it can equally be applied to applications (as identified above) but it's obviously a bit more work.
This post has talked about how to use instrumentation to group jobs into applications and the like. It's also included some thoughts on how to characterise individual jobs and applications.
I hope in the next part to talk about relationships between applications. And to dive deeper into the application's data.