[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

2866.0. "FCS stops, Documents remain RESERVED" by OSLACT::BJARNEC_P (The last boat left without me .....) Tue Jun 15 1993 11:06

    Hi,
    
    
    Users at one of our customer sites have problems accessing a Shared
    Drawer.  It all started with a disk crash.  This was one of their
    ALL-IN-1 user disks.  They decided to restore backup of the disk to
    another disk (!!) and also to start using a logical disk name (used
    physical disk references on the one they moved from).  I recommended
    (after they had moved to the new disk, anyway) that they should change
    the profile of all the moved users, then execute the script
    OA$PART_SEED and then run the Housekeeping procedures TRM and TRU. 
    
    They have done all this apart from TRM and TRU and all users seem to
    function fine with the exception of being able to access a Shared
    Drawer that one of the users had set up.  The first one that accesses a
    document in this drawer (all users that have been granted access can
    see it), doing either an Edit or Create, will manage this but the
    document will then remain in a RESERVED state.  Subsequent users then
    hang when they try to access (edit/create) documents in the Shared
    Drawer.  On at least one occation the process OA$FCV looped, taking
    80-100% of the CPU, but on most occasions the FC Server just stops.
    
    Have just searched the RESERVATION.DAT file in the Shared Drawer and I
    can see the 2 documents that are RESERVED.  There is, however, a
    cluster alias name associated with each of these 2 records in
    RESERVATION.DAT.  This is strange, I think, because ALL-IN-1 only runs
    on 1 node in this 2 node cluster (VAX1, VAX2 and alias CLUSTA).  All other
    references to a node name use the name VAX1 (e.g. Process Name:      
    VAX1$SRV73, OA$DATA_SHARE:VAX1$SERVER73.DAT, VAX1::"73=" ... etc.). 
    
    Q1) Could this be the problem?
    Q2) How come the cluster alias gets written into RESERVATIONS.DAT?
    Q3) How would it be best to proceed with this case?
    
    I feel inclined to wait till tonight, shut down ALL-IN-1 and run
    TRM and TRU - and hopefully this may do the trick.  The other option I
    could try is to restore the user (including his Shared Drawer) onto the
    original disk and then do a RNA to move him to the new disk.  If someone
    has any other good ideas I would much appreciate some help with this one!   
    
    
	Regards,
    
    		Bjarne

T.R	Title	User	Personal Name	Date	Lines
2866.1		IOSG::STANDAGE		`Tue Jun 15 1993 11:21`	20
	Bjarne, I apologise, but currently I'm too busy to look at this in any detail. However, I have a couple of comments: a) OA$FCV is not related directly to the FCS. It is a detached process which is used to provide unique fle names for cabinet entries. This mechanism has been around for a few releases of ALL-IN-1, where as the FCS is obviously new to V3.0. BTW: The FCS process is called <node>$SRV72 b) If users have added the shared drawers to their File Cabinets, they will need to re-add the drawers once they have moved disks (DRM ADR). Also check to see if the owner of the drawer can successfully create and edit documents. Kevin.
2866.2	Check the server logfile too...	IOSG::STANDAGE		`Tue Jun 15 1993 11:23`	11
	Bjarne, Also check the FCS log file to see if any errors have been logged: SYS$MANAGER:OAFC$SERVER.LOG Kevin.
2866.3	SYS$MANAGER:OAFC$SERVER.LOG	OSLACT::BJARNEC_P	The last boat left without me .....	`Tue Jun 15 1993 11:38`	32
	Kevin, That's what I call "replying by the speed of light"! I check to see if the owner can edit a document. Below is the end of the SYS$MANAGER:OAFC$SERVER.LOG:- . . . 8-JUN-1993 11:36:04.08 Server: VAX1::"73=" Message: Startup for File Cabinet Server V1.0-2 complete 10-JUN-1993 07:34:42.32 Server: VAX1::"73=" Error: %OAFC-E-INTERR, Internal error in File Cabinet Server Message: CsiOpenDrawer; DOCDB file/dev id does not match IUID in partition, continuing 11-JUN-1993 07:59:42.31 Server: VAX1::"73=" Message: Startup for File Cabinet Server V1.0-2 complete 14-JUN-1993 15:11:51.72 Server: VAX1::"73=" Message: Startup for File Cabinet Server V1.0-2 complete 14-JUN-1993 16:53:36.37 Server: VAX1::"73=" Error: %DSL-E-INVSPEC, Invalid component specification Cheers, Bjarne
