From malon@sun3.hep.anl.gov Thu Oct 30 15:34:42 1997
Date: Thu, 30 Oct 1997 17:34:26 -0600
To: challenge@sseos.lbl.gov
Subject: Objectivity File Locator Errors
Cc: malon@sun3.hep.anl.gov
From: "David M. Malon"     <malon@anl.gov>


As agreed at our meeting today, I have investigated Objectivity's behavior 
when a database file cannot be located.  It is, in fact, possible to detect 
this problem in two ways:  

    1.  The open() method returns a non-zero status code, and one can 
        then check the most recent error data (global variables).  

	while (!dbHandle.open(innerName, oocRead)) {
	   cout<<"\t*** Last error was "<<oovLastError->errorN<<" (level ";
	   cout<<oovLastErrorLevel<<"); message was ";
	   cout<<oovLastError->message<<endl; 
	   cout<<"\nRetry?";
/*
   Interactive version:  if the answer is "yes," then put the file where it's 
   supposed to be and type 'y'
*/
	   char answer;
	   cin>>answer;
	   if (answer!='y' && answer!='Y') {
	     cout<<"Aborting transaction and exiting."<<endl;
	     trans.abort();
	     return 1;
	   }
	}

    2.  One can write and register an error handler.  

	
ooStatus trapMissingFiles(const ooErrorLevel errorLevel,
                          const ooError&     errorId,
                          const ooHandle(ooObj) *contextObj, 
			  char* fileName) { ... }
...
        ooErrorHandlerPtr oldEHPtr;
	oldEHPtr = ooRegErrorHandler(*trapMissingFiles);

In either approach, one has access to the error number (4301) and a string 
that can be parsed to yield the desired hostname::filename:

** Error #4301: ooHandle(ooDBObj)::open(): Storage Manager: Cannot open file
                pdsfni1::/home/users/malon/ObjyTests/Fed1/default_odmg_db.NA49a.DB (No such file 
or directory) (100101)


While one can unintrusively detect the problem and correct it, I know of no 
way to tell Objectivity after this is done to retry the open automatically.  
Opening the database in a while loop would work:

	while (!eventDB.open(dbName, oocRead)) {
           if (!ArieMovedTheFileWhereObjectivityExpectsIt()) abort();
        }
               
This is easy to accomplish transparently to users with database wrapper 
classes like those under consideration by BaBar and RD45.  It would be better, 
though, to have hooks inside Objectivity, so that Objectivity--not the 
user--would retry the open.

There should really be at least two choices for corrective action:  

   1.  Put the file where Objectivity expects it;
   2.  Tell Objectivity where to look for the file.  

The latter should be possible using a tool called oochangedb with the 
-catalogonly switch.  Without the switch, oochangedb will move a database file 
to a new location and update Objectivity's catalog of database locations.  If 
one has already moved or copied the file, the -catalogonly switch should allow 
updating the catalog without moving the data.  I have not yet managed to get 
this option to work:  Objectivity thinks it needs to open the old file anyway.  

   Example:  After moving an Objectivity file default_odmg_db.NA49a.DB to 
     default_odmg_db.NA49a.DB~, queries, of course, fail.  
     When I try to tell Objectivity to look in the new location, here's what 
     happens:  

oochangedb -db default_odmg_db -host pdsfni1 -filepath 
/home/users/malon/ObjyTests/Fed1/default_odmg_db.NA49a.DB~ -catalogonly NA49a

Objectivity/DB (TM) Change Database Utility, Version 4.0.2
Copyright (c) Objectivity, Inc 1993, 1996. All rights reserved.

** Error #4301: ooHandle(ooDBObj)::open(): Storage Manager: Cannot open file
                pdsfni1::/home/users/malon/ObjyTests/Fed1/default_odmg_db.NA49a.DB (No such file 
or directory) (100101)
** Error #11913: oochangedb: Unable to open Database "default_odmg_db".
                 Processing terminated.

I see no reason that Objectivity should even care about the existence of the 
old file when I have used the -catalogonly switch.

David Malon
30 October 1997