New Processor Value Unit Licensing for Middleware Evolving the Structure to Provide a Foundation for the Future Processor Value Unit Sales Scenarios.

New Processor Value Unit Licensing for Middleware Evolving the Structure to Provide a Foundation for the Future Processor Value Unit Sales Scenarios

How To Read The Scenario Charts
Description of the customer scenario Changes: Overview of all the changes required by the customer in this scenario System at beginning of scenario System at end of scenario Sever System Installed IBM Middleware Installed Server System Installed IBM Middleware Installed Blue circles = processor cores White rectangles = chips Each of the following scenarios starts with a description of what the customer wants to accomplish. This description is enclosed in a rectangle at the top of the page. Directly below the scenario description is a list of all the changes the customer will undertake to get from the before picture to the after picture in this scenario. Following the list of changes are before and after pictures of the customer’s systems, including the middleware deployed on them. The results of the scenario changes can be seen on the results picture on the right of each page. Each of these pictures includes a number of sections: The blue box at the top tells you the kind of system hardware installed. It notes both vendor and brand. For simplicity sake we have left the specific model number out. Then I describe the IBM middleware installed in the pale yellow box. Once again, for simplicity we have left the version and release information off the chart, but please just assume it is the latest version. Below the IBM middleware is a set of white boxes with blue circles in them. The white rectangular boxes represent the hardware chips, and the blue circles represents the processor cores in the system. Then I have provided a table which summarizes the IBM middleware, the number of hardware chips and processor cores, and the number of middleware licenses required on that specific server. I’ll conclude each scenario with a summary of the actions the customer must take to keep their middleware in compliance with our terms and conditions. IBM Product No. Chips Number Processor Cores License Type WebSphere 2 4 4 Per Processor IBM Product No. Chips Number Processor Cores License Type WebSphere 2 4 400 Processor Value Units Customer Action: Specific licensing actions required by the customer

Scenario 1: Single Hardware Platform New Purchase
Customer buys a new system with x86 dual-core chips Changes: Purchase System x server Purchase DB2 licenses for the new processors Prior to 7/25 Subsequent to 7/25 IBM System x Server DB2 IBM System x Server DB2 Product Chips Processor Cores Per Processor Licenses DB2 2 4 Product Chips Processor Cores Processor Value Units DB2 2 4 200 Scenario 1 shows a customer buying a new system and the resulting licenses required both prior to the announcement on July 25th and following it. So in both cases both the hardware and the middleware will be new. The system purchased before July 25th is on the left, and the system purchased after the introduction of processor value units is on the right. In this scenario, the customer buys a new System x server with two dual-core chips and deploys DB2 on it. As you can see in the table, this situation would require 2 per processor licenses since it is being purchased before the introduction of processor value units. Remember that a dual-core x86 server only requires one license for the 2 cores on the chip, or effectively ½ of a license per processor. Since there are 4 processors here, the customer will need two DB2 licenses. Now lets see what the customer would acquire if this transaction took place after July 25th and the introduction of processor value units on the right side of the page. When you look up an x86 dual-core processor on the processor value unit table, you will see that 50 processor value units are required for each processor core on the system. Since this server has 4 processor cores, the customer will require 200 processor value units of DB2. You can also see that this is the same number that you could get by taking the number of per processor licenses on the left of the chart and multiplying them by the conversion factor of 100 we discussed in prior modules. Customer Action: Acquire 2 per processor licenses of DB2 for 4 System x processor cores before July 25th Customer Action: Acquire 200 processor value unit licenses of DB2 for 4 System x processor cores after July 25th

Per Processor Licenses
Scenario 2: Single Hardware Platform Comparison of Same Licenses Purchased Before or After Announcement Customer adds WebSphere to an x86 dual-core server already running DB2 Changes: Purchase new WebSphere processor value unit licenses Prior to 7/25 Subsequent to 7/25 IBM System x Server DB2 IBM System x Server WebSphere & DB2 Product Chips Processor Cores Per Processor Licenses DB2 2 4 Product Chips Processor Cores Processor Value Units DB2 2 4 200 WebSphere Our starting point in scenario 2 is the same kind of server that was installed in scenario 1. This server was purchased before the July 25th announcement, so it looks exactly like the picture on the left of scenario 1 we just looked at. What the customer wants to do now is to add WebSphere. This will take place after the announcement. To accomplish that, the customer will order 200 value units of WebSphere using the same approach we saw on the previous chart. Again, when you look up an x86 dual-core processor on the processor value unit table you will see that 50 processor value units are required for each processor core on the system. Since this server has 4 processor cores, the customer will require 200 processor value units of WebSphere. There is no change to the number of DB2 licenses, but I have shown them converted to processor value units so you can compare them to the new WebSphere licenses. So the only middleware the customer needs to order here is 200 processor value units of WebSphere. Customer Action: Acquire 200 processor value unit licenses of WebSphere for 4 System x processor cores

