7 opportunities to reduce wlc costs - por Danilo

7 opportunities to reduce WLC costs

May 2015

Proibida cópia ou divulgação sem

permissão escrita do CMG Brasil.

1

Disclaimer, copyright & trademarks

Disclaimer: THE INFORMATION CONTAINED IN THIS PRESENTATION HAS NOT BEEN SUBMITTED TO ANY FORMAL REVIEW AND IS DISTRIBUTED ON AN “AS IS” BASIS WITHOUT ANY WARRANTY EITHER EXPRESS OR IMPLIED. THE USE OF THIS INFORMATION OR THE IMPLEMENTATION OF ANY OF THESE TECHNIQUES IS A USER RESPONSIBILITY AND DEPENDS ON THE USER’S ABILITY TO EVALUATE AND INTEGRATE THEM INTO THE USER’S OPERATIONAL ENVIRONMENT. WHILE EACH ITEM MAY HAVE BEEN REVIEWED FOR ACCURACY IN A SPECIFIC SITUATION, THERE IS NO GUARANTEE THAT THE SAME OR SIMILAR RESULTS WILL BE OBTAINED ELSEWHERE. USERS ATTEMPTING TO ADAPT THESE TECHNIQUES TO THEIR OWN ENVIRONMENTS DO SO AT THEIR OWN RISK.

Copyright Notice:

© EPV Technologies. All rights reserved.

Trademarks:

All the trademarks mentioned here belong to their respective companies.

2



In all figures and reports, numbers are in European format; we use comma for decimals and point for

thousands

3



Introduction

• Saving money on the mainframe is still one of the most important goals of companies running z/OS applications

• There are many ways to achieve this: some require a deep technical analysis whilst others can involve complex organizational issues

4



Introduction

• Most of the z/OS software products are priced with the WLC policy where license fees are determined by the monthly peak of the 4-hour rolling average value of the MSU used

• In WLC there is something simple and very important that you can do to keep the software products bill under control and hopefully reduce it: a daily WLC check

5



Introduction

• You need effective reporting to perform a WLC check daily, to make sure that the money needed for software products is minimised

• While ex-post controls can normally only reduce future costs, in WLC it may also be possible to reduce the current month bill

• We will discuss these checks in the first part of this presentation

6



Introduction

• In addition you should explore WLC cost reduction possibility offered by new hardware and software technologies and pricing options

• In the second part of this presentation we will discuss IDAA and Mobile Workload Pricing

7



Agenda

1. Not a “beautiful” day ?

2. (un)Happy Hour

3. The system you don’t expect

4. The importance of “importance”

5. Could we save more money with zIIP ?

6. IDAA

7. MWP

8



Not a “beautiful” day ?

9




• The first thing to control is on which day the MSU monthly peak has occurred

• You would expect this to happen on a working day and probably on a business-critical day (e.g. month-end or the start of the month)

• A simple report such as the one in the next figure can allow a very easy and quick check

10




11

• Machine is a 2097-717 valued 1,329 MSUs

• Report refers to February 2012 • 4-hour rolling average monthly

peak is 1,309 MSUs • It happened on Sunday • Note the big difference with

the second peak value (354 MSUs)




Bad news

– At this customer site Saturday and Sunday are not business days so a such high value on Sunday has to be considered abnormal

– In this case it was caused by a long, resource heavy recovery activity needed to fix a data corruption issue following the migration to new storage processors which happened on the previous day

12




Good news ? Customers have the primary responsibility for preventing uncontrolled loops, operator errors, or unwanted utilization spikes. However, IBM understands that, occasionally, situations that could not be prevented (especially situations related to disaster recovery) might cause exceptional utilization values. In these situations, IBM does not normally expect customers to pay for the increased utilization associated with the unusual situation. Use your best judgement to determine if an unusual situation has occurred. IBM does not publish a list of unusual situations because, by their nature, they will be unpredictable.

From the “Using the Sub-Capacity Reporting Tool” manual.

13




– WLC rules foresee the possibility to manage “unusual situations” by excluding some hours or days from bill calculation

– This is the reason why being able to intercept and document situations like that is very important

– Talk with IBM …

14



(un)Happy Hour

15



(un)Happy Hour

• Very often the monthly peak occurs on a business-critical day. In this case a next step in the WLC check should be done to verify in which hours of the day the peak occurred

