Vendor results can be a telling indicator of what might lie aheadWe regularly connect with the ITAM Review as a reliable source of information in the software domain and of interest this month is a comprehensive report from Rich Gibbons on the financial performance of some key software vendors - from the $5.6B loss of Google Cloud to the 29% rise in operating income (Q2) of Microsoft. In summary ...
Some marked differences in performance - particularly in the cloud space, with a watch and ready advice for some of the poorer performers - we all know where they head when times are tight ...
0 Comments
An innocuous Announcement Letter may be more telling than it seems ...
While discounts will remain for hybrid and cloud platforms, as of 1st July these will no longer apply to your on-premise installations. With statements such as: "where we will continue to focus our investment and innovation" And ... "it is recommended that your company evaluate and plan a transition to the equivalent, cloud- and/or hybrid cloud-based offering" The message seems pretty clear that the future as IBM sees it is all in the Cloud, certainly if you're looking for discounts on your next purchase of PA software. It will be interesting to see what might follow in IBM's plans to further 'encourage' cloud migration, and how others might adopt similar strategies.
All might not be as it seems - check this list of ILMT gotcha's
Here are out top five tips for trimming your PVU sub-capacity report counts: 1. Incomplete Vitualisation - the 'TVM' predicamentIf your ILMT configuration is not fully or properly implemented you're likely to find incomplete virtualisation heirarchies in your VM Manager connections, which result in every affected VM being treated as a stand-alone physical machine at the highest PVU rating of 120 PVUs per core). This can quickly add up where you might otherwise be entitled to the likes of 70 PVUs per core. 2. Missing Software ClassificationsCentral to the accuracy of ILMT reporting is the much dreaded 'Software Classification' process. If you choose to ignore this painstaking requirement you can be sure you'll pay the price either in real terms or in time-draining dispute at your next audit. Essentially, every exempt PVU count in your environment needs to be catagorised as such, meaning instances that are to be excluded from PVU counts (which depending on the License Terms are likely Developer, DR, or Test installs) need to be individually identified as such via this (ongoing) activity. 3. Unrecognised BundlingAs a follow-on to the Software Classification issue above, you'll then likely notice that where you have installed Supporting Programs on a different server - where entitled to do so under the License Terms - the program will magically form part of the PVU count, ie. bundling is not recognised across servers. So once again you'll need to identify these instances and exclude them from the relevant count, making sure you add comments to qualify the classification. 4. Reallocation High-Water MarksSo you dutifully maintain your vCPU's to your level of entitlement, which, as you're permitted to do, includes the occasional reallocation across servers to match processing and performance needs. Given you've balanced the core counts out all is good - right? Well ... no, ILMT will track the high-water mark for each server in the 90-day reporting period, so for example a taking a core from a 4 vCPU server to assign to a 3 vCPU server will see both reporting as 4 vCPU servers for that period. To be in a position to challenge this make sure you have or take - and keep - separate records that evidence the reassignment of cores to negate any double counting. 5. Ghost DecommissioningSimilar to the above, you might think that decommissioning one server to deploy another would be quite within your rights as long as you (as always) don't exceed your level of entitlements. Well ... no, the decommissioned server will also report within the same 90-day period as the new server - potentially a bigger problem than the issue with high-water marks. So again you'll need to either classify the server accordingly, or ensure you have the right artefacts to contest any double recognition, or both. ... a lot of overhead right?Yes.And that's where a secondary source of truth can prove essential ... IBM Announces its new "Authorised SAM Provider" Offering (IASP)While it appears the disgruntled messaging from clients is finally starting to register with some major vendors, a recent announcement from IBM (outlined here by the ITAM Review) by no means makes it an all clear. We're all for any move to make software licensing compliance simpler, and the IASP program for some large IBM customers might just do that - although by invitation only and accomplished by engaging one of just four designated IBM partners:
OKAY, SO WHAT's THE OBJECTIVE?In a nutshell, to offer those select few an alternative to IBM's License Reviews by operating a managed service that brings SAM expertise, tools, and knowledge to organisations who are perhaps struggling with those skills themselves - which happens to be exactly what we at Software Compliance have been offering our valued clients since 2016! HOW ABOUT the APPROACH?Once invited, an organisation selects an authorised partner who will then - through a defined scope of paid work - follow the standard licensing compliance process to create a baseline (using ILMT), perform an initial reconciliation, resolve any issues, and implement an ongoing management and control program, all done under an IASP Agreement that must be executed with IBM (covering a term of up to 3 years). ... And THE Benefits?The major attraction is that any licensing shortfalls discovered in the initial baseline can be resolved at the customers entitled price without any back-dating of S&S - and - an apparent waiver of any sub-capacity issues (tbc). ... and we all know how problematic (ie. costly) issues in this space can be! On the surface perhaps an admirable new direction from IBM, but does it really differ to how customers operating under the likes of an Enterprise Services & Software Offering (ESSO) have been treated for the last 10+ years? We think not - baselines were created, shortfalls resolved (albeit perhaps not as transparently), regular reporting was mandatory, etc ... so the only difference seems to be that the customer is required to engage one of just four designated partners.
Contact Us ... (before your Vendors do)
Could the Change to IBM's PVU Core Table Signal a Refreshing SHIFT in Sub-Capacity Licensing? While some vendors prefer to wallow in the mire of antiquated and irrelevant licensing regimes others seem to be moving ahead with revised models that provide clarity and ease in establishing your licensing and compliance position. A case in point - IBM - who flagged a rethink with a shift from the messy PVU to Virtual Processor Core metrics (example in the hyperlink). Starting April this year the x86 PVU Table has been culled down to just 6 entries with the Intel category now much simplified for the Xeon chipset, basically all determined by the number of sockets at 2, 4, and >4 (with the lower models in the listed ranges remaining at 50 PVU's):  There is however one complication - Symmetric Multiprocessing Servers - which you need to factor per definition below: The PVU requirement for the Intel processor technology indicated is dependent on the maximum number of sockets on the server. If sockets on two or more servers are connected to form a Symmetric Multiprocessing (SMP) Server, the maximum number of sockets per server increases. Example:
Good news from our perspective - anything that removes ambiguity is welcomed (with reference to the linked post at the start of this blog: "oh but you have to count the Physical cores, not virtual, on the Host, in fact all Hosts in the complex, actually in the Data Center, well let's say the Cloud then, so basically ... ... everything, everywhere")
Extended Support for SQL Server 2008 and 2008 R2 will end on July 9, 2019. |
 |  |
