This post is part of a series exploring the unique aspects and capabilities of WebSphere Liberty when running on z/OS.
We'll also explore considerations when moving from WebSphere traditional on z/OS to Liberty on z/OS.
To start at the beginning, follow this link to the first post.
---------------
Last time we talked a lot about how WLM tries to manage different things running on a z/OS image based on the goal of the service class the work is assigned to. This week I’m going to try to take a high level look at how WLM knows which stuff has which goal, also known as classification.
In WLM’s configuration (known as a policy) you’ll have defined some service classes and some report classes. Service classes we’ve talked about. A report class allows you to break up work into different groups to be reported on separately. You might have two applications that fall into the same service class, but because you have to report how you did against the goal separately for those two applications you need it broken out into two reports, thus report classes.
Now you need to define some rules that tell WLM how to assign a service and report class to something running on z/OS. The first thing WLM needs to know is what kind of a thing is this that’s running. Is it a TSO user? A started task? A WebSphere thing? There will be separate sets of classification rules for each kind of thing.
The rules for classifying a started task are grouped together under the STC workload type. So what identifies one started task as being different from another? How do you know this address space is TCP/IP vs. APPC, for example? Well, that’s usually the name of the started task itself. So, easy enough, you define rules for STCs (called a subsystem type in WLM, not to be confused with z/OS subsystems, of course). In those rules you’ll list different names and the corresponding service and report classes that should be used for each started task.
Ok, so if you start a Liberty server as a started task, you can use the STC subsystem rules to assign that server to a service and report class. We’re done, right? Well, maybe. But your goal for something like Liberty is probably a response time goal and being treated as a started task, WLM can’t see request processing begin and end so it has no idea what response times are for this server so it can’t manage it. While you will classify the server as a started task, that goal is really only useful during start up and initialization. Once it starts processing work you’ll want it handled differently.
WLM needs to be able to see the start and end of each request processed. To do that Liberty needs to call WLM to tell it when that happens. And, while we’re telling WLM a new request is starting, we’ll also give it some information to help WLM understand what kind of work it is (i.e. how to classify it).
Work running inside WebSphere gets classified using the CB subsystem (CB stands for Component Broker which was WebSphere’s original name back in the late 90s). For granularity within a subsystem WLM provides a set of generic attributes that can be used for classification. WebSphere uses the Collection Name (CN in the classification rules) and Transaction Class (TC).
In WebSphere traditional the Collection Name was the cluster name (short). In Liberty it is essentially the server name, although you can configure a different value so you can group servers together by assigning them the same Collection Name value for classification purposes.
That leaves us with the Transaction Class. How Liberty determines a transaction class depends on the type of request being processed, and that’s the subject of the next couple of posts.