• What triggered customer attention in the next report is the difference between the first peak day and all the other days

16



• Machine is a 2827-711 valued 1.593 MSUs

• Report refers to December 2014

• 4-hour rolling average monthly peak is 1.017 MSUs

• It happened on Friday • The difference with the second

peak value is 97 MSUs

(un)Happy Hour

17

DATE DAY TYPE MODEL MSU USED

19/12/2014 Fri 2827 711 1.593 1.017

03/12/2014 Wed 2827 711 1.593 914

04/12/2014 Thu 2827 711 1.593 866

15/12/2014 Mon 2827 711 1.593 836

30/12/2014 Tue 2827 711 1.593 827

29/12/2014 Mon 2827 711 1.593 824

16/12/2014 Tue 2827 711 1.593 824

18/12/2014 Thu 2827 711 1.593 823

23/12/2014 Tue 2827 711 1.593 809

17/12/2014 Wed 2827 711 1.593 782

24/12/2014 Wed 2827 711 1.593 774

02/12/2014 Tue 2827 711 1.593 738

22/12/2014 Mon 2827 711 1.593 728

05/12/2014 Fri 2827 711 1.593 722

31/12/2014 Wed 2827 711 1.593 702

19/12/2014 Fri 2827 711 1.593 621

01/01/2015 Thu 2827 711 1.593 584

06/12/2014 Sat 2827 711 1.593 574

20/12/2014 Sat 2827 711 1.593 572

25/12/2014 Thu 2827 711 1.593 532

13/12/2014 Sat 2827 711 1.593 261

22/12/2014 Mon 2827 711 1.593 257

28/12/2014 Sun 2827 711 1.593 218

21/12/2014 Sun 2827 711 1.593 213



(un)Happy Hour

• By analysing the peak day at the hour level, our customer realized that something strange had occurred. They normally have the workload peak in the morning so they expect to have the peak of the MSU used in the 4-hour rolling average just after noon

• In fact a high value (907) was reported at 14 (between 14:00:00 and 14:59:59) but in the late afternoon the MSU utilization climbed up to a much higher value (1.017)

18



Looking at the different systems’ contributions, it appeared clear that the peak was due to something running inside the SYS2 system

Our customer asked the technical team for a deeper analysis

(un)Happy Hour

19

SYSTEM 12 13 14 15 16 17 18 19 20 21 22 23

SYS1 96 103 120 130 130 125 106 87 75 69 56 21

SYS2 699 720 746 538 549 594 736 878 898 867 746 580

SYS3 4 4 3 4 5 3 4 4 4 4 3 3

SYS4 44 43 38 35 38 43 49 48 40 39 30 23

TOTAL 843 870 907 707 722 765 895 1017 1017 979 835 627



The late afternoon peak was caused by a TSO user running into a loop

As you can see in the above report, TSO001 used about all the MSUs of 1 CP continuously for about 5 hours

(un)Happy Hour

20

WKL ADDRESS SPACE SRVCLASS MEAN 12 13 14 15 16 17 18 19 20 21 22 23

TSO TSO001 TSO 71 97 138 143 142 141 142 47

JOB BATCH001 BATCHHI 31 4,8 56,3

JOB BATCH002 BATCHHI 25 27,3 49,2 8,6 14,5

JOB BATCH005 BATCHHI 24 31,3 38,8 0,5

JOB BATCH006 BATCHHI 23 29,9 38,8 0,5

JOB BATCH008 BATCHHI 22 8,3 18,8 28,2 49,4 29 19,1 22,7 1,3

DB2 DB2DIST DDFDB2 22 29,5 22,7 33,4 52,4 63 30,7 6,6 5,6 3,3 8,7 3,8 1,2



(un)Happy Hour

Good news ? Customers have the primary responsibility for preventing uncontrolled loops, operator errors, or unwanted utilization spikes. However, IBM understands that, occasionally, situations that could not be prevented (especially situations related to disaster recovery) might cause exceptional utilization values. In these situations, IBM does not normally expect customers to pay for the increased utilization associated with the unusual situation. Use your best judgement to determine if an unusual situation has occurred. IBM does not publish a list of unusual situations because, by their nature, they will be unpredictable.

From the “Using the Sub-Capacity Reporting Tool” manual.

21



The system you don’t expect

22




• Every site runs systems dedicated to different workloads and activities such as production, application development, application test, system test, etc.