Upgrade or Transfer Existing Processor Value Unit Licenses to New Servers
In the next section we will take a look at some scenarios where we either upgrade or transfer existing processor value unit licenses to new server environments.

Scenario 3: Upgrade to Larger Server Single Hardware Platform
Customer upgrades from a 4-way to an 8-way System p running WebSphere Changes: Server upgrade, adding 4 processor cores Add WebSphere processor value unit licenses for the new processor cores Base Result IBM System p Server WebSphere IBM System p Server WebSphere Now in scenario 3 lets take a look at a customer who upgrades their hardware and wants to fully populate the server with WebSphere. The original system is a 4 processor System p (also referred to as a 4-way system p) that the customer upgrades to an 8-way. To accomplish this, the customer will need to acquire enough additional processor value unit licenses of WebSphere to match the additional processors. The System p requires 100 value unit licenses per processor core. Since the customer has added 4 additional System p processor cores, the customer will need to purchase an additional 400 processor value unit licenses of WebSphere for a total of 800 processor value unit licenses of WebSphere. Product Chips Processor Cores Processor Value Units WebSphere 2 4 400 Product Chips Processor Cores Processor Value Units WebSphere 4 8 800 Customer Action: Acquire 400 additional processor value units of WebSphere

Scenario 3a: Upgrade to Larger Server Single Hardware Platform
Customer upgrades from a 4-way to an 8-way System p with Quad Core Modules (QCM servers) running WebSphere Changes: Server upgrade, adding 4 processor cores (one QCM module) Add WebSphere processor value unit licenses for the new processor cores Base Result IBM System p QCM Server WebSphere IBM System p QCM Server WebSphere Now in scenario 3a lets take a look at a customer who upgrades their hardware, but is using the unique Power 5 Quad Core Module technology. This technology has 2 Power5 dual core chips on a single module that plugs into a single socket. The customer still wants to fully populate this QCM server with WebSphere. The original system is a 4 processor System p with one quad core module that the customer upgrades to an 8-way, which requires the installation of an additional QCM module. To accomplish this, the customer will need to acquire enough additional processor value unit licenses of WebSphere to match the additional processors. The System p QCM requires 50 value unit licenses per processor core. Since the customer has added 4 additional System p QCM processor cores, the customer will need to purchase an additional 200 processor value unit licenses of WebSphere for a total of 400 processor value unit licenses of WebSphere. Product Chips Processor Cores Processor Value Units WebSphere 2 4 200 Product Chips Processor Cores Processor Value Units WebSphere 4 8 400 Customer Action: Acquire 200 additional processor value units of WebSphere

Scenario 4: Transfer Licenses to Larger Server Different Hardware Platform
Customer upgrades server from an HP ProLiant PC Server (2 single-core x86 chips) to System i with 4 processor cores running WebSphere Commerce Changes: Server upgrade to System i server Transfer existing licenses of WebSphere Commerce Add additional licenses of WebSphere Commerce Base Result HP ProLiant PC Server IBM System i Server WebSphere Commerce WebSphere Commerce In this scenario we will introduce our first non-IBM hardware platform. The HP ProLiant system is an x86 based server which can have either single or dual-core chips in it. In this case the customer has an older system with single core chips. The customer realizes, though, that with their workload increasing they need more processing power and have decided to migrate to an IBM System i and provide enough additional power for their expected future growth. To accomplish this, the customer will install the new System i, transfer the existing WebSphere Commerce licenses to the new system, and acquire enough additional processor value unit licenses to fully populate the system. Since a single core x86 system requires 100 processor value units per processor core, the customer already has 200 processor value units of WebSphere Commerce. These 200 processor value units are enough for 2 of the 4 processors on the System i. Since a total of 400 processor value unit licenses are required to be in compliance, the customer needs to acquire an additional 200 processor value units of Commerce. Product Chips Processor Cores Processor Value Units WebSphere Commerce 2 200 Product Chips Processor Cores Processor Value Units WebSphere Commerce 2 4 400 Customer Action: Acquire 200 additional processor value units of WebSphere Commerce

