The Four Hundred

While the pricing levels on the new iSeries machines announced on January 20 will in large measure determine how well or how poorly the iSeries does at new and vintage AS/400 accounts, the pricing for upgrades and the means by which more current customers--those with 7XX and 8XX boxes--have to upgrade is probably a more immediate factor in the short-term success of the new offering. Upgrading is never a painful process, no matter what the vendors say.

Over the next several weeks, I'm going to be examining issues concerning upgrading to the new iSeries. This week, I'm just going to get into what upgrades are available and what processes are required, based on the information I have been able to gather, to perform an upgrade to a new iSeries machine. This is not a manual for guiding you through an upgrade, but rather a way for you to figure out if an upgrade, rather than sticking with your existing AS/400 or iSeries line and upgrading that machine or doing a push-pull box swap, is in your best interests. I hope you find it useful.

First, let's answer the burning question that everyone has been asking me in the past couple of weeks. If you are a customer with a Model 270, Model 7XX, or Model 8XX server and you want to upgrade to one of the new machines, what do you have to buy as part of the upgrade if you have already acquired some or all of the software that IBM has included in the Standard or Enterprise Edition of OS/400? If you are, for instance, a Model 840 customer who has bought WebSphere middleware, Tivoli systems management programs, and a whole slew of IBM code that is included in OS/400 Enterprise Edition, you might think you do not need to pay full price for that software, especially if you loaded a lot of interactive capacity on that Model 840 as well, which cost big bucks. Well, you'd be wrong, at least in the official IBM view. This is going to be a sticking point with a lot of OS/400 shops, and I expect them to make a lot of squeaking noises, and, more important, I expect that IBM will grease the squeaks just so it can get a deal done. That is not an official IBM statement, but an observation of human nature.

Sources I spoke to within IBM last week said that this policy was meant to simplify the upgrade process; it makes a simple rule that everyone can understand. I figure that it also ensures that IBM gets some money to cover the deep price cuts on hardware and interactive processing capacity that it has made with the revamping of the iSeries line. This is also an admission by IBM that the penetration of many of the elements of the Enterprise Edition--except the 5250 OLTP capability--are not pervasive in the OS/400 installed base. And to IBM's thinking, most customers haven't bought this code, so it is not double-charging them for it. A lot of companies that have bought the programs in the Enterprise Edition are going to feel this way, however, and those that have bought a lot of interactive capacity or the full interactive capacity are certainly going to explain to IBM that they have already paid for it. A lot depends on the numbers, which I am compiling now for next week's issue. (This is a bear of a table, so bear with me. There are so many different possible interactive-to-edition upgrade paths and prices to plug in that this table is taking some time to build. I'll make it worth your wait.) In any event, IBM has no intention of giving any special dispensation to small or midsized customers when it comes to prior software licensing fees, but, as usual in the IT industry, IBM will be willing to work with its biggest customers who have lots of this code because, quite frankly, it doesn't have a choice.

Some advice: If you are a midrange shop, start talking to IBM like an enterprise shop and see what happens. Figure out what you have already invested in IBM software and interactive features and run these numbers against what you reckon your current machine is worth and what IBM is charging for a new iSeries box. The math has to work for the deal to get done, and IBM knows this. The problem right now is that second-hand Model 270, 7XX, and 8XX prices are in flux because of the announcements, and until the market reckons with the new upgrade pricing, it won't know how to value the older equipment. The new machines don't even start shipping for two more weeks, so we have time to figure it out.

Customers on Software Subscription who have current V4R5, V5R1, and V5R2 licenses will have the easiest time doing an upgrade. If customers do not have Software Subscription on a machine that they want to upgrade to a new machine, my sources at IBM say that they will first have to pay the after-license charges on their software, to bring it to the current level, and then perform the upgrade to the new machine. This sounds a bit draconian, but again, depending on the situation, IBM might give on this just to close a deal. If you find yourself in this situation, be sure to examine the cost of just bringing in a whole new iSeries box and getting rid of the old one on the second-hand equipment market before you pay those after-license fees. You may end up saving money and grief that way.

Here's generally how an upgrade to a new model works. The upgrade of the basic server chassis--say from a Model 270 to a Model 810--is a free upgrade. From there, two items are priced: the processor feature upgrade and the upgrade from a specific interactive level to a feature for the Enterprise Edition of OS/400. AS/400 and iSeries servers with zero interactive processing capacity in the Model 270, 7XX, or 8XX lines can upgrade to an appropriate processor. Customers can add the Standard Edition to the new iSeries machine if they want to stay at zero interactive capacity, or they can move to the Enterprise Edition. Customers with any interactive capacity on their Model 270, 7XX, or 8XX machines have to automatically move to the Enterprise Edition, whether they have the base or the full interactive capacity on that box. They cannot "downgrade" to a Standard Edition machine.