• In a normal situation you expect the WLC monthly bill to be mostly related to the amount of MSUs used by production systems

• A report showing the contribution of each system to the MSU monthly peak can be very useful

23



• Machine is a 2097-714 valued 1,139 MSUs

• Report refers to 1 year (Nov 2010-Oct 2011)

• 4-hour rolling average monthly peak is 1,092 in October 2011

• ZNET system consumption doubled in this month


24

DATE TYPE MODEL MSU PROD TST1 TST2 ZNET TOTAL

2011-10 2097 714 1.139 988 10 8 86 1092

2011-09 2097 714 1.139 975 10 9 45 1039

2011-08 2097 714 1.139 913 9 9 40 971

2011-07 2097 714 1.139 873 7 7 39 926

2011-06 2097 714 1.139 965 10 10 44 1029

2011-05 2097 714 1.139 943 10 10 45 1008

2011-04 2097 714 1.139 967 9 9 42 1027

2011-03 2097 714 1.139 961 10 10 44 1025

2011-02 2097 714 1.139 956 10 10 45 1021

2011-01 2097 714 1.139 940 9 9 41 999

2010-12 2097 714 1.139 944 8 8 43 1003

2010-11 2097 714 1.139 923 10 10 44 987



• ZNET workload used to be very stable

• something happened on October 24th

• It was Monday ! • First idea was to check for

maintenance activities performed in the week end


25

DATE DAY MSU SYSA TST1 TST2 ZNET TOT

16/10/2011 Sun 1.139 395 5 5 18 423

17/10/2011 Mon 1.139 886 7 7 43 942

18/10/2011 Tue 1.139 896 8 7 43 954

19/10/2011 Wed 1.139 869 9 8 43 928

20/10/2011 Thu 1.139 851 8 7 45 910

21/10/2011 Fri 1.139 796 7 7 41 850

22/10/2011 Sat 1.139 684 5 5 24 718

23/10/2011 Sun 1.139 376 5 5 16 402

24/10/2011 Mon 1.139 863 7 7 79 955

25/10/2011 Tue 1.139 891 9 7 78 985

26/10/2011 Wed 1.139 900 10 8 78 996

27/10/2011 Thu 1.139 892 8 8 79 987

28/10/2011 Fri 1.139 842 7 7 75 931

29/10/2011 Sat 1.139 698 5 5 40 748

30/10/2011 Sun 1.139 385 5 5 38 433

31/10/2011 Mon 1.139 979 7 7 84 1077

01/11/2011 Tue 1.139 988 10 8 86 1092




• A more detailed ZNET workload analysis showed a correspondent CPU increase of the session manager address space

• The new version of the session manager caused such a big increase (about 40 MSUs).

• In this case most of these MSUs were recovered thanks to some PTFs

• Being able to measure and report this issue gave the customer the possibility of discussing the October and November monthly bills with IBM in order to reduce them

26



The importance of “importance”

27




• Once you verified that WLC monthly peaks occur on business-critical days, in business-critical hours and they are due to business-critical systems, the next check you have to perform is about the “business importance” of the workloads which used most of the MSUs and determined the monthly software bill

• It is not by chance that WLM, decides which workload can use the system resources (CPU, memory, etc) based on a parameter called “importance”

28




• There are five levels of importance for user workloads; they range from 1 (highest) to 5 (lowest). In addition there are system related workloads (more important and referred as importance 0 workloads) and discretionary workloads (less important than any other workload and referred as importance 6)

• WLM “importance” has to be carefully matched to the “business importance” of the workload in order to provide the appropriate support to the company business

29




30

DATE IMP 0-6 IMP 0-5 IMP 0-4 IMP 0-3 IMP 0-2 IMP 0-1 IMP 02015-01 1.087 920 713 628 440 387 140

2014-12 1.167 1.017 590 513 373 323 143

2014-11 1.163 1.013 655 565 351 301 146

2014-10 1.028 847 485 426 291 223 117

2014-09 1.004 841 512 461 302 251 124

2014-08 1.006 833 498 459 314 257 133

2014-07 1.044 862 410 359 283 224 129

2014-06 1.090 924 499 414 295 239 136

2014-05 1.114 952 603 523 323 260 123

2014-04 1.117 946 554 513 299 249 150

2014-03 1.128 970 548 465 302 245 182

2014-02 1.071 900 486 392 292 232 149

