Admin Alert: Things to Check After Upgrading OS/400 V5R1 to V5R3

February 2, 2005 Joe Hertvik

In the last few columns, I’ve covered basic information on upgrading a multipartitioned OS/400 V5R1 machine to V5R3 (i5/OS). This time, I’ll switch gears and cover some items to check after the upgrade is done. Here are some things that I recently discovered after performing three such upgrades.

Checking Out What’s Changed

The best reference for finding V5R3 operating system changes is an IBM manual called iSeries Memorandum to Users: Version 5 Release 3 (June 2004 Update) (in PDF format). This manual reviews many of the changes IBM made between OS/400 V5R2 and V5R3, and it should be reviewed before you install V5R3, as well as after the installation if problems occurred. Since you’re upgrading from OS/400 V5R1 to i5/OS V5R3, you should also download and keep handy a copy of the iSeries Memorandum to Users: Version 5 Release 2 (May 2004 Update) (also in PDF format), which lists OS/400 changes that occurred between V5R1 and V5R2 (these changes aren’t listed in the V5R3 book). You can use these two books as a fairly complete reference for looking up new features that might need adjustment to work in your processing environment.

Beware of the New Default Job Descriptions

With OS/400 V5R3, IBM added a new default job description called QDFTSVR in library QGPL. Many V5R3 service jobs, including OS/400 servers such as the QRWTSVR DDM jobs and the QZDASOINIT database server jobs, will automatically start using QDFTSVR immediately after the upgrade. In OS/400 V5R1 and V5R2, these jobs used the older default job description, QDFTJOBD, in library QGPL. This means that if you altered the QDFTJOBD job description to match your environment, you should compare the altered QDFTJOBD with the new QDFTSVR job description and then change QDFTSVR to match whatever changes that you previously applied to QDFTJOBD. If you don’t do this, you might get mixed results when server jobs that rely on QDFTSVR start running.

This issue doesn’t just affect QRWTSVR and QZDASOINIT. It also affects a number of other server jobs, like QZLSFILE (which is used for AS/400 NetServer), QSQSRVR (OS/400’s SQL server jobs), as well as the QPWFSERVSO, QPWFSERVSS, and QPWFSERVS2 server jobs used for TCP serving. A more complete list of server jobs that use the new job description can be found in the V5R3 Memorandum to Users manual.

Getting Rid of Unnecessary Communications Messages

After completing each of my V5R3 upgrades, I noticed the following TCP2617 message kept recurring in my QSYSOPR message queue: “TCP connection to remote system &2 closed, reason code &5.”

Where &2 and &5 were parameters representing the TCP/IP address of a closed connection (&2) and a reason code designating a short explanation on why the connection was closed (&5).

Since the messages were relatively benign, and they quickly started cluttering up my QSYSOPR message queue, I researched the issue and found that you can stop i5/OS from issuing TCP2617 messages by using the following Change TCP/IP Attributes command (CHGTCPA) from a green screen:

CHGTCPA TCPCNNMSG(*NONE)

The TCP close communication message attribute (TCPPCNNMSG) specifies whether i5/OS should log abnormally closed TCP connection messages. Connection logging is stopped by setting that attribute to *NONE, which suppresses the message and keeps your message queue relatively uncluttered.

Save-While-Active Backups No Longer Completely Crash on Open Commitment or Rollback Operations

In OS/400 V5R1, a backup operation normally times-out and ends if another running job is holding an open commitment or rollback operation against a specific library while the backup job is performing a save-while-active Save Library command (SAVLIB) against that same library. This problem ruined many save-while-active procedures because OS/400 V5R1 would not let you save all your libraries if one library had an outstanding commitment or rollback operation on its databases. I documented this problem and how to recover from it a few years ago, but OS/400 V5R3 has done me one better in this case.

I discovered that, in V5R3, when a SAVLIB command fails during a save-while-active operation, the i5/OS will only cancel the save-while-active request for the library that has the commitment or rollback operation conflict; it won’t cancel the entire SAVLIB command for all the libraries that are being backed up. After ending the save-while-active backup for the library in question, the V5R3 SAVLIB command puts two informational error messages into the QSYSOPR message queue telling you about the problem. It will then continue backing up all the other libraries that are listed after the problem library in your SAVLIB command.

The downside of this enhancement is that you may need to watch the results of your backups more closely, because your SAVLIB statement will complete normally even when there has been a backup error on one or two libraries, and it’s fairly easy to miss commitment or rollback messages in QSYSOPR. But, all in all, this is a much better way to perform save-while-active backups than the previous all-or-nothing method in V5R1.

Not the End

This is by no means an exhaustive list of items to check after an OS/400 upgrade. If you’ve done your due diligence before an upgrade, these items provide a small flavor of what you may encounter after the upgrade. Fortunately, IBM provides an adequate road map in its Memorandums to Users manual that you can use to prepare for many of the changes you’ll run into.

Related Articles

“Admin Alert: Preparing for an OS/400 V5R1 to V5R3 Upgrade”

“Admin Alert: More on Preparing for OS/400 V5R1 to V5R3 Upgrades”