Source: SPITFIRE.DOCEdition: searchable Web reading editionPresentation: historical wording retained
14.0 - EVENTS MENU EXAMPLE
--------------------------
It is possible for a Sysop to execute specific programs
automatically by setting these programs up as a scheduled event
using SPITFIRE's Events Menu.
>>>>>>>> EVENTS MENU <<<<<<<<<L>............ List An Event <E>.......... Enable An Event
<D>......... Disable An Event <Q>..................... Quit
<+>............... Next Event <->........... Previous Event
EVENTS MENU - [L E D Q + -]?
14.1 - EVENTS MENU EXPLANATION
------------------------------
<L>.... List An Event
SPITFIRE supports 13 events <A..M>. Sysops who select
this feature are asked which event <A..M> they wish to
view. If the event selected is not configured,
SPITFIRE states that this event is not active. If the
event selected is configured, then SPITFIRE displays
the time of the event, the day of the event, whether
the event is active and whether it has been completed
that day.
<E>.... Enable An Event
This feature is used to activate one of the 13 scheduled
events available. Sysops who select this feature are
asked which event they wish to enable. If they select
one that is already active, SPITFIRE notifies them that
the event selected is already active and they are asked
whether they wish to change it. If the designated
event is not active, Sysops are prompted to enter the
time the event is to be activated (expressed in 24 hour
format. Example: 22:00 = 10pm). Next they are asked on
what day the event should be scheduled to take place.
The format looks like this:
0=Sunday, 1=Monday, 2=Tuesday, etc....7=All!
Sysops are then prompted as to whether the event should
be marked as having been completed for the day. If they
reply with N for No, and the event is configured to be
executed at a time earlier than when it is created, the
event is executed upon exiting the Events Menu. If they
reply with N for No, and the event is configured to be
executed at a time later than when it is created, it is
executed at the next scheduled time. If they reply with
Y, for Yes, the event is not executed until the next
designated scheduled time after the day it is created.
Finally, Sysops are prompted as to whether the event should
be marked as an on-time event. For additional information
regarding on-time events, refer to the following section,
Important Note Regarding Scheduled Events of this manual.
After having selected the desired scheduled event and
establishing the time and day the event is to be performed,
Sysops need to modify the SF.BAT file with their favorite
text editor. For illustration purposes, let's assume Sysops
wish to execute Buffalo Creek Software's SFLOG to create a
bulletin of the weekly activity on their BBS. The SFLOG
utility requires Sysops to specify the bulletin file name
that the information will be written to by adding a
"/BULLET<x>" parameter to the command line. Our example
will use the file BULLET1. To simplify this explanation,
assume all files are being run from the default directories,
and the event will be event A.
The Sysop will need to select <E>.... Enable An Event from
the Sysop Utilities Menu and then choose A as the event to
be created. They are then prompted for the time the event
will be performed. Let's assume a time of 01:00. Next, the
Sysop is prompted for the day the event will be performed.
Let's assume they wish to run the event every Sunday, so 0
is entered. When prompted whether to mark the event as
being completed today, type Y. Finally, Sysops are prompted
as to whether the event should be an on-time event and N is
entered.
The SF.BAT file for Event A will look like this:
:EVENT_A
REM Place Event Commands Here
GOTO LOOP
What is required next is to include all necessary DOS
commands which are needed to run the SFLOG program and
enter those in place of the "REM Place Event Commands Here".
A completed SF.BAT for Event A appears as:
:EVENT_A
CD\SF\WORK
SFLOG /BULLET1
COPY BULLET1.* \SF\DISPLAY
ERASE BULLET1.*
CD\SF
GOTO LOOP
With the event set up as described, every Sunday morning
at 1:00 am (or immediately after a caller logs off since it
has not been marked as an on-time event), SFLOG creates a
bulletin of the BBS weekly activity. SFLOG must be located
in the same directory as the CALLERS.LOG (WORK). Therefore,
the batch begins by changing to that directory. SFLOG is
then executed and the BULLET1.BBS/CLR display files are
created. Next, the bulletins are copied to the DISPLAY file
directory and to conserve disk space, the BULLET1.BBS/CLR
files in the WORK directory are deleted.
<D>.... Disable An Event
This feature is used to disable an event that has been
previously configured. If the event is currently active,
SPITFIRE asks the Sysop whether they are certain they want
to disable it. Responding with "Yes" disables the scheduled
event.
<Q>.... Quit
This feature takes the caller from the Events Menu and
returns them to where SPITFIRE was prior to calling up
the Events Menu, either the "SPITFIRE ready..." prompt
or the Sysop Utilities Menu.
<+>.... Next Event
This option is used to move forward from one Event to
another. Pressing the "+" key progresses from one
event to the next in alphabetical order. When the last
event is reached (Event M) and the "+" key is pressed
SPITFIRE cycles to the first event, Event A.
<->.... Previous Area
This option enables Sysops to cycle through the Events in
reverse order. Pressing the "-" key moves to the
preceding event. From Event A, if the "-" key is pressed
SPITFIRE will cycle to Event M, the last event.
IMPORTANT NOTE REGARDING SCHEDULED EVENTS!
------------------------------------------
SPITFIRE has the capability of marking an event as an "on-time"
event, which causes the event to be executed at the exact time for
which it has been set up. If an event is marked as an on-time event,
when a caller logs onto the BBS, SPITFIRE checks their time against
any on-time event that has not yet been completed for that day. If the
event is scheduled to run during the time the caller has remaining,
then SPITFIRE reduces the amount of the caller has on the BBS by that
amount. For example, if a caller is allowed 60 minutes when logging
onto the BBS, and SPITFIRE checks for an on-time event and determines
an on-time event is to be executed in 25 minutes, the time the caller
is allowed on the BBS for the current call is reduced to 25 minutes.
**NOTE** Even though an event is marked as an on-time event, it
is possible that a caller could gain additional time on the BBS
preventing the event from being executed on-time. For example, the
BBS could be configured to allow additional time for file uploads
(i.e. 2 to 1 time compensation for uploads) or offer time bank
programs where the caller can withdraw stored online time.
Marking an event as on-time event might be necessary for running
programs that require a specific time to be executed. Such an
instance might be importing daily net-mail packets where Sysops are
given a designated amount of time for connecting with their net-mail
hub. Usually configuring an event to activate "on-time" is not
necessary.
When an event is not marked as an on-time event, unlike most
other Bulletin Board Systems, if a caller is on-line when an event is
scheduled to occur, SPITFIRE waits until the caller logs off and then
performs the scheduled event. In this fashion, the caller is not
interrupted or subjected to a forced log-off.
Please note that Event M is reserved for use to Pack the Message
Base. At the scheduled time you designate, SPITFIRE initiates Event M
to pack the message base by purging all messages marked for deletion.
In addition to messages marked for deletion, messages are purged based
on how the Sysop has configured the Message Conference Record. The
options which determine which messages will be purged include Purge
Msgs Older Than, Purge Unreceived Msg, and Purge Old Thread Msg. Purge
criteria is configured individually for each Message Conference that is
available on the BBS. Refer to the section - CONFIGURING MESSAGE
CONFERENCE RECORDS for more information regarding these options.
Immediately after completing the scheduled event M, SPITFIRE
looks for SFMSGPCK.BAT in the work file directory. If it exists,
SPITFIRE shells to and executes the commands within the SFMSGPCK.BAT.
This batch is intended to perform duties required by some net-mail
utility drivers. If SFMSGPCK.BAT is not found or once it has been
completed, SPITFIRE returns to the "Ready..." prompt. Packing the
message base should be done routinely to conserve disk space.