Tim Malone, MCSE†††††††††††††††† (818) 257-0513†††††††††††††† firstname.lastname@example.org
Upgrade from AM6000 to AM7000 at Condor†††† 23 Dec 2002
We started planning and preparing for this upgrade many months prior to the actual conversion.† I contacted several potential vendors and consultants and negotiated the deal.† We came up with several options Ė one was an exact replica of our existing equipment, another was a new AM6000 and the third was an upgrade to the AM7000, which is at least 25% faster than the AM6000.† Although our purpose was to put into place a backup for a system failure, it worked out that the best deal was to go with the upgrade.† We finished negotiations in earnest towards the end of November and placed the order the first part of December.
I spent the next few weeks working with Mark Goldberg, the programmer who wrote our custom MRP package, to identify and modify everything that needed to be changed to accommodate the new configuration.† The main difference was going from two small disk drives on the old system to one large 17GB drive on the new system.† We also decided that in order to use the old system as a backup, we would need to reconfigure it with the same disk and tape drives that we would be getting on the new system.† A little shopping on the internet got some good deals on a refurbished tape drive and a Ďlast-of-the-lineí disk drive.† After weeks of preparation, we were at last ready for the big day.
We tried to schedule the upgrade for Friday afternoon, the 20th of December, but too many users freaked at not having a system available for even a few hours.† We had to reschedule for the first day of the Christmas vacation.† We still got emails from users asking if it could be rescheduled.† That old Alpha Micro is the heart of the company.† People simply canít do their jobs without it, even when the plant is supposed to be closed for vacation.† We gave them until noon the day of the conversion and still had to delay a few minutes while someone ran a last-minute report.† I am amazed that we have gone for 20 years on the same system without some sort of backup other than tape.
The intention was to hook the two systems together through external SCSI cables but for some reason we kept getting copy errors.† We guessed it was some sort of SCSI termination problem but wasted an hour trying to figure it out.† So we decided to take the drives from the old system and hook them up to the new system.† Hereís a picture of Jeff Kreider starting to do the copy after we hooked the drives up. You canít see them because theyíre behind the new system.† Jeff was very careful about copying the system files because we were also upgrading to a newer release of the operating system at the same time.† Itís clear looking at the picture what an amazing change in technology has taken place over the years.† The old AM6000 is on the right.† The computer itself is not the whole cabinet.† It is the case in the middle with all the serial ports on the back.† We stopped using serial terminals and serial connections at least a year ago but the cables were still plugged in up until a week before the upgrade.† One of my tasks was to carefully remove the serial connections one by one to be sure that nothing stopped working.† Because Alpha Micro serial boards have a strange mind of their own, one of the remaining serial printers stopped working unless there was another serial cable plugged into a port on the same board to provide a complete ground loop.† We finally had to switch that serial printer over to a TCP connection.† Hereís a picture of the back of the old Alpha Micro before we disconnected all the serial ports and the multiplexer that routed them down to our plant in Mexico:
This is only half of the cables that used to be connected to it.† Up until last year we had another plant in Mexico and a second multiplexor with an equal number of serial connections.† We still have about 75 or 80 users between the corporate office and our plant in Mexicali.† However, they all use AlphaLAN and the TCP port to get to the system.† That was another reason for going to the AM7000 Ė to get 100mbs Ethernet.† Between the faster processor, the faster disk drive, and the faster Ethernet, we figure we will get at least a 25% increase in productivity, if not more.† Because we have such a customized system, Jeff had to take extra care to create our system disk just the way we needed it.† Since our software is so old it is not able to take advantage of larger hard drives in a more efficient way.† We use an old version of BASIC that can only recognize 32MB logical disks.† So instead of seeing one large disk or even partitioning into a few large disks, we had to configure our 17GB drive into 544 32MB logical drives.† What a waste!† But I guess thatís the price you pay for being locked into old custom software.† The version of BASIC is called dBASIC and the company that wrote it went out of business years ago.† Our system disk is almost full and we have removed all but the bare essentials.† dBASIC also replaces some of the AlphaBasic components that are part of AMOS, the Alpha Micro operating system.† So after an hour of careful tweaking, Jeff had the system up and running on the new drive.† Now it was time to copy all our programs and data files.† That took about an hour and a half.
Once the copy was completed, we unhooked the old drives from the old system and retired them from service.† We then took the new 17GB drive that I had purchased from CDW, hooked it up to the AM7000 and did a complete copy of the disk from the one to the other.† Another hour and a half went by.† We then took that second drive from the AM7000, put it in the AM6000 along with a new 4/8GB tape unit to match the AM7000 and fired it up.† A little tweaking and it was up and running.† It then got shut down, unplugged and wheeled into the corner, never to be used again.† Why would we go to all the trouble to put a brand new 17GB drive and a new 4/8GB tape unit in an old AM6000 computer that we would never use?† Backup, redundancy and fault-tolerance Ė something we should have had in place years ago.† If our new AM7000 fails, we just swap out the disk and put it in the old AM6000, make a few adjustments and weíre back in business.† If itís the disk itself that fails on the new system, we take the disk out of the AM6000, put it in the AM7000, do a restore from tape and weíre up again.† Of course, we lose the transactions made after the backup from the night before, but itís a lot better than having no replacement or backup system at all.
Hereís a picture of the new AM7000 in itís new home using a notebook computer as the TRM1 console.† Thereís really not much to see, is there?† Itís just a server and it looks just like any other computer.† However, it takes up less than 20% of the volume of the old AM6000. It produces at least 25% more throughput for our 80+ users.† Iíve tested it in production for the past few days since it was installed.† I have a nightly job that used to take three hours to run that now completes in 1 hour and forty minutes.† I would say we made the right decision in going with the AM7000.† We got both a backup solution and a major improvement in performance at the same time.† We are now in the process of installing and testing AlphaODBC, a new product that allows us to access the data files stored on Alpha Micro directly from a Windows-based computer.† If ODBC lives up to itís promise, there is no reason to retire the new AM7000, even if the operating system is 25 years old.† The entire upgrade took less than eight hours and was a complete success.† We are looking forward to the users coming back from vacation after the first of the year to see if anybody even notices the improvement in speed.
Tim Malone, MCSE
Information Systems Manager
Condor DC Power Supplies
Oxnard, CA (Now SL Power in Ventura)