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