CISC to RISC - It's SLIC

fter having just spent the long Easter weekend going through the CISC to RISC migration, I feel IBM really deserves a round of applause - it truly is SLIC. It wasn't without its own set of Goths though so I thought I would write this article to tell you about our experiences, here at E.D. Smith. I have been planning this upgrade for two years, ever since the RISC box became more than just a whisper. Our lease expired December 31, 1995 and I had thought I would be well positioned to take advantage of the new technology. When the actual expiration came though, we were several months too early for general availability. Undaunted, I negotiated a RISC box - a 510 model 2043, that was a quick progression through the model 310 - a lateral move from our then F50.

As soon as our delivery date of March 15^th was confirmed I couldn't wait to get things going. We downloaded and applied the necessary V3R1 PTFs that would allow us to run the upgrade prep. We attended the migration planning course offered by IBM education (I strongly recommend that anyone considering an upgrade take this course.) Armed with all this information and the rather daunting-looking AS/400 Roadmap, we began the necessary preparations.

UPGRADE PREPERATION

The first task is to run the upgrade prep. This provides a list of the unsupported objects on your system - any programs with observability removed or any programs that have been created with a compiler that is no longer supported under V3R6. If you are a user of QUSRTOOL, almost all of those programs will show up. The list also indicates which source file the program came from and whether or not the source is available on the system. If you are a fan of QUSRTOOL you will be aware that support for this product is no longer with IBM starting on V3R6. It is supported, and new enhancements will be available from Jim Sloan, Inc. In our environment, all of the source existed and the tools could be recreated. Some of our packaged software showed the unsupported compiler message, but as the programs were all observable, they were migrated cleanly. One gotcha occurred when one of our packages was in a library beginning with Q and the upgrade prep did not indicate a potential problem. This did not show up until the library was accessed after the conversion and the user received the message that the object would not convert.

The estimated storage requirements section of the report analyses your current disk configuration and predicts the storage required under the Power PC architecture. Our environment indicated that OS/400 would grow by 966 Meg, licensed programs would grow by 247 Meg and our objects would grow by 543 Meg. The upgrade prep job then goes on to predict the length of time the disk prep job would run. In our case it predicted over 500 minutes but the actual job required less than half that time.

We contacted all of our software suppliers where program observability had been removed and got new observable versions. Most of the vendors were very interested in the conversion as they had not tested their software on RISC boxes yet. We recompiled any objects we could internally until the list showed only a couple of problems - a couple of IBM objects in QGPL and a few programs that had not been used in years that we could get rid of.

DISK PREPERATION

After a RCLDLO and a RCLSTG we were ready to run disk prep! This job converts all the object indexes to the new page size. This job works very nicely allowing you to select in advance the length of time you want the job to run for and the day and time you want it to run. It also lets you select an automatic IPL after the job is completed. Again, I have to admit I was very anxious to get moving on this conversion so I did the disk prep very early in the process. That was a mistake. We were close to the limit of what the 310 could do for us, so this extra strain slowed the performance considerably.

When I ordered the upgrade, I planned it as a staged upgrade - replace the release. Remember, I had just moved to the 310 at Christmas, so I had also ordered part of the disk to be delivered with the 510. With the addition of a workstation controller and a tape I/O card, that gave us a useable system that we could run beside the 310 to help us prepare for the migration. We were able to migrate all of our user libraries prior to the conversion. This knocked about 12-14 hrs off the conversion weekend. At this time we also converted our development box - the 20S to a 40S. In that case we did a full unload reload and we were up and running on V3R6 on that machine several weeks before the production system was migrated. All of our planning seemed to indicate a 3 day conversion so, of course, it was scheduled for the Easter weekend.

FINALLY, the long awaited weekend was here!

HARDWARE MIGRATION

We began the necessary backups at about 2:00 a.m. on Friday morning. This took about 4 hrs. Thinking we would save some time we did a DUPTAP to make a second copy. We have a 9427 8 mm tape library system which is really fast but the DUPTAP was a very slow procedure. The one benefit to running this is that the system was still available. Once backups were completed it was necessary to run the RCLSTG. We turned the machine over to IBM at 11:18. From 11:18 to 12:53 they ran the necessary procedures to prep the system and disks for the move. (It was kind of scary to see the disk drives sitting out on a desk in order, and knowing that one false move and it was reload time!) Then they moved the hardware from the old frame to the new frame. This was the first customer migration they had done and they were super. A special thanks to Denny and Harold. At 2:35 we brought up hardware service manager on the new box. Follow the instructions on the screen carefully - do not push F3 or F12 from the main screen or you will be looking at a full reload. At 3:05 we exited from hardware then began the load source upgrade. Mirroring was resuming - the system waits until mirroring is resumed then performs the load source upgrade. The load source disks from the 310 and the new disks all appear as non-configured. IBM are finished - it was now up to us. From 4:00 to 6:00 the machine was in storage management recovery, from 6:00 to 6:35 authority recovery, then the operating system was started at 6:40. At 6:45 the screen to install the operating system came up. The PowerPC AS now has an internal CD-ROM so this was accomplished in record time. At 7:25 we had a signon screen!

It was then time to sort out the device descriptions and to perform the hardware resource mapping. This was completed at about 8:00 p.m. The previously converted applications were restored from tape. This was complete by 10:00. Next convert QGPL and QUSRSYS. At 10:05 I began installing the licensed programs. In order to save time we had installed the latest cum on the staged upgrade box prior to migration and had done a SAVLICPGM (This procedure took about 6 hours!). At this point the book said we could use this tape to install the licensed programs from. I tried and tried but it would not install this way - it kept telling me that it couldn't find QGPL or QUSRSYS on the tape. I just got mad at it and started the install license programs off of the CD. Once that was well underway I left for the evening - around 11:30.

DAY TWO

Day Two - Jeff was in bright and early and applied the cum. Now it was time to tackle those non-configured disks. This had to be done in 2 steps. First, the old load source drives that were mirrored had to be added into the set. This was a fairly lengthy process and required an IPL to complete. Once these disks were added it was then time to add the new DASD. Again, a fairly lengthy process with another IPL required. Then it was fire her up! Up she came! A final STROBJCVN to make sure all of the objects were converted and it was ready to use. We went around to all of the PCs and made sure that they were all operational and that everything was successfully downloaded via Client Access. That had been the biggest problem when we had converted to V3R1 but with V3R6 it was no problem whatsoever! Next one last save of the entire system just in case and it was ready to begin its new job. It was fully up and running by 9:00 PM. on Saturday.

On Monday morning it was work as usual. The conversion really had been seamless to the user community. They were just thrilled with the improved performance that the new machine delivers.

All in all a very successful migration. A special thanks to the E.D. Smith I/S team. T < G

Bev Russell is the TUG Vice President in charge of speakers. She can be reached at E.D. Smith, in Winona, Ontario (905) 643-1211 x372.