Previous Table of Contents Next


Any lists created on the production server needed to be printed out and rebuilt by hand before the target server was brought online. The list itself was added to the server before the data files were restored and converted. Names could be added to the list only after the server was brought online.

The Group Moves. The only activities that could not be done before Friday afternoon were the group moves, and the transfer of the E-mail, data files and updates to the Adminlist for the target server.

Promptly at 5:00 PM on Friday, the groups were moved from the production server to tape and then restored to the target server. The group moves were done before the file services, because in the process of the file conversion, the ARL were updated to the new Vines 5.52(5). The file services (i.e., the actual data) were backed up to tape and then restored to the target server. ARLs and the group and user IDs were matched. If the groups with their users had not been there before moving the files, it would have been necessary to go back in and edit the ARLs on the target server.

Moving E-mail and STDA. The E-mail service was moved from the production server to the target server via tape backup. This process was straightforward and reliable.

The STDA was recreated on the target server, once the target server was moved to production status and cabled to the WAN and the old server was removed. Again, the proper sequence was removed and the new target server moved into place. The STDA service could not be moved with reliable results, so Banyan recommended that it be recreated; however, it could not be created before the server was placed on the WAN. The target server needed the connection to the WAN so it could rebuild the internal SIDA database from upstream neighbors. The creation and forced rebuild on Friday night gave three days for the rebuild process to operate before Monday morning. Sometimes, though, three days is not enough time for STDA to rebuild properly, and the data base had to be killed and recreated before it would work properly.

Moving the ARLs. The ARLs were one of the last major areas left to update once the target server became the production server. The administrators were usually part of another group that were kept on a different server. Sometimes the Adminlist could not be updated with the names of administrators until the new production server could “see” the target server. At those times, two different methods to force the update process on the new production server were used. A dummy group was created on the new server, which forced a Detail broadcast to the WAN that updated all the surrounding servers, and, as a result, the entire WAN began to “see” the new server. When the server could “see” and “be seen,” the dummy group was deleted.

The other method was to use a Banyan utility that would “goose” Streettalk and force the surrounding servers to exchange routing information and update their respective routing tables. The STSYNC utility is effective in getting servers to synchronize with each other.

The last upgrade detail was updating the boot disks for the users. This process typically required that someone physically visit each workstation that was physically attached to the upgraded server and run the NEW REV PROGRAM, which copied down the new boot files to the workstation. This process was quickly automated by the staff members so when a user of a group that resided on a newly upgrades server logged in, a batch file ran that copied the necessary files to their workstation and then required them to reboot. This process saved an enormous amount of time.

Because entire groups with the associated users were being moved, no password changes for the end users were required. This helped make the conversion more transparent to the end user.

Some Glitches

Final issues for the conversion were to double-check the ARL of the root in each file service, as they did not convert reliably and had to be modified by hand. Oddly enough, the remaining ARLs in the rest of the directory tree were usually correct and did not need modifying. Some tailoring of the ARLs did occur after the fact, so as to comply with the new RTC standards that were published before the upgrade was started.

One ARL problem encountered was with lists on the server that were used in the ARLs of files and directories. If the ARLs were being changed or updated with the Banyan Vines utility Netpro, the workstation would receive an out of memory error and terminate. The reason for this was that Netpro could not update ARLs with a list that was not there, so it buffered the transaction and went on to the next ARL update, and so on, until the workstation ran out of memory. The lesson learned here was to make sure that all lists were at least placed on the server, empty or not, so the ARL conversion would operate properly.

In the particular upgrade scenario for the site, two and sometimes three server conversions a week could proceed with the equipment on hand. As servers were replaced with new production servers running Vines 5.52(5), the 4.11(5) servers coming off line became the new target machines in the upgrade process for the following week. The assorted 20 Banyan servers took 10 weeks to convert from Vines 4.11(5) to Vines 5.52(5). All staff members worked in teams that rotated each week, so no network administrator was needed for consecutive weekend work, and no mental “burn out” that would have resulted from such a demanding schedule occurred.

As in all well- thought- out plans, there is always an overlooked X variable that comes back to foil complete upgrade success. As all sites reached the final stages of the server upgrade process, a problem surfaced that no one had anticipated: Paradox 3.5 would not support over 25 concurrent users on a Banyan Vines 5.52(5) platform.

Lab applications testing did not explore the Paradox application to this extent. Both Banyan and Borland were contacted about fixes or workarounds. Banyan declined to assist RTC in this problem, saying it was an application problem. After many phone conversations with Borland, their technicians did concede that it was a problem with Paradox 3.5. But because Borland was no longer supporting that product version, the technicians suggested that RTC upgrade to Paradox 4.0 to solve the problem.


Previous Table of Contents Next

Copyright © CRC Press LLC