Acquire New Licenses Lets now look at a few scenarios where the customer acquires a new middleware product. The first of these scenarios is on page 12.

Scenario 5: Add New Product to Existing System Single Hardware Platform -- Full Capacity
Customer adds DB2 to an existing System p server running WebSphere Changes: Add new DB2 licenses on all processor cores Base IBM System p Server WebSphere & DB2 Result IBM System p Server WebSphere Product Chips Processor Cores Processor Value Units WebSphere 2 4 400 In this scenario the customer is adding DB2 to an existing WebSphere system. I also want to introduce another term here – full capacity. Using processor value unit licensing, a customer can implement one of two kinds of licenses: full capacity or sub-capacity. By the way, these are the same two license types that have been available with per processor licenses as well. I’ll cover sub-capacity in a later scenario. With a full capacity license, the customer must have enough licenses for every processor on the server regardless of whether the product is actually running on each processor or not. In this full capacity situation, the customer already has a 4-way System p running WebSphere. You can see that the customer is fully in compliance with our full capacity terms because they have 400 processor value units of WebSphere, or 100 processor value unit licenses for each processor on the system. They then add DB2 to that same server. Again, since it is a full capacity situation, they must acquire 400 processor value units of DB2. In the next scenario we’ll see the customer install an additional server to complement their existing one. Product Chips Processor Cores Processor Value Units WebSphere 2 4 400 DB2 Customer Action: Acquire 400 processor value units of DB2

Scenario 6: Add Additional Server -- Same Type Single Hardware Platform -- Full Capacity
Customer’s workload increases requiring additional server. Customer chooses to install an additional System x dual-core server of same type Changes: Install additional server with 4 processor cores Acquire new licenses for the new processors Base Result IBM System x Server DB2 IBM System x Server DB2 IBM System x Server DB2 In this scenario the customer’s workload is expanding and they have decided to scale out their deployment by adding another System x server. The new second server is configured exactly like the first one, with both running DB2 using full capacity licenses. As we saw earlier, a dual-core x86 server, such as the System x, requires 50 processor value units for each processor core on the system. So the customer already has 200 processor value units of DB2 for their existing System x, and must only acquire an additional 200 processor value units of DB2 for the newly acquired System x. This gives them a total of 400 licenses in total between the two servers. Product Chips Processor Cores Processor Value Units DB2 2 4 200 Product Chips Processor Cores Processor Value Units DB2 4 8 400 Customer Action: Acquire 200 additional processor value units of DB2

Scenario 7: Add Additional Server -- Different Type Different Hardware Platform -- Full Capacity
Customer’s workload increases requiring additional server. Customer has a System x dual-core server and then installs a new System p server Changes: Install additional System p server with 4 processor cores Additional WebSphere Portal licenses for new server IBM System x Server WebSphere Portal Base Result IBM System x Server IBM System p Server WebSphere Portal WebSphere Portal In this scenario the customer will add an additional server to accommodate a growth in their WebSphere Portal workload, but it will be a different type of server. They are starting with a System x running 200 processor value units of Portal since the x86 dual-core processor requires 50 processor value units each. The new System p server, also with 4 processors, will require 100 processor value units of Portal for each of its processors. This is a total of 400 additional processor value unit licenses of WebSphere Portal for a total of 600 processor value unit licenses across both systems. So to meet the requirements of a full capacity license the customer acquires 400 processor value units of WebSphere Portal. Product Chips Processor Cores Processor Value Units WebSphere Portal 2 4 200 Product Chips Processor Cores Processor Value Units WebSphere Portal 4 8 600* * Total of 600 made up of 200 on System x and 400 on System p Customer Action: Acquire 400 additional processor value units of WebSphere Portal

