63 kB PostScript reprint
C. Clayton
Rutherford Appleton Lab., Chilton, Didcot, Oxon OX11 0QX, U.K.
In order to exploit the most cost-effective hardware and to maintain compatibility with the international community, Starlink is migrating from an entirely VAX/VMS based service to UNIX-based systems. This migration is almost complete, and this paper describes some of the solutions adopted for the wide variety of problems which were encountered.
Migration of the hardware platform is discussed first. Equipment which can be re-used under Unix is identified. System software and non-astronomical applications which are required to allow a smooth transition from VMS to Unix are considered next. While many VMS functions can be replaced with Unix equivalents, it has become apparent that there is a small number of key VMS applications which must be provided on the replacement Unix platform to avoid considerable disruption to users.
Various strategies for moving the users themselves from VMS to UNIX are considered and their relative merits compared. Fast migration routes are considered to be more effective as long as certain key applications and user aids are already in place. The porting of the Starlink Software Collection is discussed, as is the problem of migrating large quantities of private user code.
In order to exploit the most cost-effective hardware and to maintain compatibility with the international community, the formerly VMS-only Starlink Project has switched to using Unix-based computers. A mixed Unix/VMS service, with its extra system management and software support costs, cannot be afforded and at present the existing VMS service is being run down.
A complete change to Unix will have occurred by April 1995. A central fall-back VMS service will, however, be retained for emergencies (for example, for applications where source code is not available). Starlink is currently operating DEC Alpha and Sun SPARC CPUs.
The first Sun was installed at a Starlink site in March 1990 and hence the total elapsed migration time has been 5 years. However, the majority of the hardware purchasing has taken place in the last 3 years. During this period, we have had to run VMS and Unix in parallel. The VAXes at a given site have then been switched off when virtually all of the software which is used at that site has been ported to Unix and when there is sufficient Unix hardware at that site to support the resident user community.
Unfortunately, it has been necessary to divert funds from software effort in order to complete the move so swiftly. A high rate of change was deemed more cost effective; savings are then possible in the areas of maintenance (we can switch off older, expensive-to-maintain equipment earlier) and system management (less manpower required if the VMS and Unix systems are run in parallel for a shorter time).
We have attempted to re-use hardware from our VMS system where it is both technically possible and cost-effective. Such equipment includes 1/2'' tape drives, exabytes, CD-ROMs, SCSI hard disks, printers, and networking kit. Equipment which could not be moved cost effectively included VAX CPUs, non-SCSI disks, Honeywell image display cameras, and DEC LAT-only terminal servers. Further details are available from the author.
One of the most vital aspects of the migration was the provision of migration aids for users. These took the form of VMS-equivalent software for Unix and friendlier versions of certain ``user-hostile'' Unix utilities which come bundled with the operating system.
Due to budgetary limitations, we cannot afford formal Unix training for all of our users. Instead we have adopted a strategy of sending system managers on Unix management courses, encouraging system managers and other local experts to give Unix seminars to local users, and encouraging users to attend other local Unix courses (e.g., ones held for new undergraduates at university computing centers). We also provide copies of the book Unix for VMS users, make WWW Unix guides readily available from our home pages, and encourage users to help each other. In order to transfer our large (1800) user population, we adopted the following broad strategies: (1) new users are given accounts on Unix machines only; (2) exciting new software is only made available on the Unix machines (this included Mosaic and Usenet news as well as new astronomical software products); (3) the VMS systems were made to look unattractive by a variety of methods, including transferring useful peripherals to the Unix systems (e.g. printers) and reducing the level of support available to VMS users; and finally, (4) switching off the VAXes.
It was found that users who ventured onto Unix, but returned to VAX/VMS whenever they encountered a problem, never made the transition to Unix until their VAXes were actually switched off. Those users who did not look back, and overcame each problem as it arose, typically completed the transition in about three weeks. Those users who returned to the VMS service temporarily seemed to forget most of what they had learned while on the Unix machines and hence each attempt to migrate was a painful as the previous. However, those who immersed themselves consolidated what they had learned, and very rapidly became proficient under Unix.
The Starlink Software Collection is based on a software environment (called ADAM) supported by a team of professional programmers, and hence the problem of porting to Unix was tractable. The software which was VAX-specific has been made portable, and it now runs on a number of flavors of Unix (SunOS 4.x, Solaris 2.x, Ultrix 4.x and OSF/1) as well as VMS. Ports to other Unix implementations are expected.
Users were given several years warning of the switch to Unix and were instructed to ensure that they ported their private code themselves. Unix porting advice has been available to users encountering difficulties. Much of the code has been standard FORTRAN 77 and has been moved to Unix with relative ease.
The change to Unix gave us the opportunity to kill off certain hard-to-maintain packages, which were originally poorly written, on the grounds that they were too difficult to port. These have been replaced with better engineered products. However, use of certain packages in this category were too entrenched and we were forced to port these despite the difficulty of the task.
This is now done via anonymous ftp. For further details contact the Starlink Software Librarian ( ussc@star.rl.ac.uk).
63 kB PostScript reprint