Software Release Note for ISOC version 25.1

(click here for SRN history)

Author: M. Bindels [m.bindels@sciops.esa.int]
Date: 10-06-2010
Summary: AO8 post-TAC Release

Dependencies

System name ID Version
ISOC Core System (PHS, OSS and CSS) core 15.3 (new)
ISOC Database DB 9.4
ISOC FD Server application fdserver 3.1 (new)
ISOC Web web 7.6
Proposal Generation Tool PGT 8.0
Proposal Receiver PRV 8.0
Proposal Loader PLD 8.0
Mailer Daemon MLR 8.0
Push Pull Daemon PPD 3.1
ISOC Observing Time Estimator ote 8.1
ISOC Target Visibility Predictor TVP 5.0

External dependencies:

System name ID Version
Integral File Transfer System IFTS 2.0
Flight Dynamics Software FDS 2008.2i
Database of Observable Bins DBOB 118
Optical Monitoring Camera Pointing Software OMC 3.7
OMC Source Catalogue OMC_CAT 5
ED Viewer IODB IODB_3.1_063_23_04_10

Fixed SPRs in core v15.3:

SPR 1120 The solution for SCR1111 solved the problems in this issue as well.
SPR 1153 The addressing of scheduling notification emails has been improved: for proposals that have a mailing list (generally containing the subscribing PIs' email addresses), the message is address to the list only -assuming the proposal's PI is in the list too-.

Implemented SCRs in core v15.3:

PHS:

SCR 1099 PHS allows to see the associations of a subscription without using previously the "Edit" button, by enabling the "Associations" button by default.
SCR 1168 As of AO8, open time proposals are automatically linked to a generated data rights subscription for the PI. The following PHS behaviour regarding these auto-subscriptions has been added: when the open time proposal is rejected, the auto-subscription is rejected as well.

OSS:

SCR 1111 Switching active JEMX from OSS has been improved such that only proposals that are still eligible for scheduling are considered. This means that proposed Key Programme proposals (prior to AO7) and amalgamation children whose parent has been scheduled no longer show up as effected observations.

Implemented SCRs in fdserver v3.1:

SCR 0001166 The contents of the sky map cache is stored in the file system and read back after a restart, thus no longer requiring -long- recomputation of these maps. The cache is stored automatically every hour and when the server is stopped. The file is written to the systems temporary directory (/var/tmp on Solaris). It's a zip containing pseudo XML representation of the sky maps. To allow multiple instances on the same computer storing separate files, the file name contains the RMI port number to keep them separate indeed. A starting server will detect existing stored caches and select the most recent file to read and populate the cache with. Handling large files (10M for 1000 sky maps) is slow on Solaris. A starting server may need 2 minutes or so to read the cache and twice that amount of time to write it (be aware of this when stopping and re-starting!).