The VMS Era

The VMS era will be considered to begin when UW purchased a pair of VAX 8800s in late 1987. However, in a sense it began several years before in 1984, when a VAX 11/785 was purchased with funds from Computer Services and the Computer Science department. Curiously, it daily alternated operation between VMS and Ultrix. Also, at around the same time that the Cybers arrived, the Geology department obtained a Vax 11/785 to process seismic data using a package called Disco. This system could read the indefinite-length tapes made by their field-recording systems, had an attached floating-point array processor, and a hardware rasterizer and electrostatic plotter. The Engineering college also dabbled in VAXes. However, this is the history of central computing, so not much more will be said about these.

It was strongly rumored that though Computer Services and Computer Science kicked in equal amounts of money to buy the 11/785, the latter chose to apply all of the educational discount against their half of the funding rather than sharing the discount.

At Computer Services, the VMS era began in earnest when it was decided to replace the Cybers with the largest available VAX systems of the day, the dual-CPU VAX 8800. Two of these systems were purchased, along with appropriate peripherals, to be run as a VAXcluster (now called a VMScluster since the Alpha systems were released in 1993). The systems were initially set up in the paper store room for development, shake-down, and familiarization. Over the Christmas break, the Cyber 760 was removed and the cluster was installed in its place in the machine room, and released to the users in January of 1988.

This time, all the "managers" were promoted to "associate directors" though this did not happen immediately.

The Cyber 840 was scheduled to be removed at the end of 1988, but some last-minute data processing issues extended this to January 31, 1989.

As we had done with the Sigma-to-Cyber transition, utilities were written to allow VMS to read many of the proprietary NOS data formats on tape, and to allow file transfers from the old system to the new.

While most people naturally called the VAXcluster a replacement for the two Cybers, I did not. We gained quite a bit, but overall computing horsepower went way down compared to the old CDC mainframes. An especially important aspect of multi-CPU systems that gets lost on most people is that in most cases, the fastest that *you* can complete *your* job is dependent on the speed of a single CPU. Adding them all together does yield an important figure, namely the aggregate or total speed, but this doesn't necessarily impress the single user. Also remember that the Cybers used 60 bits in single precision, 120 in double precision; VAXes use 32 bits by default, so a meaningful comparison might mean using double precision on the VAX against single precision on a Cyber. With all this taken into account, the Cyber 760 alone was about as fast as the two 8800 systems combined. For some time I would sign e-mail with "I used to work on mainframes but now we have VAXes instead."

When we got the VAXcluster, we were concerned about the manpower needed to convert SUPER. Instead we wrote NEWUSER, a method whereby people could get their own usernames set up. The hierarchical approach was abandoned, partly because we had found that users tended to be members of multiple hierarchies (e.g. a part-time student with a dual appointment to two departments, or a student with dual major, or a student with no major, or employees that moved from one department to another). So we started considering people to be simply people. However, in a move that only later was clearly a mistake, students were considered different than employees, and employees were given UICs that were grouped by University unit (often improperly called departments). Writing NEWUSER was a signigicant task, but the benefits have been worthwhile. After many years the departmentalization of employees was abandoned, and students finally got the same resources as employees, making the distinction useless.

Mark Walker tells me that in the early days of VMS, one of the compilers absolutely required that the source file be organized as variable-length records, of exactly 80 characters each!

After running CDC's NOS for many years we became almost addicted to their concept of "local files" (explained earlier). We felt it was desirable on VMS to restrict users via disk quotas, but the VMS enforcement prevented users from using large amounts of disk space on a temporary basis. We looked at several alternatives for temporary space but most relied on the users to clean up after themselves. A design was implemented that has many of the same characteristics as local files. A disk was set aside as the "temporary" disk; for each login, a directory is created for the process and a logical TMP: defined to point at it. This disk has no quotas. When a user logs off, a background process detects this and deletes all the files (unless some are queued for printing). Thus our VMS system has a very nice feature we "borrowed" from CDC. Believe me, it is nice. Only a few times have we had users go crazy and run the whole disk out of space.

On NOS, we had one username per person/task, meaning a person had a separate username for each class or job. On VMS we decided on one username per person but still wanted to track usage by task. So we went with a product called ARSAP from a company called GEJAC, to implement "project accounting." A student would get a project created for every class being taken, and users could have a project created for any purpose. However, the user was expected to enter a SWITCH command whenever he/she started working on something. If a student logged in and wanted to work on COSCI 301F, then he/she was supposed to enter a SWITCH command to say so. If the student got tired of that and wanted to work on HOMEC 440D, then enter another SWITCH command so usage gets charged against the proper project. Well, hardly anybody ever used the command at all, so project accounting was a complete bust and waste of significant effort (we had to create a project for every class every semester, add/drop students to projects as they added/dropped classes, kill the projects each semester, and so on). With great relief we finally gave up and de-installed ARSAP.

