Conference vaxaxp::vmsnotes

re .0
    
>User Action:  Do a SET FILE/NODIRECTORY on the directory file in which the
>files are located; then delete the directory file. Last, run
>ANALYZE/DISK/REPAIR to rename all the files from the bad directory into the
>SYSLOST.DIR;1 directory.
    
    Ouch. Good pick up.
    
    I think you should QAR this to ensure it receives adequate attention.

  Hold on a minute. Do you want the help text to list *all* the exceptions?

  The stated user action is correct for 99.9999% of cases. Yes, there are a
  few situations under which following that advice might cause some grief,
  but is it really worth filling up HELP/MESSAGE with complicated and
  potentially confusing information? My only criticism of the text is that
  it leaves out the final step (RENAME SYSLOST.DIR back to where it came
  from). If you really think it's that dangerous, the text should simply
  be replaced with "log a call with your local CSC". If you make the text
  sound dangerous, that's what people will do anyway, but it's a rather 
  expensive way to deal with the majority of simple instances.

>    In the meantime, this is VAX OpenVMS 7.1 and I'd love to know what
>    caused it. (I fixed it with judicious rename/copying.)

  There were some F11XQP bugs which could result in the use of MOVEFILE (by
  defraggers) munging directory order in clusters:

"Problems Addressed in the VAXF11X02_061 Kit for OpenVMS VAX V6.1:

  o  As of OpenVMS VAX V6.0, movement of directory files is allowed
     as long as no node in the cluster has data from these files
     cached.

     The cluster-wide check for this condition does not work
     properly.  This results in cache incoherency and, as a result,
     directory file corruption.  Common symptoms of this problem are:

       +  out-of-order directory listings
       +  duplicate directory entries for the same file
       +  "lost" files
       +  inconsistent directory listings on different nodes
       +  files appearing in directory listings which are
          not "accessible" from the RMS level (i.e., they
          cannot be "typed" out).
"

  Latest version of this patch is VAXF11X03_070, but I'd have thought this
  problem was fixed long before V7.1. Could they have been there for a long
  time?

						John Gillings, Sydney CSC

    John
    
    	I'll take your points in reverse order. 
    
    Since the system is standalone and I don't run a defrag, then I don't
    believe the problem comes from those sources. The upgradde from 6.2 to
    7.1 went without a hitch 10 days ago. The system disk had an analysis
    performed about a week ago.
    
    You asked if I want the help text to list all the exceptions, or
    alternatively to just tell the user to contact the CSC. Not at all.
    HOWEVER, what could preface the advice would be, imho, a section that
    says:
    
    "If this problem occurs on your system disk and appears to be in an
    OpenVMS-critical directory, please contact your local CSC before doing
    anything else following the advice below. Otherwise...<rest of text>".
    
    Anyone blindly following the advice given will probably *royally* screw
    up a system disk.
    
    Funnily enough, I never have seen this error before in 14+ years of
    VMS'ing. Makes you wonder if VAX OpenVMS 7.1 has had this reported as a
    bug^H^H^Hfeature?
    
    BTW: Removing SYSLOST.DIR wins nothing, I never bother.
    
    /a
    
                    

re .3
    
>I never have seen this error before in 14+ years of VMS'ing.
    
    I believe that it is only fairly recently that ANAL/DISK has included a
    check of the ordering of directory entries.
    
>    BTW: Removing SYSLOST.DIR wins nothing, I never bother.
    
    I think John meant that if you follow the advice that you quoted from
    the help text then you end up with all the files in SYSLOST.DIR. One
    possible final step is just to rename SYSLOST.DIR to be the directory
    that you deleted however I wouldn't do that for two reasons viz. other
    unrelated orphaned files may have been picked up, and this will not
    ensure the correct security attributes that were on the original
    directory.
    
    The last time I had this problem it was SYS$MANAGER. I'm sure glad I
    didn't follow the suggested remedy! (not that I read it)

>>I never have seen this error before in 14+ years of VMS'ing.
>    
>    I believe that it is only fairly recently that ANAL/DISK has included a
>    check of the ordering of directory entries.
    
    Absolutely, the `bug' has been there since V1 and previous.  Without 
    going into the sums, I would wagerthat the re-ordering came on a block
    boundary. 
    
    What has happened is that the XQP got brutally inetrrupted in the
    middle of a `shuffledir', as it sqeezes the files up into the previous
    block.   This sort of situation is bound to occur with a non-logged
    filesystem, we are taking action in 7.1 to reduce the possibility of
    you seeing this (narrowing the window), but this will never be fixed.

    
    In the middle of this shuffle, one file actually got completely
    trashed from SYS$LIBRARY, whilst two files, as per the listing,
    showed up twice.
    
    I discovered the missing file (UCX$ACP_SHR or somesuch) when I rebooted
    and noticed that UCX failed to start up with a meaningful message.
    Installing 4.1 and ECO 4 fixed that.
    
    Interestingly, ANA/DISK didn't find this file and place it in syslost,
    so I wonder where it was sent by the XQP!
    
    /a