Workload Manager: Difference between revisions

Content deleted Content added
See also: del Category:IBM mainframe technology
m Fixing wikilink for sysplex article(s)
Line 10:
[[Image:ExVel02.jpg|thumb|400px|Definition of Execution Velocity|left]] This measurement is based on system states which are continuously collected. The system states describe when a work request uses a system resource and when it must wait for it because it is used by other work. The latter is named a delay state. The quotient of all using states to all productive states (using and delay states) multiplied by 100 is the execution velocity. This measurement does not require any communication of the application with the WLM component but it is also more abstract than a response time goal.
 
Finally the system administrator assigns an importance to each service class to tell WLM which service classes should get preferred access to system resources if the system load is too high to allow all work to execute. The service classes and goal definitions are organized in service policies together with other constructs for reporting and further controlling and saved as a service definition for access to WLM. The active service definition is saved on a couple data set which allows all [[z/OS]] systems of a [[IBM Parallel Sysplex|Parallel Sysplex]] cluster to access and execute towards the same performance goals.
 
WLM is a closed control mechanism which continuously collects data about the work and system resources; compares the collected and aggregated measurements with the user definitions from the service definition and adjusts the access of the work to the system resources if the user expectations have not been achieved. This mechanism runs continuously in pre-defined time intervals. In order to compare the collected data with the goal definitions a performance index is calculated.
Line 19:
A major difference to workload management components on other operating systems is the close cooperation between [[z/OS]] Workload Manager and the major applications; middleware and subsystems executing on [[z/OS]]. WLM offers interfaces which allow the subsystems to tell WLM when a unit of work starts and ends in the system and to pass classification attributes which can be used by the system administrator to classify the work on the system. In addition WLM offers interfaces which allow load balancing components to place work requests on the best suited system in a parallel sysplex cluster. Additional instrumentation exists which helps database and resource managers to signal contention situations to WLM so that WLM can help the delayed work by promoting the holder of resource locks and latches.
 
Over time [[z/OS]] Workload Manager became the central control component for all performance related aspects in a [[z/OS]] operating system. In a [[Parallel Sysplex]] cluster the [[z/OS]] Workload Manager components work together to provide a single image view for the executing applications on the cluster. On a [[System z]] with multiple virtual partitions [[z/OS]] WLM allows to interoperate with the [[LPAR]] [[Hypervisor]] to influence the weighting of the [[z/OS]] partitions and to control the amount of CPU capacity which can be consumed by the logical partitions.
 
== Literature ==