Scenario 8: Add Additional Server -- Different Type Different Hardware Platform -- Full Capacity
Customer’s workload increases, requiring additional server. Customer moves DB2 workload off existing server and on to new System p server Changes: Install new System p server with 4 processor cores Transfer existing DB2 licenses to new server and acquire additional licenses IBM System x Server WebSphere & DB2 Base Result IBM System x Server WebSphere IBM System p Server DB2 In this scenario, the customer starts with an x86 dual-core server running both WebSphere and DB2 in full capacity mode. With a growing workload, they have decided to bring in a new System p server, but plan to split their middleware so that only one product runs on each server. That is, they will run DB2 on one system and WebSphere on the other. On the original System x the customer has 200 processor value units of both WebSphere and DB2. After installing the new system and migrating DB2 off the original system to the new one, the customer will still have the same 200 processor value units of WebSphere on the System x. On the new System p, however, the customer is required to have 100 processor value unit licenses for each processor, so they transfer their original 200 licenses and need to acquire an additional 200 licenses to fully populate the new system with 400 processor value unit licenses. Product Chips Processor Cores Processor Value Units WebSphere 2 4 200 DB2 Product Chips Processor Cores Processor Value Units WebSphere 2 4 200 DB2 400 Customer Action: Acquire 200 additional processor value units of DB2

Maintenance Renewals Now lets look at a scenario where we renew maintenance on an existing system.

Scenario 9: Maintenance Renewal Full Capacity
Customer’s wants to renew maintenance for existing WebSphere and DB2 on System x dual-core server Changes: No system or licensing changes. IBM System x Server WebSphere & DB2 Base Result IBM System x Server WebSphere & DB2 Product Chips Processor Cores Processor Value Units WebSphere 2 4 200 DB2 Product Chips Processor Cores Processor Value Units WebSphere 2 4 200 DB2 This is a simple maintenance renewal scenario. There is no change to the server itself or the middleware products deployed on it. Please remember that in an earlier module we told you that all maintenance records will be automatically migrated to the new processor value unit maintenance part numbers on announcement day. When the current software maintenance expires, the customer will need to renew all 200 processor value unit maintenance licenses of WebSphere and 200 processor value unit maintenance licenses of DB2. This can be done using the new maintenance renewal part numbers for each product. In every maintenance renewal situation you need to renew all the licenses of the product in question using the new part numbers. Customer Action: Renew maintenance on 200 processor value units of both WebSphere & DB2

Sub-capacity Licenses
Now lets take a look at a few sub-capacity scenarios.

Scenario 10: Add Sub-capacity licenses Same Hardware Platform -- Sub-Capacity
Customer wants to add an additional sub-capacity license to an existing System p server running WebSphere MQ Changes: Increase hardware partition size Order additional WebSphere MQ license Base Result IBM System p Server IBM System p Server MQ MQ In this scenario I want to introduce sub-capacity. Sub-capacity licenses, available for some WebSphere and DB2 products, requires the customer to physically partition their hardware on all non-x86 systems and then have the appropriate number of licenses for each processor in that partition. For x86 systems they are required to run either VMware or Microsoft Virtual Server on it instead of using physical partitioning. In addition, the customer is also required to install the no fee IBM Tivoli License Compliance Manager for IBM Software (or its fee equivalent), monitor all their sub-capacity licenses, and review and submit a report to IBM quarterly on that usage. I’ll give you more details on this in a few pages. In this case the customer already has sub-capacity licenses of WebSphere MQ running in a 2 processor partition on a System p server that has a total of 4 processors. Since MQ is running in a 2 processor partition, the customer only requires 200 processor value units of MQ, and has used the sub-capacity part number to acquire them. To handle a growing workload, though, the customer is going to expand their physical partition to include an additional processor. This will require the customer to purchase an additional 100 processor value units of WebSphere MQ to that partition, also using the sub-capacity part number to order the correct version of the product. Lets take a look at a scenario where we convert existing full capacity licenses to sub-capacity licenses in the process of fulfilling the customer’s request on page 20. Product Chips Processor Cores Processor Value Units WebSphere MQ 1 2 200 Product Chips Processor Cores Processor Value Units WebSphere MQ 2 3 300 Customer Action: Acquire 100 additional processor value units of WebSphere MQ

