USE CASE SP

There are a few layers of infomation which needs to taken care of in the
case of simu production:

1. Manage user requests:
        a. gather information on requests from users - decay file,
filters, generators, events, user, awg, priority
        b. request can come from anywhere at any time, uses a web
interface to database.
        c. Simu production manager can control requests, accept or reject,
set priorities, reset events. 

2. Define production runs:
        a. accepted requests are then broken up into production runs: 
run number,decay files, filters, generators, events per run,
conditions alias defined, background used.
        b. Blocks of runs can encompass multiple requests, automatically
setting run numbers.
        c. A location for a block of runs can be define - site. 

3. Build runs at site:
        a. defined runs need to built at sites: information taken from
database by run number using a database proxy scheme.
        b. Once runs are built and running state of runs updated in
database - again updates to database using proxy scheme from any site. 

4. Manage import of runs:
        a. Database produced are imported to SLAC, info about event
databases is put into database - actually not me right now, Tofigh and Adil
probably know more.
        b. Working dir's and log files are tar'ed into 100MB archives, and
imported to SLAC - tar'ed dir are parsed for information, final info on
runs are put into database - run state, events done, where done, computer
done on, who did it, times, background offsets used, um, some other stuff.

5. Relay information on runs and jobs to users:
        a. web interface with searches on run numbers to see state.
        b. web catalog of blocks of runs listed by decay files used.
        c. bfreport as a command line util to access data in database,
select using run number, decay mode, run state, and other options.

I think that about covers use needs in general, with most specific info
listed. The general tech. used:

 - All information in one and only one database for the whole world wide
system.
 - Access to database is only needed when data is being tranfered.  
Request made, job defined, job built at site, at import time, get date to
users.  No access is needed while jobs are running.
 - Local sites do not need database, local run time infomation only needs
file system access.  Use of status files for each run.

I think this covers it for now.  There should be more notes about
limitations and the relative sizes of tables.  I will get that together
later.
===============================================================================