CBBS34.DOC 6/18/80
N-O-T-E to previous CBBS implementors wishing to upgrade to
version 3.4: You need only add a fourth line to the file "NEXT"
which contains a 5 digit, maximum number of active messages.
Note that this is character-string compared with the number in
the third line, which is the current number of active messages.
(I.E. don't put 00320 in line 5, put in (space) (space) 320. As
long as you are running a version of CBBS which does not do the
message packing, this SHOULD be the only change required. Let
me know if it isn't.
Since going to the version of CBBS which did not re-number
and pack the messages, CBBS has had a problem with the time it
took to kill a message. That has now been solved with CBBS
3.4.
The primary cause of the slow speed of "K" was that the
entire summary was passed thru memory, to "WORKFILE", deleting
the single message summary being killed. This is similar to
the overhead of doing an edit to a file, except that the
"editor" (CBBS) is resident.
I had been looking for a long time for a simple way to
speed up the kill. It appeared that fancy linked-lists, or
some other technique was required, but that went against the
grain of the idea of CBBS files: that they all be simple,
sequential ASCII files so you may readily use existing
utilities on them, such as editors, etc.
The solution was to only "flag" the summary as having
deleted a message, but to otherwise fully process it. Many
people had suggested this technique, perhaps with a file or
table of killed message numbers to look at first. But I didn't
want to add that level of complexity to CBBS.
Now, when a message is killed, the message file is
processed, with the message being physically deleted and
written to "KILLED" (a history file of messages); The "NEXT"
file is processed to update the # of active messages; then the
summary is flagged. How? First some background:
Some time ago, I made the "Q" and "S" search commands do a
binary search for the message. However, I didn't go past one
extent (16K) because of the complexity. For CBBS 3.4, I did
change the summary scan routine to do a full binary search of
the summary, assuming (as I recall) that the summary wasn't
more than 2 extents long.
I also made the binary search routine a subroutine.
Therefore, it could be called from both the summary routines,
and the kill routine. So, to "flag" a message in the summary
as killed, I just do a binary search for the number, then read
ahead for the first digit of the # of lines in the message, and
overwrite an "X" to it. I then write the sector back in place,
unless the "X" occurred in the last byte of the sector, in
which case "WRBYTE" already wrote it back.
The routine which processes the entire summary file thru
memory is no longer automatically run by "K" (therefore the
time saving). So periodically, the system operators must run
the new operator command "PURGE" which will pass the summary
thru memory, deleting all "X"ed messages. The summaries of the
deleted messages are shown, as is the total number of messages
deleted. You need only ensure that the free space on the disk
never goes below the length of the summary file, since the
temporary file created by PURGE is nearly as long as the
summary. (See next paragraph).
Additional enhancements in 3.4: You now set the maximim
number of messages entered by any one caller, the number of
comment lines entered, and most importantly, the maximum number
of active messages in the system. This was implemented because
of the need for the workfile to delete messages and to PURGE
the summary file. If the disk gets full so that K or PURGE
won't work, you have to PIP over message files to another disk
until there is space, then K or PURGE, then eventually PIP the
messages back. Now, by limiting the maximum number of active
messages, CBBS will simply not accept any more at this point.
NOTE this is not a test of how full the disk is, since message
length is not taken into account.
At CBBS/Chicago, running two 8" drives, we typically run
with 25-35K free on the message disk, and have 320 as our
number of active messages.
----------------
Ideas for the future:
Randy is interested in adding some functions, particularly
for you implementers of CBBS. For example, a special password
which would allow CBBS operators to exchange implementation
ideas, problems, solutions, and for us to leave new
modifications online.
In general, we would like to enhance the function of CBBS,
perhaps going to an overlay scheme to handle a wider variety of
functions, without CBBS.COM getting unwieldy.
Some operators, notably Lewis Moseley of CBBS/Atlanta, have
split all the user-specific functions out of the main menu, and
put them into a separate "U" function menu. These include the
Case, Duplex, Null, Prompt bell, Video backspace, and eXpert
user functions. The reason is to make the main menu less
crowded.
I, too have been thinking of this and soliciting comments.
The comments are sufficiently varied that there is no clear cut
solution. Some thing dual menus to be more confusing than a
single menu. Others say don't have another menu, but go to two
byte commands, such as MD for "Mode Duplex", and MX for "Mode
eXpert". A nice idea, too. "The jury is still out" on this
one.
Some have suggested deleting the "V" function, and just
echoing characters if DEL is used, and echoing backspaces if
control-H is used. Randy vetoed that for good reason: He has
a video terminal with a handy-to-use backspace key, which
generates a DEL, but he wants the cursor to back up. I see no
problem with "V" remaining.
----------------
Here is a list of the changes since release 3.2 of CBBS, by
file:
CBBS.ASM: Modified the documentaion on the contents of file
"NEXT". Added following equates:
ECOUNT: number of messags any one caller may enter.
CCOUNT: number of comment lines any one caller may
enter.
Added "TEST" equate to generate a system which doesn't
look at the sense switch, defaults all files to the "logged in
drive", and JMPs to 0 when you use the "G" command. Used to
create "CBBSTEST.COM" whicn is to allow you to become familiar
with CBBS on your own machine.
CBBSBYE.ASM:
Code to limit the number of comment lines.
CBBSDISK.ASM:
Add label "SETOPEN" which just opens FCB; Also add
usage of "UNRDBYT" to replace earlier code which dinked with
the pointer to the disk read buffer; Also modify routine
"EXTEND" to efficiently handle multiple extents. The eariler
version only went to the end of the file if it was in the first
extent. This routine keeps opening extents if necessary to
find the end.
CBBSENT1.ASM:
Modifications to limit the number of active messages
allowed in the system, and the maximum number entered by any
one caller.
CBBSFUNC.ASM:
Added label "DEFUNCT" which kills stacked lines. Then
modified several places in many other modules, which did a STA
of a CR into INBUF to kill the stacked lines. They now just
JMP to DEFUNCT. N-O-T-E you don't have to change any of your
old routines. This is a new, but compatible way to kill
stacked lines.
CBBSKILL.ASM:
MAJOR REWRITE to just flag summaries as killed. Add
"PURGE" routine for operators to clean up the summary file of
flagged messages.
CBBSOPER.ASM:
Add PURGE to the command table.
CBBSSUB1.ASM
Put in "DCX H" to back up buffer pointer when the
buffer is filled. At label RDFULL.
Also fix bad JMP in RDLINE (Thanks to Lewis Moseley for
finding this)
CBBSSUB2.ASM:
Add moving "CCOUNT" to "CLEFT" and moving "ECOUNT" to
"ELEFT", in the REINIT routine.
Put in test to not jump to PROM if "TEST" mode is true.
CBBSSUB3.ASM:
Added missing "INX H" in the flush test. (Did not
properly test if running under FAST).
CBBSSUMM.ASM:
Enhance the binary search to handle two extents, and
split it out as a subroutine so it may be used to search the
summary on a "flag" kill. Also split out "SUMCOMP" to scan
from current summary position, to match the contents of
"MSGNO". Also modified the summary print to ignore "flagged"
summaries.
CBBSWORK.ASM:
Add ELEFT, CLEFT; and other minor documentation. Add
"NPURG" (# PURGED).
Add "TEST" equate to allow assembling a system which
may be run as is, with no modem, for you to try out
when you receive CBBS.