Help!! What is the problem??

It appears that you are trying to access a database with the gdbm command. It is having trouble opening the file check you system make sure you have enough space and the file is there to open.

GDBM cannot have the same database open for read and write at the same time.

Maybe the db was never closed after being opened for write.

Jim Kosloskey

Hyunyoung,

You probably need to incorporate some re-try/error logic with respect to opening the database; if it attempts to open the database while it is open for write, then an error will be returned.  You can do something like this:

#This code keeps attempting to open the database until successful #

    set retcd 1

    while { $retcd } {

         set retcd [catch {gdbm_open $db_name}]

    }

# End of open loop #

Hope this helps.

Jim Cobane

Henry Ford Health

To view gdbm database content: from hcitcl execute the regular GDBM commands. Keep in mind that the database must be open first, before executing any other command  and while the database is open, the tcl will not have access to it, so it is not a good idea to keep a production database open for viewing.

To close it:

hcitcl gdbm_close /pathway/dbname

Examples of gdbm commands:

gdbm_list /hci/root3.8.1P/pmctest/exec/processes/prov_test_adt1/cerner.db                    # lists all keys in the db

gdbm_store /hci/root3.8.1P/pmctest/exec/processes/prov_test_adt1/cerner.db  key  content   # writes into the db

gdbm_close /hci/root3.8.1P/pmctest/exec/processes/prov_test_adt1/cerner.db

gdbm_firstkey /hci/root3.8.1P/pmctest/exec/processes/prov_test_adt1/cerner.db             # reads first key in the db

gdbm_nextkey /hci/root3.8.1P/pmctest/exec/processes/prov_test_adt1/cerner.db key      # reads next key

gdbm_delete /hci/root3.8.1P/pmctest/exec/processes/prov_test_adt1/cerner.db key          # deletes a key from the db  

gdbm_fetch /hci/root3.8.1P/pmctest/exec/processes/prov_test_adt1/cerner.db key         # reads a specific key

Hyunyoung,

I would shut down any process that is accessing that database, and that should free the lock.

Jim Cobane

Henry Ford Health

If the data is reproducable and expendable you may be able to simply delete the gdbm database that is having the issue.  I have had this occur in the 5.3 environment.  I then moved away from gdbm when all was said and done.

We have been using gdbm quite successfully for several years, but be warned. Working with gdbm can cause your hair to turn grey.

You can open a database for writing (single-user mode) by only one instance of the tcl interpreter. If it is not open for writing, you can open it for reading (multi-user mode) by many instances.

You must have created the db file before you attempt any gdbm_open calls.

If you are placing the gdbm calls inside multiple xlates you will be fine as long as they are in the same CL process, and you add some code to make sure you don’t attempt to open it more than once. You will want to open it for writing. Opening the db only once within the process is fine. If using this inside xlates, you do not need to close the db.

If you are placing the gdbm code inside tcl procs for use outside the xlates, you have to implement your own file locking. For “multi-user access” the best option is to use tcl’s flock call. (Go to hcitcl and say “help flock”.) You cannot use flock directly on the database file so you must create a semaphore file that you use flock with. Then you must write your code so you always access the semaphore file with flock before trying to open the gdbm database. After your access, use the gdbm_close call and then call funlock on the semaphore file. Use this flock/open/access/close/funlock sequence for each db access so all instances will have equal opportunity to access the db.

When using flock with multiple files, particularly in multiple routines, always open and access the files in the same sequence and close them in the reverse order (unwind) so you can avoid deadlock problems.

When implementing the flock calls you use the options -read and -write. This allows multiple tcl instances to access the db for reading yet make them wait if an instance wants to open the db for writing. It also makes the write job wait if anyone has the file open for reading.

You can certainly play with this and test it by opening two telnet sessions, firing up hcitcl and entering the commands manually. You will see how access to the db by the two instances is controlled.

Email me if you would like some sample code.

I like gdbm.  It’s quirky and fun.

You don’t say what version you are using, but starting around 5.3 rev something (we use AIX 5.3 Rev 2) a new process appeared: hcigdbm

If it is running, try killing it and running the script below from the hci command line.  (Also, stop processes that use xlt_query_gdbm first.)