The Four Hundred

After reading last week's Admin Alert on changing OS/400 IP addresses, an IBM staff software engineer on the TCP/IP and Internet Support Team wrote in to correct me on one particular paragraph in that piece. As you might expect, this engineer made a few good points about keeping TCP/IP active while making changes, which you should be aware of when you make changes to TCP/IP addresses on your AS/400 and iSeries servers:

The statement "To change an OS/400 IP address, TCP/IP must be turned off" is incorrect. The correct way to do the procedure [is to] add the new interface, activate it, test it, then end the old interface at your leisure. All while TCP is Active! The other steps can be done while TCP is active. With TCP inactive, there is little to no error checking on the parameters entered. Which means a customer can enter an incorrect route or interface, and that may cause serious problems when TCP is started again.

I'm glad our reader wrote in, because he has a good point about performing these steps while TCP/IP is active. TCP/IP rides on top of a line description, and taking down TCP/IP isn't critical to changing an IP address, although it's sometimes necessary. And, in many cases, you should be able to perform most of the tasks in last week's column with TCP/IP active (though you may have to change the order of those tasks a bit, so that you add and activate the new interfaces and routes before you delete the old interfaces and routes). Our reader also pointed out that there are some error-checking algorithms that run while TCP/IP is active, and if TCP/IP is down the system will allow you to add incorrect parameters on an address change. So in addition to not having to schedule downtime for a TCP/IP address change, there are other benefits to performing an IP address change while TCP/IP is up.

So I stand corrected and encourage you to think about following IBM's advice and evaluate whether you can make IP address changes while TCP/IP is active. If you're able to do so, you'll enjoy two benefits: You won't have to endure any AS/400 downtime and TCP/IP will perform some error checking when the new interfaces are activated.

The only downside to IBM's recommendation is that you still won't be able to avoid disconnecting your network connection for all IP address changes. Here's a situation I ran into recently. A shop with approximately 15 AS/400s had to go through an IP address change due to a change in ownership, which meant the company was swapping in a new network infrastructure with different subnet addresses in the same location. For each AS/400, the techies had to physically move the Ethernet cable from the old hub to a new hub in the new infrastructure. This meant that they had to turn off at least the network line description in order to effect the change (note that, although they didn't necessarily need to turn off TCP/IP in this case, disconnecting their network card had the same effect of killing TCP/IP traffic). There was no way to maintain communications, so the company had no choice but to take the outage during the change.

While IBM's advice is good and may cover a majority of situations, there are still times when you'll need to disconnect network communications to process a change, experiencing downtime in the process. Luckily, most companies provide maintenance windows and people turn off OS/400 TCP/IP and vary off network cards all the time for a number of different system changes (including hard drive installations, increasing memory, or even something as simple as full system backups). Sometimes the best way to make a change is to start from scratch when nobody is on the system. But you'll need to inform your users ahead of time that they will be losing network connectivity, and schedule the downtime so that it doesn't affect your production systems.

The point is that it is as wrong to say that TCP/IP address changes should always be made when network connectivity is down as it is to say that they should always be made when network connectivity is up. There are circumstances where one or the other method should be used, and it's the wise administrator who knows when to use each technique.