Return to release.notes CVS log

Up to [Development] / JSOC / CM / V5.1

Updated 5.1 release notes as it has been takinga long time to get this release out.

                       Release Notes JSOC V5.1         1May2009
                       -----------------------         ---------


A release is a set of files, each having a specific version.  And a release typcially
has a version number because over time you have newer and newer releases of the 
same product.  For example, a hypothetical 1.3 release may contain fileA#1.8, 
fileB#1.2, fileC#2.2 and a 1.4 release may contain fileA#2.5, fileB#2.1, fileC#2.9. 
JSOC releases are similarly versioned and contain a set of such files.  JSOC release
code is guaranteed to compile on cluster nodes (eg., n00, n02).  The resulting binaries
have been minimally tested.  At the time of the creation of the release, the
release versions of each file will be the most recent.  But as time passes, newer versions 
of some files will be made, and there is no guarantee that these changes will
not destabilize JSOC (ie., they may cause JSOC to no longer compile or execute
properly).  

There are several ways to use this release.  If you wish to simply use pre-built
binaries, you can simply use the production binaries, which are located at 
/home/production/cvs/JSOC.  Every time a release is created, the binaries in
this location get updated.  Only the production user can update these binaries.
So, you could run /home/production/cvs/JSOC/bin/linux_x86_64/show_keys, for example.
If instead you want to work with stable source files, then you must have a sandbox,
which is a local copy (in your home directory) of the files in the cvs depot.  
You would probably want to work with a sandbox if you plan on making eventual 
changes to the depot files.  Changes you make to your sandbox files are not visible 
to other users until you "commit" those changes back to the cvs depot.  Please see
"If You Don't Have a Sandbox" below for more information on how to create a sandbox.  
There is also a "working" release which resides in in /home/jsoc/cvs/JSOC.  New 
files may be placed here and existing files may be edited for common use before the 
next official release.  Each time a release gets created, the source and binaries of 
the working release get updated.  WARNING: the files you see here may not be stable 
since by the time you see them, another user may have edited them. Only the production 
release is guaranteed to be stable and unchanged between releases.

Obtaining the Release
---------------------
To update your working directory to this release, or to check-out this release anew, 
please visit http://jsoc.stanford.edu/jsocwiki/CvsInit. Please keep in mind that
users may have modified files since the release was created, so use of the 
scripts documented in the web page may result in a working directory whose
content is not identical to the release.  If updating, you can supply 
the flag "-R" to the jsoc_update.pl and jsoc_sync.pl scripts to download the
latest release.  This will ensure that your working directory has the exact, latest
release versions of the files (eg., jsoc_sync.csh -R). If checking-out, 
you can supply the argument "-r Ver_LATEST" to the "cvs checkout" command
to achieve the analogous result, but for a fresh checkout.  WARNING: if you use 
the "-R" or "-r" flags, please use only jsoc_update.pl or jsoc_sync.pl to update 
your sources thereafter.  Use of "-R" or "-r Ver_LATEST" will result in a cvs
"sticky flag" being set.  jsoc_update.pl and jsoc_sync.pl clear this sticky flag.

Additional Info
---------------
If you are unfamiliar with the use of cvs see the file:
JSOC/CM/working_with_sandbox.txt.

There's a linux4 cvs gui at xim:/usr/bin/lincvs
Also on our jsoc web page:

http://jsoc.stanford.edu/cvs/JSOC/

Use the Apache cvs gui to see the diffs. For example, go to
http://jsoc.stanford.edu/cvs/JSOC/base/drms/
and click on the name in the File column and then click on
"diffs to previous #" to see the diffs.

Changes since previous release (V4.7 - October 16, 2008)
--------------------------------------------------------

NEW FEATURES: 
* RemoteSUMS implemented, including sum_export_svc() which serves as the
server process that relays SU requests to Stanford.

* Support added for NetDRMS localization (config.local.template).

* New drms_run (C executable that handles child drms_server process better).

* More definitions, like SUMSERVER, made localizable via the config.local file.

* Performance boost - cache the user's series permission in DRMS_SeriesInfo_t so 
that there is no need to access the database every time the user's permissions 
need to be assessed.

* Performance boost - restrict the number of psql records involved in a 
group by operation when drms_open_nrecords() is called.

* Support added for value-range 'skipping'. If a value range is specified in
a query (eg., su_arta.testseries[235-634]) it is now possible to return a 
subset of records by using the '@' construct (eg., su_arta.testseries[235-634@4] 
is the same as su_arta.testseries[235,239,243,247,...].

* Support added for timestrings inside sql where clauses 
(eg., su_arta.testseries[? time > $(2009.10.25_UTC) ?]).

* Support added for ISO times and DOY times.

* Added a '-l' flag to set_keys that allows the user to specify keyword names
in lower case.

* Added a '-I' flag to show_info that prints session information: host, runtime, 
jsoc_version, log directory.

* Added a '-v' flag (verbose) to show_info that displays diagnostic information.

* Added a '-x' flag to show_info that shows current archive status.

* Added a '-K' flag to show_info that shows a list of links

* Exported drms_names_parseduration() so modules can parse time-duration strings, like
12.8s and 14h.

* New DRMS API functions - drms_record_nextkey() and drms_record_nextseg(). These
functions allow the caller to iterate through a record's keywords and segments, and 
they properly follow linked keywords and segments.

BUG FIXES:
* RemoteSUMS now works when Stanford storage units are offline (and on tape).

* Several problems with make dependencies fixed.

* Several fixes to make drms_server shut down cleanly. Fix cases where
direct-connect modules were not calling PQfinish() to terminate 
connection to DRMS database.

* Fix host-and-port-number parsing so that drms_server uses the drms_session table
in the correct database.

* Queries involving finding the record with the largest or smallest value of more
than one prime keyword now operate in the following manner. All records that 
match the query from the first prime keyword are first identified. Then from
that set of records, all records that match the query from the second prime
keyword are selected.  And so on for additional prime keys.

* Ensure that FITSRW uses double-precision floats for bscale/bzero, not 
single-precision.

* Record slots created within a session that get freed can now be reused.

* Memory leak in libtimeio.a removed.

* The parsing of time-duration character strings used to result in truncated floating-point
durations (eg., 12.8s became 12 seconds). This has been fixed so that 12.8s means 12.8 seconds.

* Fix create_series jsd parser so that it properly tracks the line number in the .jsd 
when reporting errors. It now also reports a more useful drms_parser.c line number when 
an error occurs.

* Fixed hang that occurred when a DRMS record-set query was missing the trailing ']'.

* Fixed jsoc_export_as_fits, which was not exporting non-FITS segments and not 
exporting linked segments.