MVM Eases DB2 for z/OS Upgrade Anxiety

On 14^th February 2017, IBM quietly announced a new software charging mechanism that could have some very positive implications for most System z sites – including DB2 for z/OS customers. MVM (Multi-Version Measurement) replaces the old Single Version Charging (SVC) arrangement, and promises to do away with many of the restrictions that IBM previously imposed on the timing and charging for version upgrades. Want to know more? Read on…

Single Version Charging (SVC)

A quick recap might be in order for those of us that don’t permanently reside in the complex and murky world of IBM’s mainframe pricing plans. Most of IBM’s mainframe customers are on some flavour of sub-capacity MLC (Monthly Licence Charge) plan, which involves paying IBM software fees each month based on the peak 4-hour rolling average CPU utilisation for a given environment. This peak CPU usage (measured in MSUs) is used to calculate the charge for each IBM software product used in that environment.

OK, but what has all of this got to do with version upgrades? Well, if you happen to be running two versions of the same product in the same environment (say DB2 10 and DB2 11 during your upgrade from one to the other), you’d get charged separately for each one – effectively doubling the cost of your DB2 licence while both versions were active. Of course, this additional cost would dissuade most customers from ever undertaking an upgrade, so IBM came up with the concept of Single Version Charging (SVC). This effectively grants a limited amnesty for applicable products, so that you only get charged for the newer version of a given product for a specific period of time (usually 12 months but this could be extended by prior agreement with IBM).

SVC granted customers a much-needed window to complete their upgrade so they could avoid getting charged twice, but many large enterprise customers still had significant difficulties with it. Sites with stand-alone DB2 systems that would otherwise be able to rapidly exploit new features (e.g. those supporting SAP environments) couldn’t be upgraded individually, as the SVC clock started ticking as soon as the first DB2 environment was migrated so everything had to be planned/implemented as a single massive project. Larger customers might have hundreds of DB2 subsystems to upgrade and even if the DB2 sysprogs somehow came up with a plan to complete everything in 12 months, the actual process could often take longer due to unforeseen technical issues or a lack of available change slots. The move to more agile mainframe working practices and the popularity of the DevOps movement has only exacerbated these problems.

SVC is Dead – Long live MVM!

IBM’s announcement of Multi-Version Measurement (MVM) aims to sweep away these challenges. It completely replaces SVC (and other similar mechanisms such as MPO (Migration Pricing Option) and the IPLA Migration Grace Period) with a much simpler and more straightforward approach. Customers no longer have any possibility of paying separately for multiple versions of the same product, and there are no time limits associated with running multiple versions at the same time. This allows you to upgrade individual DB2 systems as and when you get the most business benefit, without having to worry about having to upgrade all of the others within a set period. Unforeseen delays to a DB2 upgrade project will no longer result in a protracted negotiation process with IBM to extend the SVC deadline. Your DB2 environment just got a bit more agile!

A few other points worth bearing in mind:

• If you currently have an SVC agreement that was due to expire between 14th February and 30th May 2017, IBM has automatically extended it to 31st May 2017 in order to allow you to roll over to the new MVM arrangements.
• Sub-capacity clients must take action to convert from SVC to MVM. Steps are outlined in the announcement letter, but essentially this involves upgrading to the latest release of the Sub-Capacity Reporting Tool (SCRT) used to generate the monthly billing reports for IBM. If you do this in time to submit your April data (in early May), MVM will go into effect from the June 1st bill. Full capacity clients need take no action – they will automatically be converted to MVM on 1st June.
• MVM gives you more flexibility in planning version upgrades, but  it is not a “get out of jail free” card that allows you to ignore the need to keep your DB2 environments up to date with the latest release. Leaving aside the fact that you’d be missing out on many new DB2 features that could be reducing costs and improving performance and productivity, you will still be facing the unpleasant prospect of significant extended support fees if you continue to use a version of DB2 beyond its end of support (EOS) date.

As IBM moves to Continuous Delivery of new function following DB2 12, all of this is likely to become less important (although I fully expect to see new versions of DB2 being released occasionally, even with the Continuous Delivery process in full flow). However, for the majority of customers still planning their upgrade to DB2 11 (don’t forget  DB2 10 EOS is just a few months away, in September 30th 2017) or to DB2 12, this is a major bit of good news that could take away a few of the headaches associated with previous upgrade projects.

Good luck with your upgrades, and don’t forget that Triton can provide customised Migration Support Services to assist you if you’re struggling to find the time to plan and implement them.

• Share