[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:*OLD* ALL-IN-1 (tm) Support Conference
Notice:Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:IOSG::PYE
Created:Thu Jan 30 1992
Last Modified:Tue Jan 23 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:4343
Total number of notes:18308

3688.0. "TRM and "drawer in use"" by KERNEL::OTHENJ () Tue Dec 21 1993 15:52

Hi,

A customer has had a long standing problem with TRM over the last few months. 
He originally had ALL-IN-1 v2.4 (see note 3355), and was recieving the 
error

Error reading record from managers docdb.dat
Error of unknown cause
Error=? Record/Bucket locked

which caused the procedure to fail. He then left this problem for a while, 
but has since upgraded to v3.0 and the error has now changed to 

Failed to access drawer
Drawer in use
This error will prevent TRM from completing

on the managers account.

The customer can log into his managers account, and this works fine. He is 
going to run it again with show dev/files <userdisk:> but on v2.4 we 
certainly found that the managers account was not open.

If he runs TRU, he still receives the error but the procedure completes.

I have seen that the problem with TRU reporting this problem is supposed to 
be fixed by the MUP, but there is no mention of TRM. Should the MUP also 
fix the problem for TRM as well? If I simply stop the FCS prior to running 
TRM, will this definitely kill off all user processes as a quick 
workaround?

	Thanks,

			Julie
T.RTitleUserPersonal
Name		DateLines
3688.1/OVERRIDE ??IOSG::MAURICEI left my heart in AlcatrazTue Dec 21 1993 16:3111
    Hi,
    
    I don't think we have solved any TRM problem in the MUP that fixes your
    problem. What you're doing is the right thing, i.e. the show dev/files.
    
    I suspect there is some batch job that is using ALLIN1/OVERRIDE to
    enter ALL-IN-1 at a time when it is shutdown.
    
    Cheers
    
    Stuart
3688.2"Drawer in use..." always for same users...ATHINA::RALLISNicholas RallisFri Dec 24 1993 08:3821
    Hi,
    
    ref: 1239.*, 3287.*, 3688.*
    
    I have a comment on this problem: I have noticed that when TRM or TRU
    the error "Drawer in use..." appears ALWAYS on the same user's drawers
    (in our site, there are always the same two users). 
    
    Question: Why the FCS keeps locked always and CONSISTENTLY the drawers
    of the same users? Is there anything special on these users file
    cabinets (or drawers) that we should look at??? 
    
    Before I apply CSPAT_3605, recommeded in TIMA/STARS, is there anything
    I could do on these individual users to overcome the problem?
    
    
    regards
    
    Nicholas
3688.3SPAWN problem?IOSG::MAURICEI left my heart in AlcatrazFri Dec 24 1993 13:4914
    Hi,
    
    I don't think the FCS is the problem, not when you are up to date with
    pataches anyway. The one major flaw we know of is that if a user SPAWNs
    out to a sub-process from ALL-IN-1, then the shutdown AST does not get
    delivered and the user remains logged in. The workround that I have
    seen is to run a DCL procedure to kill any users still logged in.
    
    Perhaps your two users are leaving whilst currently in a SPAWNed
    sub-process.
    
    Cheers
    
    Stuart
3688.4The mystery is still aroundATHINA::RALLISNicholas RallisTue Dec 28 1993 12:3015
    Hi Stuart,
    
    the mystery is that the two users ARE NOT LOGGED in by any means, and
    there is no spawned subprocess under their name! I have checked that
    at night, loging into the system (from home) and looking at things just
    before TRM or TRU are about to run.
    
    
    By the way I have not installed any patches so far... Since June 1992
    that I installed ALL-IN-1 V3.0...
    
    
    regards
    
    Nicholas
3688.5IOSG::MAURICEI left my heart in AlcatrazWed Dec 29 1993 15:3212
    Hi,
    
    It doesn't have to be the two users logged in. Another user, or batch
    job, may have NEWDIRed or a CABINET SET_DRAWER or a MAIL SET_USER. So
    when you do your check do a $sho dev/files on the relevant disk.
    
    Also I recommend that you get patched up to date. I think V3.0-1 had
    some relevant changes, but I don't think MUPA did.
    
    Cheers
    
    Stuart
3688.6KERNEL::OTHENJTue Feb 01 1994 11:5213
    Hi,
    
    Just to let you all know, we (finally) tracked down the problem at my
    customer site with the oaini.scp file. Customer had complained about
    the amount of time that it took to go into EM, so they added MAIL
    INITIALIZE in oaini.scp. This was causing the problem. They have now
    altered it to "if =manager then do not do mail initialize" and TRM
    works successfully.
    
    	Thanks for the help,
    
    
    			Julie