What will 'end of support' mean? ... it will mean the end of regular security updates, and with the extent of hacks and attacks going on at any time - and the (legitimately) tough regulatory position on data protection - that would be a concern to all.
Now there are of course some options available at this stage to address this exposure:
- If you are an Azure customer, Extended Security Updates will be available for free in Azure for 2008 and 2008 R2 versions of SQL Server and Windows Server to help secure your workloads for three more years after the end of support deadline.
- If you run on-premise installations, you will be able to purchase Extended Security Updates for three more years as long as you have Software Assurance or Subscription licenses under an Enterprise Agreement enrollment.
So if it's free for Azure customers, what does it cost if I'm not? ...
75 percent of the full license cost of the latest version of SQL Server or Windows Server, purchased annually to cover only the servers that require the updates.
Ouch.
But wait, there's more. If you happen to run any IBM software under Windows Server, and you also run those servers in a virtualised environment, you need to be aware of an often overlooked limitation under IBM's sub-capacity rules. And that relates to 'Eligible Technologies'.
A quick glance through the regularly updated table by our ILMT development friends could come as a bit of a shock if you happen to still be running Windows Server 2003 - it's no longer an eligible technology - take a look at the snippet below under VMware:
You can view the entire list here.
And if it's 'not eligible', what does that mean? Basically that you'll need to revert to manual counting for that environment, and for which IBM provides a particularly onerous method and template as an Excel workbook downloadable here.
So taking the Windows Server 2003 omission as an example it's fair to expect that we'll see Windows Server 2008 drop off in equally quick time. Not only then is there a compelling cost imperative due to Extended Support, but an equally expensive overhead with IBM sub-capacity tracking and reporting as well (remember - you need to generate your sub-cap domain usage quarterly).
Time to act!
Microsoft have an advisory page here that is worth checking which also provides links to their end of support resource center for further advice and assistance. And if you're looking for a better tool than perhaps a spreadsheet for you IBM sub-cap reporting we have just the ticket with our ComplianceWare application - we recommend you check it out here!
 |  |
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?
Sounds interesting right, so how might you go about implementing it?
Firstly, lets look at the technical fundamentals:
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):
- 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.
- 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.
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.
Happy saving!
How might it affect performance and licensing?
As the full implications emerge with the design of Intel's (and potentially others) x64 processor (see more at the Register here) we await with interest a response from software vendors as to how the corresponding issue of licensing will be answered and resolved.
Given patches are now being released (eg. AWS EC2 5th January, Azure the 10th January) the resultant performance impacts will become the subject of intense scrutiny. Why? well if, as reported, processing power diminishes anywhere from 5 to 30 percent how will customers be compensated?
Processor and Core based software has been dutifully acquired on the basis of the underlying performance of the chipsets on which the products are run (consider IBM's PVUs, Microsofts Core minimums etc). Now though, if that proves to be erroneous, surely a remedy must be made available to the customer who has paid for a defined - and benchmarked - level of processing power?
Take the scenario whereby a customers current 2,000 PVUs can no longer deliver the required throughput and needs a further 500 PVUs in order to deliver the same capability - you would be right to expect no additional charges to apply given there is no improvement in performance surely? And what about needing more hardware just to achieve the current level of demand, or a Cloud vendor purchasing an array of new servers in order to provision more vCPUs for their PaaS / SaaS customers just to meet the same CPU cycles ?
That all costs money, so ... Who Pays??
Which then presents an intriguing conundrum for the chip makers and the software vendors. Presumably there will be a vast re-benchmarking exercise (and consider chipsets produced in the last 10 years are potentially affected) the question then being, what is to be done on the basis of the results? Compensation? Free License Grants? Reduced Annual Maintenance fees??
So we expectantly await vendor responses once the focus on getting fixes out shifts to the underlying and associated commercial dilemma confronting the industry. What can you do in the meantime? Firstly, make sure you have current performance metrics that you can measure any degradation against, and then pose these questions to your vendor Account Manager, your Sales Rep, your Software Specialist - ask how any performance issues you experience might be remediated in the immediate term, and request an open and regular communication channel to stay informed as it all progresses ...
We firmly believe - if the projected performance impacts do transpire - this issue will prove to be one of the most perplexing problems to emerge in the IT industry in many years.
Watch this space for further updates as more unfolds.
While these three little snippets might not seem particularly sensational they are worth noting precisely for that reason - they are likely lurking in the background, ready to cost you money when you least need it!
| 1. IBM License Management Tool (ILMT) |  |
OK, so we all know that under the IBM sub-capacity rules we must produce a report from ILMT every quarter right? And we know that we must sign and date that record, and keep them all as an artefact that may be required during any audit too, right?
All good, then the tip:
All good, then the tip:
Make sure you have configured ILMT correctly and fully for VM Management.
What's so important about VM Management in ILMT? If not properly configured it will default to 120 PVUs per core, so you could be over-reporting without being aware. How can you tell if its configured? Firstly, it shows a status on the Dashboard, and secondly, if not configured servers will be displayed with a serial-like number beginning with 'TLM_VM' or similar.
If you need more information on how to configure just look here.
| 2. Microsoft Subscription Licensing. |  |
Microsoft in many ways have led the industry in a shift to SaaS offerings backed by subscription based licensing. While this may appear to have a favourable ROI initially, there are other Time-Value commercial components to consider.
Firstly, you need to be aware that your licensing is now not only visible but manageable real-time by Microsoft. So from a commercial perspective there is now no locked-in pricing for the typical 3 year term of an Enterprise Agreement, instead you will see price increases built-in year on year in your CPS. And more so, there is no 'True-Up' benefit whereby you would pay essentially half the cost in the year in which you deployed the product - you now 'reserve' the additional licenses you need to be drawn down, and you start paying from that month onwards.
The tip?
The tip?
Make sure you consider TVM with subscription changes in your ROI / Cost Comparisons.
And the last tip for 2017 ... a favourite topic here at Software Compliance ... processor to core conversion.
| 3. No 'unpacking' of Core Licenses So a quick tally of the number of core licenses across your Windows Server fleet divided by 16 gives you your number of 16 Pack licenses required right? |  |
Wrong! ... A license pack is applied to a server, so where you have say a 12 Core server you need to assign 6 x 2 Core packs - you can't assign 12 from your 16 Core pack, and then apply the other 4 elsewhere. A nasty - and potentially expensive error - if not properly considered in determining your conversion.
And so ends 2017 ... we look forward to a busy and productive 2018 for us all!
IBM first introduced sub-capacity licensing in 2005 in response to the production of the x86 dual core chipset on the premise that licensing could shift to each core on a chip, not just the chipset itself. Clearly this has merit given today's much more complex, virtualised technology platforms with chips containing up to 18 cores - the enduring problem though for customers: understanding the sub-capacity rules and staying compliant.
So lets take a look at one of the most common IBM sub-capacity metrics - the Processor Value Unit or PVU for middleware. Firstly, lets be clear on IBM's terminology relevant to this discussion:
So lets take a look at one of the most common IBM sub-capacity metrics - the Processor Value Unit or PVU for middleware. Firstly, lets be clear on IBM's terminology relevant to this discussion:
Core - A functional unit within a computing device that interprets and executes software instructions.
Chip – electronic circuitry, containing but not limited to at least one core, on a silicon wafer.
Socket – the mount that secures a chip to a motherboard.
Processor – There remains disagreement in the computer industry over the definition of a processor. IBM defines a processor as the core. For example, a dual-core chip has two processor cores on it.
Chip – electronic circuitry, containing but not limited to at least one core, on a silicon wafer.
Socket – the mount that secures a chip to a motherboard.
Processor – There remains disagreement in the computer industry over the definition of a processor. IBM defines a processor as the core. For example, a dual-core chip has two processor cores on it.
As an IBM customer there are certain prerequisites to employing sub-capacity licensing under your Passport Advantage (PA) Agreement:
So with that all ticked off (and make sure they are - you will need these artefacts in the event of any audit), what are the basics in determining the number of licenseable PVUs?
If counting physical cores you count Activated Processor Cores, which are processor cores that are available for use in the server (ie. don't count if deactivated).
The illustration below provides an example of the counting rules applied in an x86 environment where the Virtualisation Capacity equates to the number of licenseable cores:
- Use Eligible Sub-capacity Products;
- Use Eligible Virtualization Technologies;
- Use Eligible Processor Technologies; and
- Use the IBM License Metric Tool (ILMT) and maintain report documentation − Tivoli Asset Discovery for Distributed (TADd) or IBM BixFix Inventor in lieu of IMLT
So with that all ticked off (and make sure they are - you will need these artefacts in the event of any audit), what are the basics in determining the number of licenseable PVUs?
- The required number of PVUs depends upon the type of processor and the total number of processor cores available to the product;
- You can license the at the physical layer, ie. physical cores on the server (full-capacity) or the highest number of PVUs available to the VM on which the product is installed (sub-capacity);
- Where no virtualisation technology is employed sub-capacity = full-capacity; and
- Where the sub-capacity core count for an installed product is higher than the physical core count, sub-capacity = full-capacity (ie. take the lower of the vCPU's or the physical cores available to the product.
If counting physical cores you count Activated Processor Cores, which are processor cores that are available for use in the server (ie. don't count if deactivated).
The illustration below provides an example of the counting rules applied in an x86 environment where the Virtualisation Capacity equates to the number of licenseable cores:
So with the number of cores established, how do we determine the applicable PVU count?
IBM assigns a PVU per processor core rating to each processor technology collated in the PVU Table published on their website - and note just how much has changed when you compare to the original table from 2006 below (!)
IBM assigns a PVU per processor core rating to each processor technology collated in the PVU Table published on their website - and note just how much has changed when you compare to the original table from 2006 below (!)
You'll need the requisite system access in order to interrogate your systems to determine the relevant processor model - refer to IBM's helpful Guide if you need more information on how to do this (or, let our ComplianceWare tool do it all for you!)
Its then a matter of extrapolating the PVU counts by cores across your product installations, and tracking on a regular basis to be sure you account for the inevitable changes in your environment that alter those figures (again, easily done through system compares of our ComplianceWare output).
IBM has published a list of FAQ that should assist you through any other queries you might have, or ... comment here and we'll be happy to help!
Its then a matter of extrapolating the PVU counts by cores across your product installations, and tracking on a regular basis to be sure you account for the inevitable changes in your environment that alter those figures (again, easily done through system compares of our ComplianceWare output).
IBM has published a list of FAQ that should assist you through any other queries you might have, or ... comment here and we'll be happy to help!
So the latest incarnation of IBM's Enterprise Software and Services Offerings (ESSO) takes the form of precious stones ... hard to argue, it can offer good value when put to good use. But that means knowing how to get the most out of the ACP and CBA, and also S&S Credits where you can. If you've loaded up your MLC projections make sure you don't lose that value either, I'd recommend preparing for renewal up to 12 months before expiry - you want to establish your baseline before IBM does, as it's pretty much locked in at that point. It takes effort, but it'll be worth it.
If you (a) start with the wrong baseline (and to IBM that's your S&S at the time, whether you're going to renew it or not), or (b) just take a guess at your future MLC, you could forfeit major, not minor, MAJOR dollars. Get ahead of the curve, sort your position out early. Only then can you negotiate on your terms.
If you (a) start with the wrong baseline (and to IBM that's your S&S at the time, whether you're going to renew it or not), or (b) just take a guess at your future MLC, you could forfeit major, not minor, MAJOR dollars. Get ahead of the curve, sort your position out early. Only then can you negotiate on your terms.