2866.4	User sees different Partition than Mgr	OSLACT::BJARNEC_P	The last boat left without me .....	`Tue Jun 15 1993 14:55`	169
	Here comes further info:- A trace from the owner of the Shared Drawer editing and creating documents. Plese note the partition name is CLUSTA (= Cluster Alias). This did not lead to the edited or the new document becoming RESERVED, but, from what the system mgr told me the 1st user didn't have any problems - only subsequent users. Extract of the trace follows: ![SCRIPT] WP_SYS_EDIT Line 4: .IF CAB$.MAIL_STATUS:U[OA$CURDOC] NES "RESERVED" A ! ND OA$CURDWR_SHARED EQS OA$N THEN .GOTO OWN_EDIT ![SYMBOL] Symbol: OA$CURDOC, Value: AB 000733 ![SYMBOL] Symbol: CAB$.MAIL_STATUS:U[OA$CURDOC], Value: ![SYMBOL] Symbol: "RESERVED", Value: RESERVED ![SYMBOL] Symbol: OA$CURDWR_SHARED, Value: J ![SYMBOL] Symbol: OA$N, Value: N ![SCRIPT] IF Operation starting ![SCRIPT] .IF condition CAB$.MAIL_STATUS:U[OA$CURDOC] NES "RESERVED" AND OA$CURD ! WR_SHARED EQS OA$N is FALSE ![SCRIPT] Null ELSE clause detected ![SCRIPT] WP_SYS_EDIT Line 5: GET #DRAWER_FULLPATH = OA$CURDWR_PARTITION "." '"' ! OA$CURDWR_LOCATION '"' ![FUNC] Function: GET, Cmd line: #DRAWER_FULLPATH = OA$CURDWR_PARTITION "." '" ! ' OA$CURDWR_LOCATION '"' ![A1LOG] Entry: %OA-I-LOGFUN, Funksjon: GET #DRAWER_FULLPATH = OA$C ! URDWR_PARTITION "." '"' OA$CURDWR_LOCATION '"' ![SYMBOL] Symbol: #DRAWER_FULLPATH = OA$CURDWR_PARTITION "." '"' OA$CURDWR_LOCAT ! ION '"', Value: CLUSTA::."[SOERUM]PLAN" ![SCRIPT] WP_SYS_EDIT Line 6: GET #RL_KEY = #DRAWER_FULLPATH:249 OA$CURDOC_DOCNU ! M ![FUNC] Function: GET, Cmd line: #RL_KEY = #DRAWER_FULLPATH:249 OA$CURDOC_DOCN ! UM ![A1LOG] Entry: %OA-I-LOGFUN, Funksjon: GET #RL_KEY = #DRAWER_FULLP ! ATH:249 OA$CURDOC_DOCNUM ![SYMBOL] Symbol: #RL_KEY = #DRAWER_FULLPATH:249 OA$CURDOC_DOCNUM, Value: CLUSTA ! ::."[SOERUM]PLAN" ! ! ! 000733 ![SCRIPT] WP_SYS_EDIT Line 7: GET #DOC_FULLPATH = #DRAWER_FULLPATH "." '"' OA$CU ! RDOC_FOLDER '".' OA$CURDOC_DOCNUM ![FUNC] Function: GET, Cmd line: #DOC_FULLPATH = #DRAWER_FULLPATH "." '"' OA$C ! URDOC_FOLDER '".' OA$CURDOC_DOCNUM ![A1LOG] Entry: %OA-I-LOGFUN, Funksjon: GET #DOC_FULLPATH = #DRAWER ! _FULLPATH "." '"' OA$CURDOC_FOLDER '".' OA$CURDOC_DOCNUM ![SYMBOL] Symbol: #DOC_FULLPATH = #DRAWER_FULLPATH "." '"' OA$CURDOC_FOLDER '".' ! OA$CURDOC_DOCNUM, Value: CLUSTA::."[SOERUM]PLAN"."AB".000733 ![SCRIPT] WP_SYS_EDIT Line 8: FILECAB GET_ATTRIBUTES (DOCUMENT = #DOC_FULLPATH, ! #MS = MAIL_STATUS, #MF = MODIFY) ![FUNC] Function: FILECAB, Cmd line: GET_ATTRIBUTES (DOCUMENT = #DOC_FULLPATH, ! #MS = MAIL_STATUS, #MF = MODIFY) [A1LOG] Entry: %OA-I-LOGFUN, Funksjon: FILECAB GET_ATTRIBUTES (DOCUMEN ! T = #DOC_FULLPATH, #MS = MAIL_STATUS, #MF = MODIFY) ![SYMBOL] Symbol: #DOC_FULLPATH, Value: CLUSTA::."[SOERUM]PLAN"."AB".000733 ![IO] FILECAB Server Request: LIST ![IO] Getting field CODE from OA$FOLDERS, Value: NO ![SCRIPT] WP_SYS_EDIT Line 9: .IF OA$STATUS EQ 1 THEN .GOTO SERVER_OK ![SYMBOL] Symbol: OA$STATUS, Value: 1 ![SYMBOL] Symbol: 1, Value: 1 ![SCRIPT] IF Operation starting ![SCRIPT] .IF condition OA$STATUS EQ 1 is TRUE ![SCRIPT] THEN Operation starting ![SCRIPT] WP_SYS_EDIT Line 9: .GOTO SERVER_OK ![SCRIPT] WP_SYS_EDIT Line 13: .IF #MF EQS "N" THEN .GOTO NO_PRIV ![SYMBOL] Symbol: #MF, Value: Y ![SYMBOL] Symbol: "N", Value: N ![SCRIPT] IF Operation starting ![SCRIPT] .IF condition #MF EQS "N" is FALSE Secondly, the owner doing a FC DRW --> selecting our favourite Shared Drawer yields the following result when he does a READ:- Skuff (=Drawer) PLAN System (=System) CLUSTA:: Eier (=Owner) SOERUM Skuffnavn (=Drawer name) PLAN Beskrivelse (=Description) Planarkiv Filkatalog (=Directory spec) HRE$BRK:[SOERUM.OA.PLAN] Thirdly, from the Manager account, doing SM MFC DR --> selecting the Shared Drawer and then a READ gives the following:- Skuff VAX1::"[SOERUM]PLAN" System VAX1:: Eier SOERUM Skuffnavn PLAN Beskrivelse Filkatalog HRE$BRK:[SOERUM.OA.PLAN] ==> It is clear (isn't it?) that the user thinks he is using a Partition called CLUSTA::, while looking from the Sys Mgr the Partition is called VAX1::. Doing a SM MP (Manage Partitions) proves the previous theory:- Read Partition: Read Partition Partition Name: VAX1:: Enabled: Y Partition Filename: OA$DATA_SHARE:PARTITION.DAT Protection: Read Write Execute Delete Owner: Y Y Y Y Group: N N N N System: Y Y Y Y World: N N N N Cheers, Bjarne
2866.5	2 Partitions in same PARTITION.DAT !!!	OSLACT::BJARNEC_P	The last boat left without me .....	`Thu Jun 17 1993 15:33`	26
	....... and further investigation has shown: 1. In MP menu it is possible to select 2 (!!) Partitions!! Yet, there only is ONE OA$DATA_SHARE:PARTITION.DAT file. They are running ordinary DECnet Phase IV and hence OA$DATA_SHARE:PARTITION_MASTER.DAT is empty. 2. The first one of the 2 partitions has the Node Name of the VAX running ALL-IN-1 and the second partition has the name of the Cluster Alias. Furthermore, it is not possible to delete any of the partitions (by MP, selecting the appropriate one, and D). It fails with an error message along the lines of: "Operation not possible because of DECnet Naming ...". Does anyone know what can be done to get out of this mess? All hints and good suggestions would be VERY MUCH appreciated! Regards, Bjarne
2866.6		IOSG::STANDAGE		`Fri Jun 18 1993 10:29`	12
	Bjarne, The Manage Partitions subsystem is only useful if you are running servers with distribution level 1 (i.e. DNS naming). If you're using DECnet naming, there is no Partition management necessary (other than the use of the ADD option from that subsystem, which will still work). Kevin.