Conference iosg::all-in-1_v30

    
    	I can see why changing the directory would make the file cabinet
    	go away. The file OA$DATA:PARTITION.DAT contains the file-id and
    	directory of the DOCDB.DAT of every drawer on the system. If you
    	had used RNA (rename account) it would have fixed up this pointer
    	(assuming it will let you muck with the MANAGER account). You
    	may be able to use one of the system manager menus to fix this
    	up (Manage Drawers or somesuch?)
    
    	Why the identifier was a problem is not clear to me. Maybe by
    	renaming the ident you lost the OAFC$SYSMAN identifier from the
    	manager account so it couldn't manage the file cab server?
    
    	If the docs explained how to do the steps you listed above and
    	didn't tell you about these pointers then I would say its a
    	serious omission - please submit a bug. This stuff belongs in the
    	docs, not in ALL-IN-1 folklore... :-)
    
    Regards,
    Paul

    re: .1
    
    No, all the known identifiers were present.  When you rename an
    identifier in authorize, it does not blow away identifiers associated
    with that account. I also checked to be sure.
    
    The main issue in this circumstance is the fact that the the OAFC$SERVER
    image exited soon after startup because it appeared to want to
    use (for what purpose, I don't know) the original identifier only.
    
    The CSC has been notified of this problem (via the customer) and I
    expect that they will log it as a bug, if there is no fix.

    
    
    There is a bug in the FCS concerning PROFILE.FDL.
    
    The FCS parses OA$LIB:PROFILE.FDL so that it can detect if any
    customisations have taken place.
    
    If the owner listed in the FDL file is not a valid VMS account then the
    parse will fail and the startup of FCS will also fail.
    
    If you're changing the names of some things, then perhaps this worth
    checking on.
    
    
    Kevin.
    
    
    In this instance, there is no error written to the log file, but if the
    FCS is started interactively, then you will see a message regarding
    this.                                                                
    
    

    /Merv,
    
       I'm with CSC I assumme you're from Calgary. I spoke to my collegues
    Mario and Derek, nobody seems to be aware of a customer calling for
    the problem you've stated in .0. If they did, we could have told them
    about the solution in .3 because we have the same problem on our
    system about a week or two ago. I started the server manually and I got
    the symptons so editing PROFILE.fdl changed the owner to ALLIN1 fixed
    the problem. So I don't know which CSC your customer is talking about.
      Can you check please. 
     
     Sorry and thanks,
     ricardo
    
     

    re .5 The customer called the CSC in Atlanta to report the problem on
    Sunday.  After checking note 730, it appears to be the problem.
    
    re .4 I am located in Victoria, B.C., but our system is in Calgary
    which we access quite transparently and efficiently via the extended LAN
    - the network is the system and all the good stuff :^).
    
    re .3 I went through Terry Porter's document yesterday, on the FCS and
    and came to the same conclusion.  The server image exits about the time 
    when it would look at OA$LIB:PROFILE.FDL.  
    
    Strange that the server would look at an FDL file.  It appears that the
    server not only looks at the owner field but also the file spec in the
    FDL file.  When I reverted to the original username (ALLIN1_1) but kept 
    the new directory name (ALLIN1) the server logged an error in the
    SYS$MANAGER:OAFC*ERROR.LOG file, indicating that the config file could
    not be found.  The directory specification in the message was the same
    as what was in the FDL file spec.
    
    Incidently there are also other .FDL files in OA$LIB and they all
    retain the original file spec.  I don't know if other pieces of code in
    ALL-IN-1 may use them, but as a precaution, I intend to modify them
    too.
     
    I plan to make these changes this Saturday.  If if learn anything new, I 
    will post them here. 

    
    re all
    
    You guys are getting good, I didn't have to say a word :-)
    
    
    re .6
    
    >Strange that the server would look at an FDL file.  It appears that the
    >server not only looks at the owner field but also the file spec in the
    >FDL file.  
    
    We do an FDL$PARSE on the profile, we have a bug against us due to
    exactly what you are seeing. We use to require some of the FDL bound
    information. We no longer do, but the call to the FDL$PARSE was never
    removed.
    
    --Bob
    

    The FCS doesn't have all of the stuff in the main image to look at the
    "shape" of files, so it uses the FDL to figure out if you've customised 
    it (putting words in Bob's mouth here :-) ).
    
    I don't think you'll need to change all the other FDLs, since the name
    field isn't normally used.
    
    Having said that, I normally remove the name, owner and protection
    fields from FDLs, and often most of the allocation fields too!
    
    Graham

    Well, we are part way there.

    I renamed the user ALLIN_1 to ALLIN1 in sysuaf; changed fields in
    A1CONFIG, profiles of MANAGER and POSTMASTER to use ALLIN1; edited
    OA$LIB:profile.fdl so that owner=[ALLIN1]; and restarted ALL-IN-1.

    The system came up as expected, FCS server log files indicated that
    startup was completed.  So finally we are back to using ALLIN1 as the
    account for MANAGER and FCS is happy with it too :-).

    I then decided to remove the directory alias (ALLIN1_1.DIR) that I
    had  put in earlier.  Thats when FCS broke.  

    After restarting FCS from the manager account the following message
    appeared in  SYS$MANAGER:OAFC$SERVER.LOG:

    11-JUL-1992 09:42:58.39  Server:  PFC::"73="  Error: %RMS-E-DNF,
    directory not found  Message: Csi$Start; Error performing $parse of
    SDAF file

    In the SYS$MANAGER:OAFC$SERVER_ERROR.LOG file:

    Error opening SYS$SYSDEVICE:[ALLIN1_1.SHARED_E]OA$DAF_E.DAT

    I have changed all FDL files in OA$LIB that reference the old directory
    to point to the correct location (i.e. A1$DISK1:[ALLIN1.*]).  A1$DISK1
    translates to PFC$DUA0: (which is also SYS$SYSDEVICE).

    I have reverted to using the directory alias, because the change window
    did not permit met to keep the system down for too long.  But
    subsequent to then I have found the file ownership of OA$DAF_E.DAT is
    SYSTEM.  Could this be the cause?
               

    I have been informed, that what I have to do is to go into ALL-IN-1 and
    use the Manage Mail Areas option to point to the new device and directory
    specification.
    
    Thought I should mention it in here just incase someone else overlooks
    this point :^)