2014-01 1.095 899 569 525 293 234 133

IBM 2827 Model 709 - 1.350 MSU




31


2014-12 1.167 1.017 590 513 373 323 143

2014-11 1.163 1.013 655 565 351 301 146

2014-10 1.028 847 485 426 291 223 117

2014-09 1.004 841 512 461 302 251 124

2014-08 1.006 833 498 459 314 257 133

2014-07 1.044 862 410 359 283 224 129

2014-06 1.090 924 499 414 295 239 136

2014-05 1.114 952 603 523 323 260 123

2014-04 1.117 946 554 513 299 249 150

2014-03 1.128 970 548 465 302 245 182

2014-02 1.071 900 486 392 292 232 149

2014-01 1.095 899 569 525 293 234 133

IBM 2827 Model 709 - 1.350 MSU

• In this report each IMP 0-n column shows the MSUs used in the 4-hour rolling average by all the workloads having an importance less than or equal to n




32


2014-12 1.167 1.017 590 513 373 323 143

2014-11 1.163 1.013 655 565 351 301 146

2014-10 1.028 847 485 426 291 223 117

2014-09 1.004 841 512 461 302 251 124

2014-08 1.006 833 498 459 314 257 133

2014-07 1.044 862 410 359 283 224 129

2014-06 1.090 924 499 414 295 239 136

2014-05 1.114 952 603 523 323 260 123

2014-04 1.117 946 554 513 299 249 150

2014-03 1.128 970 548 465 302 245 182

2014-02 1.071 900 486 392 292 232 149

2014-01 1.095 899 569 525 293 234 133

IBM 2827 Model 709 - 1.350 MSU

• IMP 0-6 accumulates the MSUs used by all the workloads while IMP 0-5 accumulates the MSUs used by all the workloads excluding importance 6 workloads (running with a discretionary goal)




2014-12 1.167 1.017 590 513 373 323 143

2014-11 1.163 1.013 655 565 351 301 146

2014-10 1.028 847 485 426 291 223 117

2014-09 1.004 841 512 461 302 251 124

2014-08 1.006 833 498 459 314 257 133

2014-07 1.044 862 410 359 283 224 129

2014-06 1.090 924 499 414 295 239 136

2014-05 1.114 952 603 523 323 260 123

2014-04 1.117 946 554 513 299 249 150

2014-03 1.128 970 548 465 302 245 182

2014-02 1.071 900 486 392 292 232 149

2014-01 1.095 899 569 525 293 234 133

IBM 2827 Model 709 - 1.350 MSU


33

• The difference between these two columns is the contribution of discretionary workloads to the software bill

• At this customer site, this difference was very high in every month




34




• In January 2015 the difference was 167 MSUs (You have to consider the highest values of IMP 0-6 and IMP 0-5 in the month even if occurring on different days)

• This means that a lot of money could have been saved if these discretionary workloads (batch jobs in this case) were scheduled in non-peak hours

35




• These numbers are estimates based on SMF 72. The following steps are needed:

transform the CPU and SRB service units, provided in the SMF 72 records, into MSU used values

increment the CPU usage accounted to WLM service class periods in order to account for the uncaptured CPU

sum MSU by WLM importance

calculate the MSU 4-hour rolling average based on WLM importance

36



Could we save more money with zIIP ?

37




• Moving as much work as possible to zIIP is a key point in the strategy of any customer who really wants to reduce hardware and software costs

• Because of the complexity of the current systems it is not uncommon to find customers having consistent zIIP eligible work running on standard CPUs so increasing the monthly software bill

38




• The most common reasons for this undesired result are :

wrong PRSM and system parameters

missing PTFs

loops

not enough zIIP available due wrong estimates in the Capacity Planning process

39



DATE CURR NO IIPCP

2014-10 1267 1156

2014-09 1218 1092

2014-08 1182 1076

2014-07 1206 1146

2014-06 1200 1140

2014-05 1194 1134

2014-04 1188 1129

2014-03 1152 1094

2014-02 1134 1077

2014-01 1128 1128

2013-12 1140 1140

2013-11 1110 1110

2013-10 1120 1120

• The CURR column shows the MSUs used in the 4-hour rolling average

• NO IIPCP is an estimate of what the CURR value would be if enough zIIP was available


40



• IIPCP was always substantially less than CURR

• In October 2014 peak hour the difference is 111 MSUs


41

