Conference iosg::all-in-1_v30

    Suzanne,
    
    	The error is telling you to check the RMS STS and STV error
    	messages that 'should' be returned. Unfortunately, ALL-IN-1 and
    	FCS between them fail to pass this information to the caller (I
    	have SPRed this).
    
    	Have you checked the file protections etc on the user's account.
    
    	The File Cabinet Server uses SYSPRV to access the user's ALL-IN-1
    	sub-directory during partition seeding. Therefore if the A1.DIR 
    	doesn't allow SYSTEM access you will see the error.
    
    	Seems likely to me that the error is occuring at the 'WRITE ADD 
    	PART$MAINT ..." in the .SCP. You can confirm this with trace or
    	by manually doing the WRITE ADD. The PART$MAINT DSAB does some 
    	checks to ensure that the account has a DOCDB and DAF and that
    	they are accessable before adding the record.
    
    	Failing that use SET WATCH etc to check for the RMS error codes.
    
    Cheers,
    
    Iain.

    
    What timing! Just a minute ago I loaded an article into STARS with
    this error.  It came from Richard Davies.  They saw this problem on
    their system.  It was a 2 node cluster. And they had problems with
    cross drawer operations intermittently. It turned out that the
    problem was on one node, the system parameters GBLPAGES and GBLPAGFIL
    were too low and caused the FCS to fail.  They set them to be the
    same as the other node that the FCS was working on and that solved
    the problem.
    
    Are you having the problem on a cluster? Check these parameters and
    try increasing them too see if this is the problem.
    
    Let me know of the outcome,
    
    Faith
    

    Iain, Faith
    
    	The problem is indeed with the Write add,  The error occurs just
    after this.  Set watch files shows nothing useful at all, it doesn't
    even show access to partition.dat.  The account this is run from
    (allin1) has sysprv and you can access the users docdb.dat and daf.dat
    (the mfc mp add does somechecking at this point as well).  Tried this
    on another node in the cluster and get exactly the same error.  
    I'm not sure what else to check.
    
    Suzanne 

    
    	PART$MAINT always calls the file cab server for its data file
    	access which is why SET WATCH doesn't show you anything.
    
    	Try turning on a File Cab server trace to get the extended status.
    
    Regards,
    Paul

    
    Can you put in the output of the following VMS command:
    
    $ dir/security [user.a1]*.dat
    
    I have a feeling that the docdb.dat or some other file has no system
    protection on it which is keeping the FCS from getting to the file.
    
    --Bob
    

    Bob, Iain, Faith,
    
    I've cracked it, it was either an empty filecab.dat, once it was deleted it,
    the write add appeared to work. Or the directory had the wrong
    protection, (I suspect not of the named data on the MP ADD option could
    access DOCDB.DAT ok.) 
    
    Thanks everyone for your help
    
    Suzanne 
    
    
    

    Hi All,
    
    I have a customer who get's the same error message as reported in the
    base note and it is followed by Insufficient priv. file protection
    violation.
    
    This only occurs when the customer is trying to copy a document from a
    shared drawer to their personal drawer.  
    
    I have asked the customer to check the users ALL-IN-1 directory and the 
    files to ensure it's have s:rwe in particular DOCDB.DAT.  Also I have
    asked the customer to ensure that the ALL-IN-1 files and directories
    have the correct prot. and ownership.  The reason why I have asked
    them to this extensive audit is because they are a trouble some
    customer. I have also asked them to do an ALL-IN-1 trace and walked
    them through how to do a trace and they still cannot get it right !!
    
    Basically it's a government department that sends out upgrade kits and
    customisations to the various states.  Some of these states do not have
    basic ALL-IN-1 or VMS skills let alone the skill to set-up a modem. 
    Hence I am asking you all if there is anything else I should look for. 
    By the way the customer has told me that they feel that auditing is a
    waste of time 8^(.
    
    I would be grateful for any input I am sure it's incorrect file
    protection or ownerships, but on the other hand you may know something
    more.
    
    Thanks in advance,
    
    Sunil

    
    My guess is that the protection on the actual document file, the
    one with the really big ugly name, is the problem. Have the 
    user log into the SYSTEM account and try to copy that file some place.
    
    The problem also could be on the personal drawer, make sure that 
    system has RWED access to the drawer they are trying to copy to.
    
    --Bob
    

    Hi Bob, 
    
    Thanks for your input the problem was with file protection the
    reservations.dat did not have system access this has been changed to
    s:rwe.
    
    Regards,
    
    Sunil