From: CSBVAX::MRGATE!ge-rtp!rtpark.RTP.GE.COM!rlb@mcnc.org@SMTP 30-NOV-1987 13:59 To: ARISIA::EVERHART Subj: No Subject Received: from seismo.CSS.GOV by KL.SRI.COM with TCP; Mon 30 Nov 87 08:49:42-PST Received: from mcnc.mcnc.org by seismo.CSS.GOV (5.54/1.14) id AA00168; Mon, 30 Nov 87 10:51:30 EST Received: by mcnc.mcnc.org (5.54/MCNC/10-20-87) id AA18699; Mon, 30 Nov 87 10:51:12 EST Received: by ge-rtp.GE.COM (4.12/UUCP-Project/1.0/ge-rtp.GE.COM/1.7) id AA04865; Mon, 30 Nov 87 09:51:49 est Date: Mon, 30 Nov 87 09:51:49 est Message-Id: <8711301451.AA04865@ge-rtp.GE.COM> From: rlb@rtpark.rtp.ge.com (Bob Boyd 8*565-3627 30-Nov-1987 0949) To: info_vax@mcnc.org 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