Scenario 11: Consolidate Servers -- Same Type Same Hardware Platform -- Sub-Capacity
Customer consolidates 2 smaller systems of same type onto a single larger system, utilizing sub-capacity on the consolidated server Changes: Install new larger server, implementing hardware partitioning Convert existing DB2 & WebSphere licenses to sub-capacity licenses Transfer DB2 & WebSphere licenses to larger server Base Result Sun Fire WebSphere Sun Fire DB2 Sun Fire WebSphere DB2 In this scenario the customer is consolidating two 4 processor Sun SPARC servers onto a single 8 processor Sun server. Each of the original servers is running one of two IBM middleware products – WebSphere or DB2. On the new server, the customer will partition the server into 2 physical partitions and run WebSphere and DB2 in sub-capacity mode, each in its own physical partition. To accomplish this, the first step is to install the new Sun server. Then, before migrating the licenses over to it, they must be converted from full capacity licenses to sub-capacity licenses. The process to change from a full capacity part number to the equivalent sub-capacity part number is documented on the Passport Advantage website on either Xtreme Leverage (XL) or PartnerWorld. Please note that it is important to convert the licenses when they are still on the original server, as the customer must be in compliance with our full capacity terms prior to the conversion. If they were to migrate the licenses to the new server first, they would have to have a total of 800 processor value units to be in compliance before they could convert and deploy the 400 licenses actually needed. Once the licenses are converted on the old servers, the customer can then migrate them to the appropriate partition on the new server. Since they converted the licenses prior to the migration and are running on the same number of processors after the migration as before, the customer does not need to purchase any additional licenses. Product Chips Processor Cores Processor Value Units WebSphere 2 4 400 DB2 Product Chips Processor Cores Processor Value Units WebSphere 2 4 400 DB2 Customer Action: No additional processor value units required

Scenario 12: Consolidate Servers -- Different Type Different Hardware Platform -- Sub-Capacity
Customer consolidates 2 smaller systems onto a single larger System p server, utilizing sub-capacity on the consolidated server Changes: Install new System p server, implementing hardware partitioning Convert existing DB2 & WebSphere licenses to sub-capacity licenses Transfer DB2 & WebSphere licenses to larger server Base Result Sun Fire WebSphere HP 9000 DB2 IBM System p DB2 WebSphere This scenario shows the customer consolidating from two competitive servers onto a single, more powerful System p server. WebSphere runs on one of the older systems, while DB2 runs on the other. Since the customer wants to optimize both their system performance and their software cost, they are going to physically partition the new System p into 2 partitions, each with 3 processors assigned to it. Just as in the last scenario, this will require the customer to convert the existing full capacity WebSphere and DB2 licenses to sub-capacity prior to the migration to the new system. Once converted, they can migrate the licenses to the new System p. However, since the new, more powerful System p can run the workloads on fewer processors, the customer migrates 300 of the 400 processor value units they have of each product to the new system. The remaining 100 processor value units of both WebSphere and DB2 become available for redeployment elsewhere. Product Chips Processor Cores Processor Value Units WebSphere 2 4 400 DB2 Product Chips Processor Cores Processor Value Units WebSphere 2 3 300 DB2 Customer Action: No additional processor value units required; 100 licenses redeployed

Reference Materials

How To Read The Scenarios
Customer scenario is outlined in the box at the top Describes what the customer wants to accomplish Changes – a brief description of all the changes required in the scenario System description (before & after scenario) Blue box – system type Pale yellow – IBM middleware installed White rectangles with blue circles Rectangles represent chips Blue circles represents processor cores Table summarizes the number of middleware licenses installed Customer actions – summarizes the changes the customer must make to their middleware licenses This page describes in words the format of the scenarios, and compliments page 2 of this deck.

Sub-capacity Licensing – Additional Information
Sub-capacity licenses also use processor value unit license structure Sub-capacity part numbers have also been replaced Existing process remains the same except: Compliance tool (IBM Tivoli License Compliance Manager) will not report processor value units until 1H2007 Conversion to Processor Value Units occurs when the customer uploads the usage report quarterly With sub-capacity licensing, the customer does not need to have the number of middleware licenses for each processor on the server; they only need to have enough licenses for the processors assigned to the hardware partition in which the middleware product will run. Except that sub-capacity licenses now come in processor value units, all other aspects of the current sub-capacity licensing process remains unchanged. Since I realize that some of you aren’t as familiar with this process as you would like, I’ll take a moment to talk about the key points in the process and, where appropriate, how they are impacted by this announcement. The key difference between sub-capacity and full capacity licenses is that the customer is required to install and run the IBM Tivoli License Compliance Manager (ITLCM), which has a no fee version for use with IBM middleware, as a compliance tool when using a sub-capacity license. This tool tracks the use of a sub-capacity product to identify the high water mark for the number of licenses used each quarter. Quarterly the customer is required to produce a standard report showing these high water marks, and after reviewing it, submit it to IBM electronically where IBM then validates that the customer has enough licenses for this product. Currently the ITLCM tool only reports in per processor licenses, and won’t recognize processor value units until the first half of next year. Until then the customer can determine the equivalent number of licenses by – you guessed it – using the conversion factor of Additionally, IBM’s License Management Server website, which receives the customer’s quarterly usage reports, will reflect the number of processor value units after July 25th.

