SPR 696 Report
Mathijs Homminga

Fixed in isoc-core branch v11.1_br and on the main trunk.

=== Finding and fixing the cause of the problem
  
In nl.esa.estec.isoc.oss.db.ObsDataModule.java, line 574:
When an observation is completely unscheduled, its status changes from 'S' to
'A'.
In this piece of code:
- the values are restored, which is OK
- there is a check to see if this observation already uses the wandering COP.
  If it doesn't, it is set to 'Y' (yes, do use wandering COP) and the
corresponding
  dwelltime is recalculated.

This is where it went wrong. The code was probably inserted at the time the
wandering COP was introduced, to make sure that every newly scheduled
observation will always use the wandering COP. 
However, this should only have been applied to observations with the raster
('R') pattern, not every observation.
I checked the database and saw that indeed there are a lot of non-raster
observations which have their usewanderincop flag set to 'Y'. This is not a
problem but the recalculation of the dwell time is. 
The dwell time should never be recalculated when going from 'S' to 'A'. 
I executed the following query to see if there are still some old observations
left which can be scheduled in the future and hence need their wanderingcopflag
set to 'Y'

 select * from obs where status in ('A', 'S') and ditpattern = 'R' and
usewanderingcop = 'N';

It appeared that there were only some old calibration ('88600xx') observations
which will not be scheduled again (I sent an email to Celia to ask her to close
them).

Lars and I decided that the check for the wandering COP flag and the
recalculation of the dwelltime should be removed completely from
nl.esa.estec.isoc.oss.db.ObsDataModule. This was done. 

=== Cleaning up

I also removed the calcDwelltime method since it was only used by the removed
piece of code. And I removed the now unused DWELLTIMEQ query from
ObsDatabase.java.

I also found out that there are two different methods to calculate the
dwelltime: 
1. PL/SQL procedure in the database: f_get_dwelltime
2. Method in nl.esa.estec.isoc.phs.db.ProposalDataModule.java: calcDwellTime

Since this is not desirable, I'd like to remove the database procedure if
possible.
Previously, when I introduced the 'custom-raster' pattern I only updated the
Java code so the PL/SQL procedure is not up to date anyway (doesn't know how to
handle custom rasters: it will always use the default dwelltime). 

Non of the Java code uses the f_get_dwelltime method anymore. However the
following database packages still use it so it cannot be removed straight away:
package amalgamation / procedure use_dominant_properties
package proposal / procedure create_new 

The proposal package can be updated such that new observations will always get
the default Raster dwelltime. This is OK because the approved time is set to 0
and so the dwelltime will be recalculated after increasing the approved time.
The amalgamation package is difficult to change since the dwelltime of an
amalgamation needs to be recalculated because the approved duration may not be
the same as the approved duration of the core observation. So as long as
amalgamation is done in the database, it must be possible to recalculate the
dwelltime in the database. For now I assume that custom raster patterns will not
be used in an amalgamation core observation so I will not update the
f_get_dwelltime function. 

In short: the f_get_dwelltime function is kept and the proposal and amalgamation
packages still use it. Something for the future.