July 7, 1988 Dick Roberts Enclosed in this .ARK are 4 code segments from: EMX-313.MAC Simon Ewins - author HBBS.Z80 Irv Hoff - editor PBBS41.MAC Ian Cottrell - editor PBBS402B.MAC Dick Roberts - editor The HISTORY: ------------ EMX is the "grand-daddy" of the other three, so, I enclosed that code just so everyone could see what the "original source" looked like. HBBS was an off-shoot of PBBS2.9 and you can see that the "USER BUG" is still in that segment. In the EMX era, users were stored sequentially in the USERS file i.e., the first User (Sysop?) to call the system occupied record #0. The se- cond user went into record #1 and when MAXU was reached the "Please call back tomorrow" message was displayed. Russ Pencin improved upon this scenario by introducing the HASH algo- rithm. Based on a table consisting of even multiples of 100 records, each letter of the alphabet was given an "allotment" of sequential re- cords. In the current PBBSHDR.MAC file, "A" has 3 slots, "B" has 11, "C" has 8, etc... What that means is when an user who's last name begins with "C" calls in, instead of starting at record #0 and reading seqent- ially through the file as EMX would have, PBBS and HBBS call the HASH algorithm first, which sets the starting record # to the beginning of the "C"'s. Since the "A"'s are allotted records 0, 1, and 2, and the "B"'s have 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, and 13, the first "C" exists at record #14 and the sequential search begins there. The speed improvement is _very_ noticable! The PROBLEM: ------------ The USERS BUG we are addressing in this FIX refers to ACTIVE users being _overlaid_ by NEW users. Also, a new user whose last name begins with "A" will put a HBBS or PBBS system with no VIRGIN records i.e., records that have _never_ been touched by an ACTIVE User) into an endless loop. Scary situation, eh? How was this catastrophe allowed to happen? Well, it appears that when the HASH algorithm was added, a check of the (AVAILF) flag was also inserted. If (AVAILF) contains ZERO, it was as- sumed we had a FREE record. As long as the USERS file contains VIRGIN records, RDUSRS: will find an (AVAILF) equal to ZERO and proceed merrily on it's way to NUOK:. BUT!!! If there are _no_ VIRGIN records, (TMPREC) is still pointing at (HSHREC) so, _whoever_ is at (HSHREC), ACTIVE or DELETED is now _overlaid_ by the New User! Too bad fella... The FIX: -------- Instead of pointing (TMPREC) at (HSHREC), while we're perusing the USERS file, let's take a look into (ACESSF). When (ACESSF) contains ZERO, we have found a DELETED user. Better to overlay a DELETED user than an ACTIVE one, eh? Also, since we're starting our sequential search at (HSHREC) and pro- ceeding up until MAXU, let us not forget to check record #0 _before_ qw increment our pointer in the NXTREC: loop, or we might be "looping for- ever", especially if we're looking for an "A" slot... HP-USERS.FIX will correct the problem both in HBBS-1 and PBBS41. P.S. If you're concerned about having users sitting at x00 i.e., users 0 - 300 in a MAXU 300 system), just change the single occurence of MAXU in HP-USERS.FIX to MAXU-1, and you'll now be limited to users 0 - 299. ------------------------------------------------------------------------ The EPILOGUE: ------------- I do hope _someone_ enjoyed reading this file. I ask that this .ARK be distributed intact and, that if anyone has trouble implementing this fix, would they please phone: The Holly Park RCP/M (201) 757-1491 2400 baud, 24 hours, and still PC-Pursuit... ------------------------------------------------------------------------ I plan on this being the first of *many* FIXES and HACKS for PBBS/HBBS to emanate from the Holly Park RCP/M, so, if you found it useful, please stop by and let us know. Thanks... - Dick Roberts