DATE CURR NO IIPCP

2014-10 1267 1156

2014-09 1218 1092

2014-08 1182 1076

2014-07 1206 1146

2014-06 1200 1140

2014-05 1194 1134

2014-04 1188 1129

2014-03 1152 1094

2014-02 1134 1077

2014-01 1128 1128

2013-12 1140 1140

2013-11 1110 1110

2013-10 1120 1120




42



• Considering the highest values of CURR and NO IIPCP in October 2014, even if occurring on different days, the difference between CURR and NO IIPCP was 75 MSUs

• This means that a substantial amount of money could have been saved if more zIIPs were available

43




• These numbers are estimates based on SMF 72 (SMF 30 can also be used); the following steps are needed:

transform CPU and SRB service units, provided in the SMF 72 records, into MSU

increment the CPU usage accounted to WLM service class periods in order to account for the uncaptured CPU

sum MSU by separating CPU only work from zAAP and zIIP eligible work running on CPU

calculate the MSU 4-hour rolling average based on zAAP and zIIP eligibility

44




IDAA

45



46

IDAA

• The new ACCELMODEL parameter (which can be set to YES or NO) provides indicators for possible CPU and elapsed time savings if IDAA was available

• It does not require presence of the accelerator

• If set to YES, DB2 accounting records include projected CPU, zIIP and elapsed time savings

• Some additional actions are needed

46 Proibida cópia ou divulgação sem


47

IDAA

• For dynamic SQL statement assessment, use the RUNSTATS utility for target table spaces or restart DB2 to invalidate corresponding dynamic statement cache entries. ACCELMODEL needs to be set to YES during statement execution for Accelerator modeling.

47

from ‘Reliability and Performance with IBM DB2 Analytics Accelerator Version 4.1’

IBM Redbooks SG24-8213-00



48

IDAA

• For static SQL statement assessment, you must issue a BIND or REBIND PACKAGE for the DB2 packages you plan to include for this workload assessment. You may use option APREUSE(ERROR) with the REBIND PACKAGE statement to make sure that the current access plan remains unchanged. ACCELMODEL=YES is required during BIND/REBIND only, not at static SQL statement execution time.

48

from ‘Reliability and Performance with IBM DB2 Analytics Accelerator Version 4.1’

IBM Redbooks SG24-8213-00



49

IDAA

• Functionality delivered via two DB2 10 APARs

PM90886: for IDAA V3 (dynamic SQL support)

PM95035: for IDAA V4 (add static SQL support)

• Functionality delivered via one DB2 11 APAR PM96478: for IDAA V4 (add static SQL

support)



50

IDAA

• Three new accounting fields will be added to the QWAC section of the IFCID 3:

QWAC_ACCEL_ELIG_ELA, the accumulated elapsed time in DB2 eligible for execution on IDAA

QWAC_ACCEL_ELIG_CP, the accumulated CPU time in DB2 eligible for execution on IDAA

QWAC_ACCEL_ELIG_SE, the accumulated CPU time in DB2 used on a zIIP eligible for execution on IDAA



51

IDAA

• IDAA is not free

• So the question is: IDAA CPU savings will justify the additional IDAA cost ?

• Every company should answer this question; the answer will mostly depend on workload characteristics and software licensing policies



52

IDAA

• In this case we have to evaluate the reduction which could be obtained in the monthly peak of the MSU used in the 4 hour rolling average

• MSU used by replication are not considered here



53

IDAA

• The following steps need to be performed to estimate MSU savings: Activate accelerator modeling on the appropriate

workloads

Collect SMF 101 data for an adequate period of time

Distribute the CPU consumptions of long running threads across the elapsed hours

Calculate the hourly CPU seconds used by summing all address space or service class consumption across all the CEC LPARs

Calculate the hourly CPU seconds eligible to the IDAA by summing QWAC_ACCEL_ELIG_CP across all the LPARs



54

IDAA

Increment both values in order to account for the uncaptured CPU

Transform CPU seconds in MSU

Subtract the IDAA eligible MSU from the total MSU

Calculate the monthly peak of the MSU used in the 4-hour rolling average

Compare this value with the «real» value of the monthly peak of the 4-hour rolling average MSU

Convert the MSU reduction, if any, to money savings



55

IDAA

• Test done on just one week; it seems that interesting MSU savings could be expected

• Values are overestimated; they have to be checked in more detail

