DBM(3B)                                                                DBM(3B)


NAME
     dbm: dbminit, dbminit64, dbmclose, dbmclose64, fetch, fetch64, store,
     store64, delete, delete64, firstkey, firstkey64, nextkey, nextkey64 -
     data base subroutines

SYNOPSIS
     #include <dbm.h>

     typedef struct {
          char *dptr;
          int dsize;
     } datum;

     int dbminit(const char *file);

     int dbminit64(const char *file);

     void dbmclose(void);

     void dbmclose64(void);

     datum fetch(datum key);

     datum fetch64(datum key);

     int store(datum key, datum content);

     int store64(datum key, datum content);

     int delete(datum key);

     int delete64(datum key);

     datum firstkey(void);

     datum firstkey64(void);

     datum nextkey(datum key);

     datum nextkey64(datum key);

DESCRIPTION
     Note: the dbm library has been superseded by ndbm(3B), and is now
     implemented using ndbm.  These functions maintain key/content pairs in a
     data base.  The dbm functions will handle very large (a billion blocks)
     databases and will access a keyed item in one or two file system
     accesses.  The dbm64 routines are identical to their dbm counterparts
     except that they can be used to operate on data bases larger than 2
     Gigabytes.


     Keys and contents are described by the datum typedef.  A datum specifies
     a string of dsize bytes pointed to by dptr. Arbitrary binary data, as
     well as normal ASCII strings, are allowed.  The data base is stored in
     two files.  One file is a directory containing a bit map and has `.dir'
     as its suffix.  The second file contains all data and has `.pag' as its
     suffix.

     Before a database can be accessed, it must be opened by dbminit.  At the
     time of this call, the files file.dir and file.pag must exist.  (An empty
     database is created by creating zero-length `.dir' and `.pag' files.)

     Once open, the data stored under a key is accessed by fetch and data is
     placed under a key by store.  A key (and its associated contents) is
     deleted by delete.  A linear pass through all keys in a database may be
     made, in an (apparently) random order, by use of firstkey and nextkey.
     Firstkey will return the first key in the database.  With any key nextkey
     will return the next key in the database.  The following code will
     traverse the data base:

          for (key = firstkey(); key.dptr != NULL; key = nextkey(key))


DIAGNOSTICS
     All functions that return an int indicate errors with negative values.  A
     zero return indicates ok.  Routines that return a datum indicate errors
     with a null (0) dptr.

     Some error conditions will set errno. These are:  ENOMEM: runtime memory
     allocation failed; EPERM: file permissions don't match the process
     euid/egid permissions; EINVAL: key+data sizes for dbm_store exceed the
     internal block size; EFBIG: hash table overflow would cause the maximum
     dbm file size to be exceeded.


SEE ALSO
     ndbm(3B) and Berkeley db: dbopen(3)

BUGS
     Dptr pointers returned by these subroutines point into static storage
     that is changed by subsequent calls.

     dbm databases may not be portable across machines with different
     alignment restrictions or different byte sexes.

     Dptr pointers returned by these subroutines point into possibly non word
     aligned storage. You cannot assume that you can cast the Dptr pointer
     into an arbitrary data type and dereference it.  This is a general rule
     in ANSI-C rather than dbm specific, but users often hit it while using
     dbm.


     The sum of the sizes of a key/content pair must not exceed the internal
     block size minus the dbm small book-keeping overhead (currently _PBLKSIZ
     - 6 = 1018 bytes).  Moreover all key/content pairs that hash together
     must fit on a single block.  For a dbm-like implementation with much less
     size limitations, check out dbopen(3) (Berkeley DB).

     Store will return an error in the event that a disk block fills with
     inseparable data.

     Delete does not physically reclaim file space, although it does make it
     available for reuse.

     The order of keys presented by firstkey and nextkey depends on a hashing
     function, not on anything interesting.


                                                                        Page 3