Date : Sat, 15 Mar 1986 09:58:00 MST
From : Keith Petersen <W8SDZ@SIMTEL20.ARPA>
Subject: PBBS Remote Bulletin Board now available from SIMTEL20
Now available from SIMTEL20:
Filename Type Bytes CRC
Directory PD:<CPM.RCPM>
PBBS01.LBR.1 BINARY 199552 CFA6H
PBBS is small and fast! It consumes less than 18 kilobytes of memory.
PBBS is written in Z-80 assembler and requires M-80 and L-80 to
assemble and link it. PBBS is a full featured remote bulletin board
system that offers all of the user tracking features of E-MX, all of
the features of RBBS, and several additional features unique to PBBS.
The users file size is set at install time and does not grow for the
life of the system. The user file is indexed using a simple hash
algolrythm based on the users last name. This allows very rapid user
look-up at signon and for message entry. On a system allowing 300
users the users file stays at 30k... the messages file will grow
dynamically as messages are entered, however, since the messages are
stored in a packed format, this file will grow much slower than the
same file would in RBBS. All menus, bulletins, welcome, and news files
are standard ASCII text files, created with any good editor.
PBBS provides the following features:
Extensive 8 level user profile
Totally menu driven single character commands
Up to 25 NEWS files
A WELCOME message
A BULLETIN message
Built-in WHATSNEW and WHATSFOR display
CHAT with settable access times
FEEDBACK to sysop
Public and Private Message system
Automatic mail waiting lookup at login
Highest message read counter
User lookup based on last name
List of last 20 logins with date and time
Automatic User/Message file maintenance
Optional CP/M access restriction
Optional CP/M knowledge question
Automatic file run on entry to CP/M
BYE33X and BYE504 bdos interface
Automatic support file creation
The .com files themselves total 46k on a system with a 1k allocation
block size and 50k on a system with a 2k block size.
PBBS is self-maintaining in the sense that the users and messages file
are 'mapped' such that on the first "loss-of-carrier" call after
midnight each day, PBBS automatically scans the USER file and deletes
users that have been inactive for a for a period of time defined by
their access level. PBBS then scans the message base and deletes all
messages to these deleted users. After the first loss-of-carrier after
midnight each day PBBS runs a short update of files such that any old
users and messages are deleted. This function is done off-line, that
is, it will only occur on the first "loss-of carrier" after
midnight, and disables the modem during the time of update. Thus the
user is not burdened with waiting for the system to do it's
maintenance. After completion, PBBS returns to a wait for next call
state. The space created is then available as mentioned above. The
number of days since the last signon is used as the determining factor
in the daily update of the users file... this number of days is
determined from a table of attributes attached to each of 8 active
user levels (level 0 is used to indicate a deleted user, level 1
indicates a banned user). Banned users and any users with a
'days-to-deletion' value of 0 are not deleted from the database during
the update routine. The exact day values and other related security
information for each access level are stored in a table that you set
up using the PBBSHDR file. Level 9 is reserved for the sysop. This
system is ideal for use with a modified version of LOCK that checks a
byte in high memory for a match to a preset value imbedded in the
'locked' .com file. PBBS allows such a byte-location in high memory to
be specified and then places the access level of the current user into
that byte. When a .com file is run that has a value of 9 imbedded in
it by PROT then the file is for all intents and purposes non-existant
if the current user is not the sysop, with an access level of 9. An
ascii equivalent of the access level can also stored in high memory
for the sake of compatability with any existing RBBS files that may
need it.
The MESSAGES update deletes any old messages that are to a user that
just got deleted. The public messages must be deleted manually by the
sysop while in the PBBSMNT routine. The access level of a user is set
to 2 initially but it is auto-incremented on the next call on a new
date up to a level of 5..... for access greater than 5 the sysop must
manually upgrade the user by using the PBBSMNT file. The auto-bump of
the access level only occurs if the call is NOT on the same day as the
previous call. PBBSMNT stores the date and time of a user file or
messages file acces in the index file and tells you what the last
date/time of the last update was.
PBBS implements the BYE33X and BYE504 bdos interface, and as such, is
almost totally hardware independant. If you can install BYE33X or
BYE504 for your system, you can run PBBS with no need for special
inserts or overlays. The only customization required is performed in
one header file that is automatically included in each of the
operating programs of PBBS at assembly time. The PBBS maintenance
file uses the same real time clock insert as your BYE program to allow
it's use independant of BYE.
PBBS is also available via modem from the Dallas Connection RCP/M
(214) 238-1016 (300/1200/2400).
--Keith