55

CEC1 CEC2



MWP

56



57

MWP

• On May 6th 2014 IBM announced Mobile Workload Pricing for z/OS (MWP)

• This new pricing model is designed “to mitigate the impact of mobile workloads on sub-capacity license charges and provide a more cost-competitive software”



58

MWP

• Key prerequisites for enabling MWP include:

Run z/OS V1 or z/OS V2

Run on a z13, zEC12, zBC12, z196 or z114 server that has implemented sub-capacity pricing under AWLC or AEWLC

Run one or more of the Mobile Workload Pricing Defining Programs (CICS, IMS, DB2, WebSphere and Websphere MQ latest versions)

Mobile Workload Reporting Tool (MWRT) has to be used instead of SCRT, to submit the WLC monthly reports to IBM



59

MWP

• MWP Contractual Requirements IBM authorizes the use of MWRT only when you have signed or otherwise agreed to the terms of the MWP contract: the IBM Addendum for System z Mobile Workload Pricing (Z126-6300).

The MWP contract has an associated supplement form (Z126-6628) where you will describe your mobile application name, the MWP Defining Programs used, the data source used to track the CPU time of mobile transactions, an explanation of how mobile transactions CPU time will be distinguished from that of other workloads, and the process for capturing and processing the mobile data.

IBM must approve the process used to capture the records for mobile transactions that will be used for monthly reporting.



60

MWP

• MWRT removes 60% of the mobile workload, interval-by-interval, on each LPAR where mobile workload runs

• Non-mobile workload will be unchanged

• Customers will get a cost reduction when mobile workloads contribute to monthly peak MSUs

• Off-peak mobile workloads will not affect the MSUs used for billing



61

MWP

• Example 1:

The monthly peak of the 4-hour rolling average is 980 MSUs and in that peak no mobile workload is running

In this case the discount will be 0 and the charged MSUs will remain 980



62

MWP

• Example 2:

The monthly peak of the 4-hour rolling average is 980 MSUs and, in that peak, the 4-hour rolling average of the reported mobile workload is 300 MSUs

In this case 180 MSUs (60% of 300) will be discounted reducing the chargeable MSUs to 800

If this is still the monthly peak 800 MSU will be charged



63

MWP

• Example 3:

The monthly peak of the 4-hour rolling average is 980 MSUs and, in that peak, the 4-hour rolling average of the reported mobile workload is 300 MSUs

In this case 180 MSUs (60% of 300) will be discounted reducing the chargeable MSUs to 800

If, after the discount, the peak is in a different hour of the month, the newly recalculated MSU peak will be charged



64

MWP

64

0

200

400

600

800

1000

1200

4

H

R

o

l

l

i

n

g

A

V

G

M

S

U

Chargeable MSU reduction due to Mobile Workloads

MSU after Mobile discount MSU

1021

880

800



65

MWP

• IBM defined the format for Customer CSV file providing mobile transaction input to MWRT

• There must be a separate CSV file for each product family, i.e. CICS, WebSphere MQ, IMS, WebSphere or DB2

• Customers have to prepare all these CSV files



66

MWP

• The first row is the Product row containing the product id (or ids) for all the versions of a particular product family the customer is using for mobile workload processing



67

MWP

• Column one of the Header row is the date header; either:

Date indicating that all times are local in ISO-8601 format

DateUTC indicating that all times are in UTC in ISO-8601 format



68

MWP

• The subsequent columns of the Header row must contain the LPAR names:

just the LPAR name (e.g. “SYSF”), or

type-serial:LPAR name (e.g. “2827-0F4D7:SYSF”)



69

MWP

• Then each cell in the mobile transaction data row must have CPU seconds for that hour in that LPAR as a floating point number



Conclusions

• In this paper we presented 5 important checks that you need to perform in order to keep WLC based costs under control

• We also showed how, effectively designed WLC reports allow you to perform these checks very quickly and easily

• Being able to clearly identify issues make it possible not only to reduce next month’s costs but, depending on the issue, can even reduce the current month’s bill

70



Conclusions

• New hardware and software technologies have to be evaluated to verify if they can provide real cost savings

• Also in this case effectively designed reports are needed

• The same is true for new software licensing options

71



Questions ?

72



Obrigado!

Thank you!

Grazie Mille!

73

Danilo Gipponi



Technology

7 opportunities to reduce wlc costs - por Danilo