One of the reasons for the desire to track usage relates to grants. Many grants included clauses like "up to $10,000 for computer usage" and we really wanted to get our money out of these grants. We never have, because we couldn't accurately bill for the usage as it specifically related to grant work. We still can't but this is largely due to refusal by the users to let us know when they're doing grant-related computing.

Another problem in any case was that ARSAP was very slow. Some users at other sites joked about how it took over 24 hours for ARSAP to process a day's worth of accounting logs. Plus it cost us money, and since we were not charging users real money (except the half-dozen commercial users), nothing was being gained. There is simply no point in micro-managing a computing resource that doesn't need it.

A cute problem with GEJAC is that they kept releasing new versions of ARSAP, and using the same version number. I think we got at least five tapes all labeled version 6.0 and we'd joke about upgrading 6.0 up to 6.0. WordPerfect loves to do this also, and I had a similar experience with the VMS version of Lynx and Digital's Polycenter Scheduler 2.1B.

When we first got the VAX 8800s, they came with ethernet adaptors called DEBNAs. It turned out these could not run at the full 10 megabits per second for very long. After a few years, somebody with a high-end PC that *could* run at full speed attempted to ftp a file to one of the 8800s and consistently hung it. This was embarrassing: a PC had a faster ethernet card, and took down our mainframe. We quickly upgraded the DEBNAs to DEBNIs!

The 8800s were purchased with four TA79 tape drives (actually, one TA79 master and three TU78 slave units), the very best 9-track autoloading tape drives Digital offered. Experience showed they were very unreliable, especially in terms of loading a tape. The operators finally gave up, and always took off the autoloading band to manually load tapes. In early 1990, three of these drives were traded in for a pair of TA90 cartridge drives, which basically pleased everybody. The TA90 was actually an IBM 3480 with a few changes made by Digital for interface differences, and an improved maintenance panel. Oddly, these drives came with the optional auto-loader which is nearly useless with VMS. Later we acquired four IBM drives for the administrative system, without autoloaders which would have been of great use. By 1994 the IBM drives were replaced with older units that came with autoloaders and data compression (IDRC).

In late 1989, the Computer Services Division was re-organized and became the Division of Information Technology. At the same time, the position of Director became Special Assistant to the President for Information Technology.

Around 1988 we got a "free" version of the Oracle database system, with the restriction that it be used only for educational purposes, not for administrative use. Either due to problems with Oracle, or because we wanted to use it for more than teaching (or both), we eventually switched to CA/DB. A short time later we joined the educational licensing program from Digital which meant we could use Rdb for free, a definite attraction to the bean counters. So we dumped CA/DB and installed Rdb, much to the chagrin of users still acclimating to CA/DB from Oracle. Now, Digital has sold Rdb to Oracle, who won't give it to educational sites for free, meaning we have come full circle and gotten screwed in the process.

By 1991 it was realized that the VAXcluster was not keeping up with demand, and that a replacement was needed. A Digital 7000 Alpha (model 7620) was acquired with 2 182-mHz CPUs, 256 megabytes of memory, and 27 1-gigabyte disk drives. The TA90 and TA79 tape drives were retained from the 8800s, as well as the line printers. This system arrived in July 1992 and was put in production at the end of August for the Fall semester.

When this system was specified by a co-worker and myself, we stated a need for 512 meg of memory and two CPUs. We were told that we could have either but not both, so we picked the CPUs. Within 6 months it was shown that the system needed more memory, but again to save money, only a 128-meg board was purchased (Digital and the 3rd-party reseller assured us this would work: having a mixture of one 256-meg card and one 128-meg card). When the memory arrived, it would not work, and we discovered that both vendors lied to us, and a 7000 of that vintage would not support such a mixture. We could not return the new card for a 256 meg, so had to purchase a second 128 meg, at a total cost above what it would have cost to buy the 256 meg card in the first place. To top this all off, an alternative would have been to buy new CPU cards that did support mixed memory but that was *way* more costly. A few months after we got the second 128 meg card, Digital turned the CPU upgrade into an FCO which meant we got new 200-mHz CPUs for "free" that would have supported the mixed memory configuration.

It is also important to point out the upgrade from 8800s to a 7620 was basically paid for by the savings on the service contract. As a side-effect, or at least a contributing factor, Digital got rid of the long-time Laramie resident engineer for lack of work/revenue. Our service now comes out of Cheyenne.

Next: Long-term perspectives, gripes, and soap-boxing