jimomura@lsuc.uucp (Jim Omura) (05/16/88)
I have too many projects going again. As such, this is one
that I'm abandonning. It should not be that hard, but I have no
time for it. Gee. Sure would be nice if somebody wrote this!
:-)
Cheers! -- Jim O.
88/05/15
A design for a Scheduling System.
Revision #1
Based on a Database of Streams.
$Stream1
* Event1
* Event2
* Event3
^Stream2*Event10^
* Event4
^Stream2*Event6^,>Stream3*Event12>
* Event5
$Stream2
* Event6
* Event7
* Event8
^Stream3*Event13,Stream4*Event14^
* Event9
* Event10
* Event11
$Stream3
* Event12
* Event13
$Stream4
*Event14
The syntax is simple. There are 6 main "transition" markers:
$ Stream marker
* Event marker
^ Requirement marker preceding
> Requirement marker concurrent
" Quote marker
' Comment
Streams and Events:
For either of the first 2 transition markers ($, *) it
is presumed that a Label follows make up of the first contiguous
set of "valid label characters" following. Valid label characters
are any alpha-numerical characters, and dot and underline.
Punctuation except for dot and underline are treated as non-printing
white space. As such, space, tabs, EOL's and are ignored, and
any of SPC, TAB, EOL, EOF and puctuation such as comma, colon or
semi-colon can terminate a Label. NULL's should be ignored in
either case and possibly, automatically removed from the file during
any update if a special file editor is created.
Anything following the Label is a modifier until another
transition marker is encountered. Syntax for modifiers vary
a bit, but fairly regularly.
Stream are limited according to the OS. For OS-9, 29
characters total. For MS-DOS, 8 characters. Event labels
are arbitrarily set at 16 characters maximum.
NOTE: Time is *not* treated particularly specially. A
Stream called $TIME might be useful. To indicate a deadline
it would be sufficient to label a specific date as requiring
the last Events in the other streams as Precedent. If you
want to get fancy, you can have a special data format for
time, so output can be specially tailored, but otherwise,
there's no need for it to be distinguished.
Modifiers:
Requirement are marked with either ^ or >. These must
be preceeded by an Event and modify the preceding event by stating
what other events must occur either before or at the same time
as the event modified. As with quotes and comments, each
set of requirements is terminated by the same mark with which
it starts.
A Comment or Quote is terminated by another comment or
quote marker. A Quote is intended to be printed as output
as it occurs until the closing quote is encountered. A backslash
(\) preceding a quote mark within a quote forces the printing
of a quote marker. A comment is for internal documentation
for the owner of the database.
Overview:
Conceptually, a Stream is made up of a number of sequential
events. If 2 events may occur at the same time, the 2nd event
should be assigned to a different stream. If not, one can be made
a Quote, but that should not be necessary and is probably bad
form.
If an impossibility arises, due to requirements of precedence
or concurrence of functions which cannot occur in that order, an
error is generated and the processor stops.
In this sample, some redundance occurs, but that's fine.
Event4 is dependent on 2 Events, both of which *must* have
already occured before it is reached. The 'hat' sign indicates
an event which must have occured before the current event.
Each event is identified by a Stream and Event number.
Output:
The output is a chart, either horizontal or vertically
formatted where key precedent or concurrent events are
specially marked and events which must occur after are so
printed.
The special transition markers should not be printed
in the default case. Neither should comments. Quotes are
printed with their labels.
Main Data Handler:
First, the datafile is read in and separated into
separate stream file. Then each stream file is read
until a requirement is reached (or EOF). Then the
events are printed until the either a requirement
label is encountered or an event that has a requirement
is encountered. If it's an event that needs another
event precedent or concurrent, that file stops printing
until the required event label is reached. If the
requirement is a precedent, then it is not printed
until after the precedent is printed. If they are
concurrent, then they are printed together, or await
any other precedent or concurrent events.
If a required label is encountered first, it is
checked whether it's precedent or concurrent with
its associated labels. If it is not required to
be concurrent with any other events (ie it is precedent
to one or more events) then it is printed immediately
and the flags for the associated events are cleared.
If it is required to be concurrent, then it is held
until the event requiring it is reached and it is
printed with it (or them as the case may be).
It is clear that each flagged event label needs
at most a structure of flags and labels equal to
the number of streams less 1.
--
Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880
ihnp4!utzoo!lsuc!jimomura
Byte Information eXchange: jimomura