Women and Children First!
The already leaking IT Financial ship has hit the iceberg of recession, and we’re bow-down and sinking fast. Things were bad enough during the “good times”, when companies made money and just wanted to squeeze IT a bit so they could make even more money… now almost everybody is having serious revenue shortfalls, and cutting expense becomes a matter of corporate survival, not mere greed.
We are past the point of arguing whether we should be using wooden lifeboats or inflatable rafts… you use whatever is handy that can get the job done before it’s too late.
The point of this rant: if high on your survival agenda is saving mainframe costs, you need to take a hard look at what your projected NET savings are (savings – costs to implement), and how soon you expect to achieve those savings. Without debating the actual, realizable savings one might achieve in mass migrating existing applications from the mainframe to an alternate platform (the most likely topic for my next epistle), the point remains large migration efforts almost certainly will take more time than you have right now. You need savings this year and maybe next, not a 5-year ROI project. The solutions you should be looking at today need to have both a quick return and a manageable upfront investment.
You have available a few generic approaches to either reduce the size of your mainframe, or (more likely) stave off that next upgrade for as long as you can:
- Peak Management
- Demand Management
- Application Tuning
- Workload Relocation
Note: all of these approaches assume someone or some group in your organization has the information and tools necessary to understand what is being done, when, why, and by whom in your mainframe workload. This information is critical in order to intelligently drive a CPU reduction project.
-
Peak Management: you need to size your mainframe to handle the peak load. Analogy: how big a freeway do you need if everybody in the city drives to work at exactly 8am every day? If you are using 1,000 MIPs from 8am to 5pm, but the machine sits idle for the remainder of the day, you have a huge opportunity. What can you do to adjust the workload to level out the peaks (to have people stagger their commute)? User-driven workload (online transactions, etc.) is difficult to control, but scheduled (batch) workload provides opportunities. Have you analyzed what work is being done during your peak processing periods, and can you move some of it to your slack periods? Bulldoze the workload peaks into the valleys.
-
Application Tuning: are (parts of) some applications just pigs? Can you identify what transactions and batch jobs are major CPU consumers? Are any of them worth a performance code review? Do any of them appear candidates for Demand Management? Again, focus on those things running during the peak periods.
All the above efforts should be well within the capabilities of a seasoned IT department, given some priority-setting and appropriate project leadership. All of them most shops do from time to time, but not always as a focused effort. This may be the time for a focused effort. Pull a team together and task them with holding back the tide. In medium to large environments every month you can defer an upgrade can save hundreds of thousands of dollars in CPU-related charges. The payback can be both large and quickly achieved, especially if aggressive workload management has not been the norm in your shop.
As many of the decisions to be made relate to application and usage-specific questions, engagement of in-house staff is almost always required, but project leadership and direction could come from an external consultant, if no in-house resource is available.
What follows is a more of a medium-term option, but one with both the potential for significant CPU savings. It also has some side benefits as well.
-
Workload Relocation: are there some workloads, or portions thereof, that can be moved to a less expensive platform? The “mass migration” scenario I discarded as a short-term option at the beginning of this article is the extreme example; there are other, faster ways to move some workload off the mainframe. What if instead of moving entire applications, we move only that functionality which can be moved easily and with minimal disruption. The mainframe (and IDMS) architecture stands second to none in being able to deliver stable and well performing transaction-based applications. However; the mainframe has no particular advantage in a reporting or data warehousing application. The proliferation of reporting tools and relational databases of all shape and hue on distributed platforms provides reporting capabilities that are equal to or superior to what the mainframe can provide. What is hard is getting them to work cheaply against mainframe data. As long as the data remains on the mainframe, it takes mainframe cycles to support reporting requests from other platforms.
This has led to a well-understood and widely embraced approach of creating a clone of selected mainframe data on a distributed platform, to support reporting/retrieval processes. Creating these second copies can be done by using a commercial product, or through in-house developed methods (sometimes requiring application modifications).
Back to our dilemma: you need a quick hit. Off-the-shelf can be implemented much much quicker that trying to create a unique in-house solution. Several robust commercial products exist which allow mainframe databases, such as IDMS, to be replicated to these other, cheaper platforms. These products can be implemented generally without any changes to existing mainframe application code. Since many shops already have end-user reporting tools that are used against relational data, providing access to replicated mainframe data may actually be viewed as an enhancement by the end-user community.
The catch is; you need to pick a product and spend some money. So if you choose to look into this option, and as you look at products, consider these questions:
- What workload will you be able to offload? Will it be enough to make this worthwhile?
- How soon can you implement and offload work? How long before I recoup my investment?
- What overhead does a particular replication product add to the mainframe? This eats into your offload savings.
- Any product limitations? What can’t it do that I need it to do? What changes do I have to make to existing mainframe applications or environments?
- Any additional functionality in the product you may need for future projects? If I buy it for simple replication now, what future needs might I have that I need to think about as I commit to a given product?
- Any additional benefits to the company from creating a replicated data store? What benefits can I show the business community from having a local relational copy of mainframe data? Can I allow local applications to access this data?
Bottom line: shops looking to quickly reduce CPU usage, or even just slow the upgrade cycle, should place immediate focus on managing workload and user demand, and tuning those application components which are significant contributors to peak usage. Beyond that one should take a serious look at what specific workloads might be quickly and easily offloaded; either through data replication or other means.
A word from our sponsor: Run Right, LLC would be happy to discuss how we can assist you in putting together a “Save Some Cycles” initiative, including any or all of the above major categories. For report offloading, we can recommend a partner who has what we feel is the most technically sound approach to IDMS replication we’ve seen. Give us a call.
Miscellaneous | Don, 18 May 10 | 
Comments (0) 
