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.
This time, all the "managers" were promoted to "associate directors" though this did not happen immediately.
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!
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.
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.