home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The World of Computer Software
/
World_Of_Computer_Software-02-385-Vol-1of3.iso
/
r
/
renumsg.zip
/
RENUMSG.DOC
< prev
next >
Wrap
Text File
|
1992-06-07
|
11KB
|
244 lines
RENUMSG
Version 1.1
Copyright (C) by Mike Woltz, 1991-92
Buffalo Creek Software
A Member Of
The Association Of Shareware Professionals
INTRODUCTION
------------
RENUMSG is a utility written by Mike Woltz, author of SPITFIRE
Bulletin Board System. RENUMSG is intended for use with SPITFIRE.
It is a utility designed to renumber the "internal numbering" of messages
within a SPITFIRE message conference.
SPITFIRE INTERNAL NUMBERING
--------------------------
To understand the necessity of the RENUMSG utility, it is best to
explain how SPITFIRE handles internal numbering of message conferences.
When a SPITFIRE BBS is started and callers begin saving messages to
a message conference, the number assigned to the message begins with
1 and progressively increases for each message saved to that conference.
And so it also with SPITFIRE's internal numbering of messages within
a conference.
However, let's assume that the message conference has grown over a
period of time to 500 messages and the Sysop decides it is time to
pack messages. Let us also assume that during the message pack,
300 messages were purged, leaving a new total of 200 messages in
the message conference. As you are aware, the next message saved
to that particular message conference will be numbered 201. But the
internal number for the new message will be 501. The internal
message number continues to increase progressively, indicating the
total messages saved to this particular conference. Therefore,
when a caller sees a message numbered 186, it may actually be
number 45,637.
Programming limitations set the maximum number for the "internal
numbering" at 2,147,483,647. After reaching the maximum number, the
internal number is wrapped around and begins again at -2,147,483,647.
So after reaching the maximum number, SPITFIRE's internal numbering of
messages virtually starts anew.
WHY RENUMSG IS NECESSARY
------------------------
Another feature of SPITFIRE is that it automatically tracks the
last message read for each caller in each message conference. When
a caller finishes reading messages in a conference, SPITFIRE compares
the message number to the previous last message read stored in
SFMSG<x>.PTR. If the number is greater than the number stored,
SPITFIRE resets the last message read pointer.
However, if the message conference has reached the maximum number
of the internal message numbering, and has wrapped around beginning
the numbering with -2,147,483,647, the caller's last message pointer
is not reset. It is not reset because the number of the last message
read is not greater than what has been stored in the SFMSG<x>.PTR
is larger than the number of the message the caller has just
finished reading.
For example, the message pointer file has message number 2,147,483,620
stored as the caller's last message read. When the caller next logs
on the BBS, assume that enough messages have been saved to that
particular conference that it has wrapped around so that the internal
numbering of messages is now set at -2,147,483,547. The caller reads
through the entire message conference. When the caller leaves the message
conference, SPITFIRE compares -2,147,483,547 to the previous number,
2,147,483,620 and does not reset the message pointer because -2,147,483,547
is not larger than the previous last message read number.
HOW RENUMSG WORKS
-----------------
When RENUMSG is executed, it performs a test on the designated
message conference (see USAGE below) to see if the last internal
message number is within 20,000 of the maximum number allowed. If
it is, then, RENUMSG will renumber the messages within the conference,
resetting each caller's message pointers.
If the message conference is not yet within 20,000 messages of the
maximum, RENUMSG will continue comparing each message number to the
number of the previous message. If RENUMSG finds that the number
of the current message is not greater than the number of the previous
message, RENUMSG will display the following:
A message numbering problem has been found
starting with message number <x>!
Please stand by...repair work underway!
and RENUMSG will start renumbering the messages within that conference
from that point forward.
This could happen if you are using a message base utility, such as
some net-mail programs and/or utilities which do not support SPITFIRE's
internal numbering of messages.
RENUMSG will only renumber messages if it finds the message numbering
is not consecutive or if the number is within 20,000 of the maximum
number allowed. If RENUMSG does not find renumbering the messages
necessary, the following message is displayed:
Message conference #<x> tested fine!
where <x> indicates the number of the message conference tested.
If renumbering is required, when renumbering is completed, the
following message is displayed:
Repair work complete!
It should be mentioned that if renumbering is required, RENUMSG
does not maintain message threads. The messages will be intact
but they will not longer be connected to a thread.
USAGE
-----
RENUMSG must be executed from SPITFIRE's home directory. It must find
SFNODE.DAT or it will not execute.
Two options are available for executing RENUMSG. The first option
is to specify which conference you wish RENUMSG to renumber and the
second allows all message conferences to be renumbered.
To specify a particular conference when using RENUMSG, simply use a
command line parameter which designates the number of the message
conference that RENUMSG will process. For example:
RENUMSG 10
would initiate RENUMSG to test, and if necessary, renumber message
conference number 10.
To use RENUMSG to process all SPITFIRE Message Conferences, simply
use /ALL as the command line parameter. For example,
RENUMSG /ALL
In the event you attempt to run RENUMSG without specifying the
desired command line parameter, examples depicting proper usage of
RENUMSG will be displayed.
DETERMINING IF RENUMSG IS NEEDED
--------------------------------
The easiest way to determine if you need to run the RENUMSG utility
is if you are experiencing problems with the last message read pointer
not being reset properly. This is a good indication that a message
conference has reached the maximum number and wrapped around.
Keep in mind, that SPITFIRE does not reset pointers for Sysops who
are using the <P>review Messages option. SPITFIRE will also not reset
the last message read pointer if a caller exits the message conference
after reading a message that appears before their last message read
pointer. In other words, if a caller's last message read pointer is
100 and reads to message 150 and then returns to message 50 before
exiting the message conference, the last message read pointer is not
reset.
POSSIBLE ERRORS RUNNING RENUMSG
-------------------------------
If RENUMSG is executed outside the SPITFIRE home directory and
SFNODE.DAT is not found a message will display explaining that
RENUMSG needs to be moved to the SPITFIRE home directory. If
RENUMSG is executed without specifying the message conference
to be processed, a message will display giving the proper usage of
RENUMSG. If you attempt to run RENUMSG and specify a message
conference that does not exist, RENUMSG will display a message
informing you that it could not find the SFMSG<x>.PTR you specified.
A similar message will be displayed if an error occurs while
RENUMSG is attempting the read or write to the SFMSG<x>.PTR
associated with the message conference you specified. When an
error occurs, RENUMSG returns an errorlevel of 1 to DOS.
RENUMSG AS AN EVENT
-------------------
Since RENUMSG will only renumber the message conference if it finds
renumbering necessary, a good way to maintain your message conferences
would be to use RENUMSG as an event. RENUMSG could be run as a daily
or weekly event within SPITFIRE so message conferences are maintained
automatically. Refer to your SPITFIRE manual for information on
setting up an event within SPITFIRE.
RENUMSG ON A MULTI-NODE SYSTEM
------------------------------
RENUMSG is fully compatible for operation on a multi-node BBS.
It automatically handles any file locking and file sharing
required during its execution.
DISTRIBUTION
------------
RENUMSG is distributed under the shareware concept. You are
free to distribute the RENUMSG program as long as it remains
unmodified and no fee is charged. If you continue to use this
program after an adequate evaluation period a fee is required.
A $1.00 fee is required of register RENUMSG. Please mail your
registration to:
Buffalo Creek Software
Attention: Mike Woltz
913 - 39th Street
West Des Moines, Iowa 50265
DISCLAIMER
----------
Mike Woltz and/or Buffalo Creek Software shall in no way be
held responsible for any damage incurred while operating RENUMSG.
All responsibility lies with the user of the software.
The documentation for RENUMSG is contributed by Jacque
Shipley and The Mother Board BBS. The shareware version of
SPITFIRE and other SPITFIRE utilities are available for download
from:
Buffalo Creek's BBS The Mother Board BBS
Mike Woltz, Sysop Jacque Shipley, Sysop
(515) 225-8496 (515) 986-3464
38400/19200/9600/2400/1200 Baud 19200/9600/2400/1200 Baud
HISTORY
-------
Version 1.0 Initial release of RENUMSG.
Version 1.1 /ALL command line parameter is added which allows
RENUMSG to process all SPITFIRE Message Conferences.