Get the Benefits of IBM’s Mobile Workload Pricing

If you are an IBM zSeries customer running a zEC13, zEC12 or zBC12 server (although actual mobile workload may be running on any zEnterprise machine including z196 and z114) utilizing z/OS Mobile Workload Pricing (MWP) eligible products - CICS, IMS, MQ, DB2 and WebSphere – did you know you could potentially reduce your z/OS peak MSUs attributable to mobile workloads by up to 60%?
​
Sounds interesting right, so how might you go about implementing it?

Firstly, lets look at the technical fundamentals:

• You’ll need to be able to tag and track mobile transactions, and there are different architecture options for doing so:
  • Option 1 -  Route requests to mobile specific regions ; or
  • Option 2 – use the same regions and filter mobile transactions based on a tagging  mechanism.
• You’ll also need the MWRT (Mobile Workload Reporting Tool) which replaces SCRT and will subtract mobile CPU seconds from peaks.

Ok then, how does this actually translate to benefits?

Per the diagram below, with the Mobile Records identified, the resultant usage data is submitted into the MWRT and up to 60% of the designated capacity is then deducted from the overall LPAR values (Refer steps 1-3):

​Sounds good, but how would each option actually work and on what basis do I choose one over the other?

Option 1 - Use individual regions for mobile-only workloads:

• Relies on implementing a routing mechanism such that all mobile requests go to a distinct set of processing resources (CICS or IMS regions for example) and then simply measure the CPU consumed by those regions.
• Region CPU can be measured using SMF 72 (RMF Workload Activity) or SMF 30 (Address Space Activity) 
• This has the advantage that transaction-level monitoring is not required – in this example, it does not need CICS SMF 110 records. It also means that all of the CPU used by the region is captured.

Option 2 - Use the same regions for mobile and non-mobile workloads :

• Relies on a ‘mobile tag’ being sent with the request so that transaction-level monitoring can filter the  transactions and accumulate CPU only for the mobile transactions.
• Reflects most system setups today e.g a CICSplex (set of CICS regions) processing requests from different channels.

Note: there is potentially another option which would be to route all mobile requests to a specific LPAR.

To supplement either you’ll also need a tool to analyse the transaction level data. There are a number of tools (IBM and non-IBM) on the market today, such as generic tools like TAW and TDS which are capable of processing records from multiple products, or if your MWP comprises a limited product set (e.g just CICS DB2) then a product based tool such as CICS PA would suffice.
​
And finally, you’ll need a Contract Supplement (don't forget the Supplement!) agreed with IBM outlining how the mobile CPU for each of the MWP programs will be calculated, which would be something similar to the below :

If you’re not ready to go down the MWP path yet you might still want to consider what could be done now in preparation, eg.

• tag and track mobile workloads (you cannot assess what you cannot measure);    
• and if you can, simplify the process of quantifying CPU utilisation by isolating mobile workloads to their own processing region.

If all this has left you wanting to know more then check out the original Announcement letter.

​Happy saving!