Sub-capacity Licensing For Distributed Systems
Sub-capacity licensing available for selected WebSphere and DB2 offerings that run on: UNIX (AIX, HP-UX, and Sun Solaris) i5/OS, OS/400 Linux (iSeries, pSeries, zSeries) x86 (VMware ESX Server, VMware GSX Server, Microsoft Virtual Server) – Announced April 25th, 2006 List of participating offerings on Passport Advantage Track compliance using IBM Tivoli License Compliance Manager for IBM Software V2.2 Free version to support IBM software that supports selected partitioning technologies Submit reports to IBM quarterly New Sys DO NOT READ – FOR REFERENCE ONLY: Link to Sub-capacity on XL: Link to sub-capacity on PartnerWorld: In April of 2005 we announced sub-capacity licensing for selected WebSphere and DB2 offerings that run on Unix, i5/OS or OS/400, or Linux when running in partitions created on supported IBM and non-IBM processor systems. Then in April 2006 we added x86 systems using either VMware or Microsoft Virtual Server instead of physical partitioning. In addition, we also provided support for Solaris V10 environments. The current list of IBM middleware offerings which are eligible to use sub-capacity licensing and the list of supported partitioning technologies can be found on Passport Advantage. This site will always have the most current list of both sub-capacity eligible offerings and supported partitioning technologies. To make it easier for customers to track sub-capacity compliance, we also announced the IBM Tivoli License Compliance Manager for IBM Software, which is a no charge version of ITLCM. This version is fully compatible with the existing for-fee version of ITLCM, but can only be used to track IBM software offerings. Customers who want to track non-IBM software can substitute the for-fee version in the compliance process. Any customer who elects to use sub-capacity licenses will need to generate and submit to IBM a report on their sub-capacity usage quarterly, as we discussed on the prior page. For additional information on this April’s enhancements, please refer to the next page. Application A – 2 processor licenses Application B – 4 processor licenses Application C – 8 processor licenses

Sub-capacity Licensing Enhanced April 25, 2006
Supports sub-capacity on x86 systems using: VMware ESX Server VMware GSX Server Microsoft Virtual Server Supports Solaris 10 (Containers) and HP-UX 11i vPAR partitioning technologies Allows Itanium (HP-UX 11iv2) customers to run sub-capacity under trust model until ITLCM 2.3 is released in 1H2007 Announces IBM Tivoli License Compliance Manager for IBM Software V2.2 as the monitoring tool for sub-capacity licensing In April 2006 fulfilled our x86 statement of direction and enhanced sub-capacity with x86 support. Please remember that x86 servers are those which run on chips from Intel and AMD. The other key enhancement was the announcement of support for Sun’s Solaris V10 environment, which is Sun’s latest version of their operating system.

Reference Table: Processor Value Unit Assignment
The following table shows the processor value unit assignment for each server referenced in this presentation: Vendor Sever Brand Processor Value Units per processor core IBM System i 100 System p System p QCM 50 System x Hewlett-Packard ProLiant 9000 Sun SunFire Processors used in the sales scenarios and their processor value unit requirements.

New Processor Value Unit Licensing for Middleware Evolving the Structure to Provide a Foundation for the Future Processor Value Unit Sales Scenarios.

Similar presentations

Presentation on theme: "New Processor Value Unit Licensing for Middleware Evolving the Structure to Provide a Foundation for the Future Processor Value Unit Sales Scenarios."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

New Processor Value Unit Licensing for Middleware Evolving the Structure to Provide a Foundation for the Future Processor Value Unit Sales Scenarios.

Similar presentations

Presentation on theme: "New Processor Value Unit Licensing for Middleware Evolving the Structure to Provide a Foundation for the Future Processor Value Unit Sales Scenarios."— Presentation transcript:

Similar presentations

About project

Feedback