Here are some tables that will help get you started in thinking about your future upgrade plans:

I realize that this information, as presented, is only useful if you want to build your own upgrade scenario. That's why I am building a giant set of tables that brings it all together, so you don't have to.

There are a couple of things that are immediately obvious from the first table. There are no upgrades to the Model 800. If you have a Model 150, Model 170, Model 250, or low-end Model 270 server and you were hoping to be able to do an upgrade, you are doing a box swap if you want to move to the new entry Model 800 iSeries machine. And if you are a Model 270 customer, your only upgrade option is to the Model 810 machine, and it is the largest Model 810 (processor 2469 with the Enterprise Edition) that you will be upgrading to. This is a two-way 750 MHz S-Star server that is rated at 2,700 CPWs. What you will also notice is that there are no upgrades out of the Model 800 or Model 810 machines, which are based on S-Star processors, to the Model 825, Model 870, or Model 890 machines, which are based on Power4 processors. If you buy into the Model 800 or Model 810 lines, you will have to do a box swap to move up to the new iSeries line. The processor technologies in these machines are so different, an upgrade is almost meaningless. However, many peripherals will move forward as you upgrade higher into the new iSeries line.

One last thing for this week: If you have an AS/400 Model 7XX machine and you are considering upgrading to the new boxes, IBM will only offer upgrades through October 8, 2003. Customers who linger will have to stay in the 7XX line and buy used parts or buy used upgrades to the first-generation iSeries 8XX machines. IBM is obviously interested in getting customers to make up their minds relatively fast, since it wants to boost iSeries revenues in 2003 and show a lot more profit, to make Wall Street and the IBMers whose bonuses are tied to IBM's profits happy.

In the coming weeks, I will detail upgrade pricing and go through some of the pointers and pitfalls related to the upgrade process. I also have some advice from IBM in dealing with an upgrade to these new iSeries servers.

Sponsored By

BOSANOVA

Disaster Recovery Assistance for Twinax Users

The Best Way to Keep Twinax Users Working is with a Pure TCP/IP Controller

In most disaster recovery scenarios these days TCP/IP is the protocol of choice for switching between machines. Most solutions to switch users from the primary AS/400 to the back-up AS/400 require that the IP address under which the AS/400 appears be changed. For example, say that the production AS/400 has IP address 10.1.1.10, while the back-up AS/400 normally uses 10.1.1.20. In the event of a disaster, the back-up AS/400 switches to 10.1.1.10. All the PC users using TN5250 do not have to change their settings; they simply restart their sessions and sign back on.

What Happens to Twinax Users?
In the same scenario, Twinax users suffer a harsher plight. During disaster recovery the local Twinax users can be left without any access to the back-up AS/400. Remote Twinax users usually can be switched over using some scripts on the AS/400, however is often a challenge.

Is There a Better Way?
IP-based Twinax controllers like the e-Twin@x Controller can easily switch between AS/400's because they treat Twinax users the same way they treat the PC users, once the session is reset. The e-Twin@x Controller, as a matter of fact, does this automatically; the users can sign on to the back-up AS/400 and continue to work, without any operator intervention!

What About Locally Attached Twinax Users?
Even locally attached Twinax users can work in this fashion, using the 47xx local e-Twin@x Controller series. These very aggressively priced controllers are designed to work in a local Twinax environment. All the local Twinax cables connect into the 47xx Controller in place of the local Twinax controller resident in the AS/400. The 47xx connects to the AS/400 over the built-in 10/100 MHz Ethernet card, ensuring fast response times. The 47xx Controller will switch over to the back-up AS/400, provided it is on the same IP subnet as the production machine.

Special Features for Switch-Over
The e-Twin@x Controller includes the following special features, which are especially relevant for disaster recovery situations:

DNS Look Up
The e-Twin@x Controller has the ability to configure the AS/400 via a DNS name instead of IP address. A timer in the e-Twin@x Controller refreshes the DNS look up every time it expires. This way, the System Administrator changes the internal DNS server, which lists the AS/400 domain name, and after the timer expires, all the devices are automatically changed to the new IP address.

Auto Reconnect
If the connection to the AS/400 is lost, the e-Twin@x Controller tries to re-establish the connection, without user intervention, after a predetermined time-out period.

Default Rollover
Two AS/400's can be configured to act as default and back-up, respectively. When the primary (default) AS/400 can no longer be accessed, the e-Twin@x Controller automatically attempts to connect to the secondary (back-up) AS/400. After successful connection to the back-up AS/400, it will stay connected to that AS/400 until the e-Twin@x Controller is reset, which can be done by using a Web browser.

By the way, you can define that the process be reversed if the first host is also defined as a backup system (for the secondary host). In this case, if the backup system fails (or if the TCP/IP interface is terminated), all sessions will be re-connected to the primary system.

www.e-twinaxcontroller.com