1.- Pending requests:
=====================

1.1.- Request #124 (P. Lombard):
--------------------------------

--> Add new table "Swarm_Events" To Application Schema to support swarm monitoring.
------------------------------------------------------------------------
==> How is this table going to be maintained?
    Permanent storage or "scratch pad"?
    In what context is the query "expensive"?
    Wheres vs. geo_region package.
    If direct access to DB, there is the advantage of seeing any recent
    changes; for example if an event was relocated.

==> Additional information from Pete:
"The swarm monitor does not keep a record of previous events in its memory or
in local files. So each time an event happens within a monitored region, it
has to query the database to find how many other events happened in that
region within some period of time, typically the last hour or 24 hours. If the
swarm monitor had to determine whether all the events in the DB for that time
were in the region of interest, that would be expensive compared to what it
does: it queries the swarm_event table where it only has to do a string match
with the region name, and events outside of swarm regions are not present.
That's all I meant by an "expensive" query, not that there is anything wrong
with the geo_region package."
------------------------------------------------------------------------

------------------------------------------------------------------------
==> Approved.
------------------------------------------------------------------------


1.2.- Request #10 (D. Given):
-----------------------------

--> Add new column "nobs" to NETMAG table.
------------------------------------------------------------------------
==> Request has been approved but the implementation is on hold until:
     1.- NC is done migrating to the new CISN software.
     2.- SC is done migrating to the leap seconds compliant code.

==> This change has eventual implications for the following applications:
    Trimag, EC, Jiggle, MT, dbselect, Stored Procedures, STP(SC), RTMd(SC).

==> Ellen started testing the replication issues associated with adding
    a new field to an existing table. She came to the conclusion that
    during the update to the replication environment, there is a small
    time window where transactions can be lost. There does not seem
    to be a way around this issue.
------------------------------------------------------------------------

------------------------------------------------------------------------
==> Stephane came up with a possible scenario involving both the
    master and slave RT systems. In theory, no transaction should be
    lost on a master system by following this scenario.
    Ellen to look at scenario. Involve Paul later on.
------------------------------------------------------------------------


1.3.- Request #53 (D. Given):
-----------------------------

--> Add integer attribute for each channel to hold COSMOS "Table 6" value.
------------------------------------------------------------------------
==> A. Walter is currently involved in NSMP project.
    We should wait until he has more information concerning this matter.

==> A. Walter sent out a proposal. Ellen & Stephane to look at it and
    provide feedback.
------------------------------------------------------------------------

------------------------------------------------------------------------
==> Allan to send new version of the schema. Ellen & I to look at it.
------------------------------------------------------------------------


1.4.- Request #4 (B. Worden):
-----------------------------

--> Add new association table between amps and events.
-----------------------------------------------------------------
Need to associate amplitudes with events.

(The schema originally had this association, and it was removed
at Caltech's request, due to performance implications in the
real-time system when events were merged).

==> D. Neuhauser sent out a strawman for implementing sets.

Strong Ground Motion Sets.
Strawman:

1. Create a new table SGMAMPSET with fields:
	sgmampsetid 	(integer)	composite primary key
	ampid		(integer)	composite primary key

2. Add to ORIGIN table:
	sgmampsetid	(integer)

Before inserting strong ground motion info into the database for
an event, if the sgmampsetid in the ORIGIN table is NULL,
get a new counter for the sgmampsetid, and update the ORIGIN
table with is value.  When inserting strong ground motion
into the database for an event, associated with the set specified
by the sgmampsetid in the preferred origin on the event.

When a new origin is computed that "near" the previous preferred
origin, the new origin can be assigned the same sgmapampsetid
as the previous origin.  If the new origin is significantly 
different, the sgmampsetid can be left NULL to indicate that
there is no current set of strong ground motions to be 
associated with this event (really with this origin).

Programs that want to harvest strong ground motion records
for an event would only have to get all amplitudes associated
with the sgmampsetid of the preferred origin.
-----------------------------------------------------------------

-----------------------------------------------------------------
==> Ellen to send a new proposal.
-----------------------------------------------------------------