Customers, running their systems with a “hard” 7x24*365 Defined- or Group-Capacity, often have trouble with unexpected load-situations, putting their systems under pressure and therefore possibly causing additional issues as well. This is exactly why a lot of Mainframe customers passed onto trying to avoid reaching a Defined- or Group-Limit throughout the day. The limits are often set in a way that they are either just reached rarely or only to times in which the consequences are calculable. “Fixed” limits often have nothing or just little to do with the actual SCRT/MLC Software Peak meaning you as a customer are limiting yourself in times in which the software costs aren’t affected at all. In contrast to this you allow MLC Peaks even though there was enough Workload available during the 4 hour time frame which you could have influenced.
Conclusion: You are wasting money. The Mainframe produces unnecessarily high costs.
With the standard (HMC/WLM) tools of IBM an intelligent, consumption minimized control of the LPARs isn’t possible. In order to be able to run your systems on a MSU level as low as possible you need flexible mechanisms which react to changes automatically. zGUARD © offers you all options for this and supervises and operates your systems –independent from the amount of your systems- according to your parameters. Thus zGUARD © can react automatically to changes and alarm you in time before new costs start to arise. Of course zGUARD © will also take over the operation of the systems to react event-based to unpredictable situations.
Mainframe systems offer the possibility to spread the available system resources dynamically. For that purpose with the Workloadmanager (WLM) there are several tools available on the Hardware- (PR/SM) and the z/OS operation system level which control the allocation of the system resources and which steer the processing depending on resource availability. All tools have various interfaces among themselves to control and –if necessary- influence the resource usage of the systems.
Primarily these steering tools are used to assign the present resources as best as possible to the current workload. Thereby an important factor is unconsidered. When a license model is used which charges usage dependent sometimes performance peaks occur which generate costs but which could have been avoided through simple actions. zGUARD © offers you the possibility to develop rules based on permanent ascertained consumption values to distribute system resources according to billing relevant criteria.
zGUARD © is a „Real-Time“ – program for the consumption optimized (MSU/h) operation of your IBM z/OS mainframe systems. Whether it is in this case about the control/ distribution of batch or whether it is about the change of Defined- and Group Capacity values, it doesn’t matter. zGUARD is able to take over all operations.
The Performance-, Delay- and Consumption values of the LPARs are measured and performed according to Trigger/ Event based actions every minute.
Intervals of single minutes are already enough to influence the consumption. A permanent Capping makes most of the time no sense and is not contemporary anymore.
MODE OF OPERATION
zGUARD © as a product in use is freely programmable. There are no restrictions to the possibilities of operations. You are provided with all necessary values actualized to the minute and analyzable by zGUARD ©. If due to thresholds Triggers/ Events will be released you have the possibility to start predefined scripts. The scripts can be written in almost every programming language, a special mainframe Know-How is not needed. Within the script you can for example compare values and consumptions with each other, make calculations and then –automated- change HMC values, offset Console commands or write a simple WTO in the Syslog of the affected system. The level of detail of information which zGUARD provides you with goes up to service- / report category level. That means you have very detailed information to assess the condition of your systems.
Exemplary, schematic representation:
Once you have evaluated which LPAR was involved with which workload in the respective peak, you can develop Events which influence such situations.
To know the potentials is essential. You need information about which LPAR limits you want to set or you let zGUARD make the decisions based on other parameters (f.e. “Delays”).
Example: If there is enough batch workload which isn’t time-critical it is possible to cap the LPAR without influencing workload of higher quality. This workload works as a buffer while Capping begins.
Which Workload do you hit through Capping? When does the WLM (© IBM) have to interfere to protect the important, time-critical workload?
Which service classes are involved in the peaks and in what dimension? Which workload is really time-critical? It is not about “important”!
If you have an accurate picture of the appearance of peaks and you know which LPAR you can refuse resources in which time frame, you are able to decide on a dynamic, automated adaption of limits. With equivalent rules your systems will begin to automatically control themselves and react to equivalent load distributions. A good practice is to define minimum and maximum values e.g.. for a Defined-Capacity. Then zGUARD © will only change the values within this area.
EXAMPLES OF USE
Depending on which effect the customer wants to achieve he can change limits or system-settings with zGUARD ©. The adaptions happen, if necessary, every minute. You can see very impressively on the following charts how the 4h Rolling Average (blue line with white border) changes itself through the adapted Defined-Capacity.
Without zGUARD © interfering the 4h Rolling Average would have proceeded differently and steeper which would have caused noticeable higher costs. After a “possible” Peak situation is over, customers have decided to again give LPAR a (standard) Defined-Capacity which serves as a maximum as long as no new MLC Peak is imminent.
As you can see in the charts LPARs are only being limited in times where it is wise considering the costs. Although the LPARs are partly strongly influenced there are only few hours during the month, which are sufficient to reach lower, sustainable MLC costs.
zBusiness Services GmbH & Co. KG
Contact person: Uwe Oswald
Telephone: +49 (0) 6246 9048153
Fax: +49 (0) 6246 9074220
Grüner Weg 1