Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!ukma!nrl-cmf!ames!ucbcad!ucbvax!rtpark.rtp.ge.COM!rlb From: rlb@rtpark.rtp.ge.COM (Bob Boyd 8*565-3627 30-Nov-1987 0949) Newsgroups: comp.os.vms Subject: (none) Message-ID: <8711301451.AA04865@ge-rtp.GE.COM> Date: Mon, 30-Nov-87 09:51:49 EST Article-I.D.: ge-rtp.8711301451.AA04865 Posted: Mon Nov 30 09:51:49 1987 Date-Received: Fri, 4-Dec-87 03:12:49 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 86 Subj: Printer Symbiont, alias file entries, backlink pointers, etc. Keywords: VERIFY, backlink, ANALYZE/DISK, file-id Peter Marshall writes: >Subj: Logical Names & CMU-TEK IP print spooler > >We are running a VAX cluster. We run a cluster wide print queue that uses >the CMU-TEK IP package to ship the print files to a Ultrix lpd deamon that >feeds a laser printer. > >Normally files put into the queue arrive properly at the other end. >Everything works just fine. If I try to send a file like >SYS$HELP:FINGER.HELP then the CMU symbiont fails complaining that it >can't find the file. The file that it is looking for is >_HSC001$DUA0:[SYSCOMMON.SYSHLP]FINGER.HELP and if you try to type that >file, sure enough the directory is bad. It should be something like >_HSC001$DUA0:[SYS0.SYSCOMMON.SYSHLP]FINGER.HELP (i.e. SYSCOMMON is not >a top level directory). When I print the same file to the standard >SYS$PRINT queue it "says" that it is printing the file named by the >illegal directory specification (on the header page), but it actually >finds the right file. > >... and more >Peter Marshall, Data Comm. Manager >London, Canada N6A 5B7 (519)661-2151x6032 >pm@uwovax.BITNET; pm@uwovax.uwo.cdn; Peter.Marshall@uwo.cdn >peter@julian.uucp; ...!watmath!julian!peter This would appear to be related to a problem that I discovered some time ago with directory back-link pointers. The problem is created by using ANALYZE/DISK/REPAIR on your system disk. There are the following top-level directories: [sys0] [sys1] ... [sysn] and [v4common] The interesting part is when each [SYSx] root is created the following gets done: SET FILE/ENTER=[SYSx]syscommon.dir SYS$SYSDEVICE:[000000]v4common.dir This creates a pointer so that [V4COMMON] appears as a subdirectory of every root. When the symbiont gets a file to print from the Job Controller, it is passed by file-id. This means that the symbiont has to "generate" the file name by "discovery". This works fine as long as all the back-link pointers are properly maintained. If however, someone has run ANALYZE/DISK/REPAIR on the system disk, the current (and all previous) version will attempt to "repair" the backlinks by re-arranging them. This causes no problem for ordinary access. Translation from file name to file id works ok-mighty-fine. However, walking the backlinks up the tree doesn't go so cleanly. In fact, I submitted an SPR about a year ago that finally got published in the DISPATCH in this November's issue. Please take a look at the problem described there if you can get a copy of it. The fix (my guess, no commitment from DEC) -- probably V5 or V5.2. The workaround: 1. Use ANALYZE/DISK/REPAIR/CONFIRM to re-twiddle your backlink pointers 1(ONLY 1) time. 2. Forever more until VMS fixes the way they handle these, never,never, never let ANAL/DISK/REPAIR/CONF do ANYTHING to "repair" backlink pointers. ALWAYS say "N" to any question to do with backlinks. Also, never, never, NEVER use ANALYZE/DISK/REPAIR/NOCONFIRM on the system disk. (or any disk that has alias directory entries set up on it) ----------------------------------------------------------------- Bob Boyd Usenet: rlb@rtpark.rtp.ge.com GE Microelectronics Ctr. Voice: (919)549-3627 POB 13049, MS 7T3-01 GE DIALCOMM: 8*565-3627 RTP, NC 27709-3049 GE DECnet: RTPARK::RLB