libes@nbs-amrf.UUCP (Don Libes) (09/12/85)
I just brought up 4.1, called for the update tape and then put that up. I gather that everyone else has done this along with concluding that there are a surprising number of buggy things in this release. Fortunately, we have the source (cmds and libs, only), otherwise we'd be in deep trouble by now. TWG offers utterly useless support. Enough haranguing. Some of the more notable things I've ran into are: cvtfnames has several bugs, none of which I fixed since it was a one-time shot. However TWG gave us no help with this. 1) Encountering empty HSN files, confuses it, because it doesn't close a FAB after giving up. Fix or delete them yourself. 2) Make sure you have sufficient quota. I ran it with the -f (ignore errors) at first, and found that all the HSN files had been deleted, but nothing else had been done. Great, a directory of nameless files. 3) I never realized it, but the hashing code is in the applications programs, not open() or creat(), because of this, old programs that haven't been recompiled can produce HSH files. cvtfnames will fail trying to rename the HSH file, because a file by the same name already exists. It says this in its own polite way - by giving an obscure error message that says "Invalid File ID". Wonderful. In case you missed it, let me repeat - recompile all your local programs, even if they (seem to) run fine. ucbmail. ucbmail works just fine if you uninstall it. I haven't the faintest idea what got into TWG on this. unixld does not support the -notrace option for installing programs with privs. Run trpatch(1) on them afterwards. There seem to be problems with dots in directory names. I.e. % mkdir D. % cat D. cat: cannot open D. % rmdir D. rmdir: cannot find D. (or something like that...) Yes, you've seen that directory before....uucp! I ended up simply removing the dots from the directory names in the uucp code. (The corresponding functions in uucp are all in subdir.c) Which brings me to uucp. TWG says it doesn't work but they are working on it (thats what they've been saying for several years now). We run GE's port of the 4.2 uucp. Oh, and we run it all unpriv'd. None of its installed. Install is like a brick wall that I keep banging my head into. Who can tell me why I can install the same image under two different names. (i.e. dra0:[eunice.bin]kludge and bin:kludge) Every include file that I have had to look at in /usr/include/vms is version 3, not version 4. It was no surprise then that things that dig through VMS structures (such as finger, w, ps) didn't work so hot. Oh, finger needs to be installed with some heavy priv to prevent this "stat" error msg. It certainly works a lot better with bypass; when I get a second I'll figure out what it really wants. One of our hackers here (klm) figured out that spawning a csh allows you to suspend out to the old DCL environment, not a new one. This was really nice, because we could do a "pushu root" (push uic on stack) and then spawn a new csh with privs. Then you could bop back and forth between your normal csh, the su csh and DCL, just using the commands: suspend (in csh), pushu and fg (in DCL). Very clean. Unfortunately, doing this in V4 doesn't work. A second shell can be invoked with a different uic, but it bombs out when suspended. Try: $ csh :== spawn/nolog @etc:csh $ csh ! start up a normal csh % suspend ; # go back to DCL $ pushu root ; set uic [1,4] $ csh ! start up an su'd csh % suspend ; # go back to DCL ......uncaught signal..... (followed by ugly stack dump) Any ideas what the problem is? Well thats all the bugs I can think of at the moment. More to come... Don Libes seismo!nbs-amrf!libes