Admin Alert: Before You Buy That New System i, Part 1

Published: January 16, 2008

by Joe Hertvik

It's not unusual for some companies to upgrade their System i servers every three years, which means that an upgrade may be in your near future. To help navigate the upgrade process, this week and next I'll present a list of upgrade pitfalls to avoid. These pitfalls can cause delays, compatibility issues, and budget overruns. For your sanity and job security, watch for these costly mistakes when upgrading to a new machine.

Pitfall #1: Forgetting About Software License Transfer Fees

As you create your upgrade budget, find out what license transfer fees are associated with any third-party i5/OS software that you will be transferring from your existing machine to the upgraded or replacement System i box. Chances are excellent that one of your vendors will ask you for more money to run their software on a larger machine. And it's best to talk to all of your vendors before you submit your capital request, because you will probably need extra money in the budget to cover these fees.

The way it works is that vendors have traditionally priced their software according to the size of your machine. In the past, most System i, iSeries, and AS/400 vendors would price software according to the machine's processor group (P05, P10, P20, etc). When you upgraded to a larger machine in a different processor group, the vendors would generally ask for the difference in price that they charged for the software between the old and new processor groups. If they sold the software for P10 machines for $5,000 and the P20 version cost $7,500, for example, then the vendor would ask you for the $2,500 difference when you upgraded your machine from a P10 model to a P20 model. The theory was that by using a larger machine, your organization got more benefits from the software and the software could service more users. The vendors used this justification to charge different prices when you moved the software to more powerful machines.

As you can imagine, this scenario led to some rather bizarre situations. When I was working for a manufacturing company in the 1990s, for instance, we upgraded to a more powerful machine and we wound up paying just as much in upgrade fees for our primary manufacturing software as we had paid for the AS/400 itself. And many old-time AS/400, iSeries, and System i veterans have similar war stories involving this practice.

However, a problem arose with processor group pricing as IBM continued to increase the processing power in its iSeries and System i product line, with the result being that companies could easily upgrade to a more powerful machine without changing processor groups. Customers relished this situation because they thought they could upgrade to a faster machine without changing processor groups, keeping their pricing down in the bargain. To adjust to the change, some vendors changed their pricing structures to create software pricing tiers that charged customers according to the new machine's Commercial Processor Workload (CPW) ratings or another pricing tier of their own devising. The result is that some vendor pricing schemes have morphed their forms but many still retain the same basic structure of processor group licensing, which is the belief that a third-party vendor is entitled to a higher licensing fee if you move their software onto a more powerful machine.

Granted, not all vendors will charge you differential pricing when you move your software to a new box. There are other models that System i vendors use to handle moving licenses from one box to another during an upgrade. Some vendors will charge you a minimal fee ($500 or less) to move the software. Some vendors handle licensing fees under the terms of your maintenance agreement and the move will be free as long as you're current on maintenance. Others will waive the fees, and yet others won't care at all if you move the software as long as you are not running it on more than one box without a license. One vendor I spoke with recently even offered to redo my older software license to take some of the pain out of moving the license. It's been my experience that different vendors treat license moves in different ways and it's wise to check with all of them when budgeting an upgrade.

So as you're putting together the capital request for a System i upgrade, my recommendation is to contact all the third-party vendors that you’ve bought software from, obtain any price increases or license fee transfers that you may need to purchase for the upgrade, and then build those costs into your budget or capital request. After all, it's better to prepare management for these costs before the machine is ordered then after.

Pitfall #2: Understanding the Costs of New Tape Technology

This problem occurs when you upgrade your tape drive architecture, such as when you trade in your old 3590 drives for a brand new LTO-4 tape drive. While the benefits of using the new technology are apparent (fewer tapes, faster backups, hardware-based encryption technology, etc.), these drives also have a not-so hidden cost associated with them. And that cost is tape.

If you're migrating to a different tape media, don't forget that you'll need to buy enough tapes to replace your daily, weekly, and maybe even your monthly tape inventory. And at prices that can exceed $50 per tape, buying these tapes can easily blow a hole in your budget. If you haven't budgeted for this increased cost, you may be forced to steal money from other budget categories to cover this expense.

When budgeting for tapes during an upgrade, you generally have a few options.

• If you know that you're going to be buying a new tape drive with an upgrade in the next fiscal year, you can include costs for new tapes in your operational budget for the upcoming year. If approved, you will be able to purchase the tapes outside of your capital request as you purchase your new drive.
• If you don't have the budget for new tapes, you can shoot for smuggling enough new tapes in under the operating budget to get you through the end of the year and then budget for the rest of the tapes in the next fiscal year. Alternately, you can request money for more tapes as you need them. The funny thing about tapes is that they are a necessary evil that can usually be purchased under a manager's authority. If approval is needed, most managers won't turn down a request for more tapes, because it's a major operational problem and an audit point if the system is not backed up.
• You can include the cost of the tapes in your capital request.

The important point is: Don't forget to budget for tapes as you're budgeting for your upgrade.

The other tape-related item to consider in an upgrade is what to do about your existing inventory of monthly and yearly tapes. Many companies have audit schedules or Sarbanes-Oxley requirements that force IT departments to store monthly and yearly tapes for up to seven years. So a secondary cost of tape drive acquisition is to determine what options you have for restoring archived material from obsolete tape formats. One option is that if your old tape drive still works, you can purchase an interface card and hook the old drive up to your new machine for archival restores only. If you cannot or you do not want to use your old drive, you can attempt to transfer your archived tapes from old media to new media by using the Copy to Tape (CPYTOTAP) or the Copy from Tape (CPYFRMTAP) commands, if both tape drives can be attached to the same machine.

More To Watch Out For

While these problems can rear up and bite you when upgrading to a new System i, they aren't the only issues that can affect your purchase. Next week, I'll discuss some other costly project pitfalls that involve which i5/OS operating system you'll be upgrading to, the need for more power, and making sure that you have everything that's needed for the upgrade.

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot