mark (09/14/82)
For those of you wondering what happened to ucbvax: Recently, Berkeley decided that their 780 known externally as ucbvax or csvax and internally as Ernie CoVax was burning too many cycles on uucp. They dedicated a 750 to processing mail and named that 750 ucbvax. The 780 is now known as ucbernie. Berkeley put all their mail and news functions on this one 750, both internally and externally. ucbvax talks over berknet, ethernet, and uucp links to other Berkeley machines and the outside world. (Their arpanet link is still a C/70, since that machine speaks NCP.) They rigged up a special shell on Ernie so that logging in as uucp on Ernie would remotely run uucico on ucbvax. Thus, uucp was moved to ucbvax without anyone noticing. (At least, that was the idea.) Eventually people would call ucbvax and the load on ucbernie would go down. As soon as the heavy load hit, so did problems. The 750 was running with rk07's as its only disks. Microcode bugs that only show up under heavy unibus load (from the ethernet) appeared. The machine kept crashing. Mail and news piled up on every other machine trying to get through to ucbvax. People at Berkeley couldn't even send each other mail since it all went through ucbvax. This period lasted about 2 weeks. Eventually they got fixes for the microcode problems (I think) and put a Winchester disk on in place of the rk07's. Now the machine stays up, but their /usr/spool/uucp is huge (50K bytes) and we all know what happens when that directory gets huge. Systems would call up and time out waiting for a response to some intermediate request. This left LCK files there, so the next time the same system called, it got RLCK'ed out. Still no uucp mail got through. Now they appear to be hand-feeding the system. It's possible to talk to it if your uucp is patient. (We've increased our timeout parameters to 3*45 seconds waiting for ROK and 20 alarms in a row, and it appears to have helped.) Some mail gets through and some doesn't. But the machine does stay up. Mark