[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

3287.0. "Problems accessing Drawers - "Drawer in Use" message" by OSLACT::SIGURDA_P () Thu Sep 16 1993 16:21

    Hi,
    
    
    Having a problem on a customer site:- It appears that after every time
    they have run the Housekeeping procedures (PT, ROF, EW) some of their
    users have problems accessing their Drawers, both private and shared
    ones.  Error message is:
    
    "Drawer in use"
    
    Their system configuration is a 2 node cluster, both of which are
    running ALL-IN-1.  Each ALL-IN-1 system has a File Cabinet Server (FCS)
    and a PARTITION.DAT file.
    
    The problems seem to dissapear if both the FCS are stopped and
    restarted.  From what I can see, also, one of the FCS processes takes
    out locks on some of the files like: DOCDB.DAT (well, at least this
    one!). 
    
    The PT log file has some dodgy stuff in it which we are in the process
    of looking into.
    
    Any ideas of things to try?
    
    
    Thanks,
    
    	Sigurd

T.R	Title	User	Date	Lines
3287.1	should only be one partition.dat	CHRLIE::HUSTON	`Thu Sep 16 1993 17:58`	13
	re .0 >Their system configuration is a 2 node cluster, both of which are >running ALL-IN-1. Each ALL-IN-1 system has a File Cabinet Server (FCS) >and a PARTITION.DAT file. Are you saying that one one cluster there are 2 partition.dat files? If so this could be the cause of the problem, the partition file should be cluster wide, all FCS's on the cluster share it. --Bob
3287.2	More info	OSLACT::SIGURDA_P	`Mon Sep 20 1993 14:42`	76
	Bob, They have only one partition.dat. Sorry for my late reply. More info: SYS$SYSROOT:[SYSMGR]OAFC$SERVER_ERROR.LOG;1 There a severel entries in the OAFC$SERVER_ERROR.LOG; file. But the context are almost equal for everyone. The lock on the following drawer has become invalidated by another process. Note that the lock has been granted and OafcNormal will be returned to the client, however, all other processes wishing to share this lock will also be granted invalid locks until all processes sharing this lock are terminated. Drawer directory: WORK07:[EDP_HAUGEN.ALLIN1.ZUVSN71RP] Drawer owner: EDP_HAUGEN AND, SYS$SYSROOT:[SYSMGR]OAFC$SERVER.LOG;0 16-SEP-1993 15:08:34.18 Server: NORSK1::"73=" Error: %OAFC-E-INTERR, Internal error in File Cabinet Server Message: FCS has access violated, please submit an SPR. 17-SEP-1993 14:02:59.52 Server: NORSK1::"73=" Error: %SYSTEM-W-VALNOTVALID, va lue block is not valid Message: CsiCacheGetVMSDrawerLock; lock manager has in validated the drawer lock Today I discovered yet another problem: An existing shared drawer was unavailable to users who where granted access earlier. PARTITION.SHARE_TYPE[OA$CURDWR_LOCATION] was N. I used EDT to change the drawer type to regular shared. The drawer was updated with no errors. But Read from MD dislayd 'The drawer is not shared with users.' AND SHARE_TYPE[OA$CURDWR_LOCATION] was still N. SO, then I tried the old trick (stop both File cab. servers and start them again) described in .0. After this emergency routine the drawer was accessible for the origninal accounts as it used to be. Strange .... As you probably already have understood, this is not an easy case to describe nor to ask the good questions. Have any of you experiences with partition problems? Two nodes running one FCS each in a cluster using only one partition.dat? I have checked sysstem parameters, could this still cause the problems? I have also got a RMS error message from the file cab. server wich where suppressed by the server. A remainder: All this problems started after an incorrect drawer deletion, backup and some rename of accounts wich owned shared drawers. Latest news, some documents get incorrectly reserved by system. Message 'document reserved by system, do you want to unreserve?' There are no problems to access the actual document after answering yes to the question above. Any hints would be apreciated. Thanks, Sigurd alfsen @NWO
3287.3	Further info about configuration.	OSLACT::SIGURDA_P	`Mon Sep 20 1993 14:49`	7
	ALL-IN-1 English version 3.0 1993-02-17 21:56:16.59 S030_002 CC 002 SHARE S3.0-002 ALL-IN-1 1993-02-17 21:02:05.76 V030_001 EE 005 SHARE V3.0-1 ALL-IN-1 Sigurd.
3287.4	security coordination problem	CHRLIE::HUSTON	`Tue Sep 21 1993 14:15`	31
	re .2 There are no problems with having one partition file for x number of servers on the same cluster, in fact, that is the ONLY supported way to do it unless they run with DNS naming. The drawer lock error you are seeing, i have seen that as a result of an IOS user having a drawer locked and cntrl -Y out of IOS, then the lock coordination between the FCS and IOS gets a little confused. i have never seen a problem with it though, things have always worked fine. The comments about the PARTITION.SHARE_TYPE stuff, I have no idea what that is. But if you change drawer info via IOS, then if the FCS has the drawer open (it keeps it open after the user closes it), the FCS would not have the new information until the FCS drawer cache is flushed. This is yet another coordination problem between IOS and the FCS when it comes to drawer information. Both sides clean them selves up just fine, problems start when one side make a change, like security information for example, the other side doesn't catch the change right away. the reason the restart worked is becuase the is a way of forcing the FCS to flush its drawer cache (sort of like killing an ant with a sledge hammer). Assuming the system is fairly busy at least, the FCS would have sorted it out eventually, when the drawer went unaccessed for some amount of time, then closed the drawer down, the next drawer access would have gotten the updated information. --Bob