Tim Malone, MCSE (818) 257-0513 tim@3tcm.net
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)
This
is part of the online resume for Tim Malone, MCSE and can be reached at http://www.3tcm.net or https://3tcm.com