SNOBOL4NDBM(3) | CSNOBOL4B 2.0 | January 1, 2015


snobol4ndbm – SNOBOL4 NDBM interface


-INCLUDE 'ndbm.sno'
        dbhandle = DBM_OPEN(file,flags,mode)
        datum = DBM_FETCH(dbhandle,key)
        key = DBM_FIRSTKEY(dbhandle)
        key = DBM_NEXTKEY(dbhandle)


"NDBM" (for New Data Base Management) is an industry standard fast hashed storage API first created in 4.3BSD, and included in the Unix 98 (SUSv2) standard. The original DBM API appeared in AT&T Research Unix Version 7, and only allowed access to a single file at a time.

There are many different implementations of this API, including:


NDBM, GDBM, and SDBM create two files: filename.dir and filename.pag. Berkeley DB creates a single filename.db file.


snobol4sqlite3dbm(3), ndbm(3), dbopen(3), gdbm(3).


Philip L. Budne


Not safe for concurrent read and write. The snobol4sqlite3dbm(3) interface achieves this portably using snobol4sqlite3(3).

Some implementations (classic NDBM and SDBM) place limits on the total size of key plus datum (typically slightly less than 1KB).

NOTE: Some implementations (classic NDBM and SDBM) create sparse files which appear (to "ls -l") to be larger than they are (see "ls -s"). Copying such files may cause the non-allocated blocks to be "filled" with zeroed disk blocks, and then the files really will be large!

Only GDBM provides locking to eliminate the possibility of file corruption, or reading of incomplete data.

GDBM locking sometimes fails on NFS mounted partitions but does not provide a way to disable locking.

DBM databases accessed concurrently by multiple processes are traditionally (re)created from text files and used for fast disk-based read-only table lookups. Programs which need to update the file generate a new temporary copy using a different name, and then rename the new file(s), so that the next reader gets the new copies (existing readers continue to see old data).