Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!ames!sdcsvax!allyn
From: allyn@sdcsvax.UCSD.EDU (Allyn Fratkin)
Newsgroups: comp.bugs.4bsd
Subject: Re: 4.3BSD ndbm(3) key/content length restriction
Message-ID: <3231@sdcsvax.UCSD.EDU>
Date: Wed, 27-May-87 12:02:11 EDT
Article-I.D.: sdcsvax.3231
Posted: Wed May 27 12:02:11 1987
Date-Received: Fri, 29-May-87 06:34:45 EDT
References: <1739@megaron.arizona.edu>
Organization: U.C. San Diego
Lines: 20

In article <1739@megaron.arizona.edu>, whm@arizona.edu (Bill Mitchell) writes:
> However, it appears that the actual limit is 1024, rising from #define
> PBLKSIZ 1024 in <ndbm.h>.  We found that changing PBLKSIZ to 4096 seems
> to work just fine, but it's not clear what's in error, the man page or the
> code.

Some time ago, I was looking at the code for ndbm, and I concluded that
somehow the values for the defines of DBLKSIZE and PBLKSIZE are reversed.  
It makes little sense (to me) to have DBLKSIZE be so large since most 
databases don't get that big.  Flame me if I'm wrong (somebody will), but 
isn't the .dir file basically a bitmap (used in the hash calculation)
of the available file pages?  How many people regularly have databases that 
are 4096 pages long?

Incidentally, I ported the ndbm package to an IBM PC running PC/IX and I 
changed the PBLKSIZE to 3072 and the DBLKSIZE to 512.  It works fine.
-- 
 From the virtual mind of Allyn Fratkin            allyn@sdcsvax.ucsd.edu    or
                          EMU Project              {ucbvax, decvax, ihnp4}
                          U.C. San Diego                         !sdcsvax!allyn