(file) Return to release.notes CVS log (file) (dir) Up to [Development] / JSOC / CM / V5.12

File: [Development] / JSOC / CM / V5.12 / release.notes (download)
Revision: 1.1, Wed Dec 15 19:42:18 2010 UTC (12 years, 9 months ago) by arta
Branch: MAIN
CVS Tags: Ver_LATEST, Ver_9-5, Ver_9-41, Ver_9-4, Ver_9-3, Ver_9-2, Ver_9-1, Ver_9-0, Ver_8-8, Ver_8-7, Ver_8-6, Ver_8-5, Ver_8-4, Ver_8-3, Ver_8-2, Ver_8-12, Ver_8-11, Ver_8-10, Ver_8-1, Ver_8-0, Ver_7-1, Ver_7-0, Ver_6-4, Ver_6-3, Ver_6-2, Ver_6-1, Ver_6-0, Ver_5-14, Ver_5-13, Ver_5-12, NetDRMS_Ver_LATEST, NetDRMS_Ver_9-5, NetDRMS_Ver_9-41, NetDRMS_Ver_9-4, NetDRMS_Ver_9-3, NetDRMS_Ver_9-2, NetDRMS_Ver_9-1, NetDRMS_Ver_9-0, NetDRMS_Ver_8-8, NetDRMS_Ver_8-7, NetDRMS_Ver_8-6, NetDRMS_Ver_8-5, NetDRMS_Ver_8-4, NetDRMS_Ver_8-12, NetDRMS_Ver_8-11, NetDRMS_Ver_8-10, HEAD
Release notes for JSOC release 5.12

                       Release Notes JSOC V5.12        15DEC2010
                       ------------------------        ---------

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

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:

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


Use the Apache cvs gui to see the diffs. For example, go to
and click on the name in the File column and then click on
"diffs to previous #" to see the diffs.

Changes since previous release (V5.11 - Oct 6, 2010)

- Moved all FITS-export code out of lib DRMS and into a new library in
- Added code to check for user permissions to read from the
_jsoc.sl_table. This table is accessed when delete_series is called to
determine if the series being deleted is being replicated (and we
disallow deletion of slony-replicated series).
- The COMMENT and HISTORY keywords are now exported into the FITS header
when a record being exported contains those keywords.
- Added 'RECNUM' to set of FITS keywords exported during export of FITS
- Modified the jsd parser to print a warning if provided external
keyword name (in the keyword description) is RECNUM, since this will
collide with the auto-export of RECNUM.
- New module set_info - this is virtually identical to set_keys,
except that it will also copy FITS files into series that contain
FITS-protocol DRMS data segments.
- Added file-locking syncronization to publish_series.sh to disallow
multiple instances of publish_series.sh to run.
- Updated the flatfield code to a newer version.
- Added support for APID 44 to housekeeping-processing code.
- Added DATE keyword to housekeeping-processing code.
- Ticket #303 - Created editloggertabs.pl, a script to
create/delete/modify configuration tables used by monitoring/logging
- Created newdrmsuser.pl, a script that facilitates new user creation;
it creates the default/appropriate entries in the db and it runs
- Modified the DRMS library code that interfaces with SUMS to attempt
re-connection in the event that the existing SUMS connection
- Added a jsoc_main parameter, "--loomain", that causes modules to
loop attempting to connect to SUMS when the initial SUMS-connection
attempt failes. By default, if the initial SUMS-connection fails, then
modules do not attempt to connect again.
- Add DRMS support for SUMS' storeset 1. If you create a series with a
tapegroup greater than 9999, then the storeset will be greater than 0
(storeset = tapegroup % 10000). The storeset controls which block of
/SUMXX gets used for that series. Currently, only storeset 0 and 1 are
used (1 means store on /SUM100, which is at LMSAL). 0 means store on
any of the other SUMS partitions.
- Add DRMSPGPORT to serverdefs.h. This is now a localizable define
that specifies the port to use on the PostgreSQL db used for DRMS.
- In the series publication code, print out the query that finds
long-running transaction in the email sent out warning about
long-running transactions blocking publication.
- Added perl module to the CVS tree - this module provides code that 
formats log output for use with anomaly-monitoring code.
- New SUMS API function - SUM_nop(). This can be called to check if
SUMS is running.
- Added "-T" flag for show_info. This causes the archive tape name and
file number to be printed for each record printed.
- Added support for additional housekeeping APIDs.

- Export all symbols from the lib DRMS library linked into DRMS
modules so that libdsds.so (a Stanford-specific library that
interfaces with DSDS code) can call into a couple of lib DRMS
functions. Run-time code using libdsds.so had started failing.
- Remove the trailing 'Z' in the DATE- and DATE__OBS-keyword values
when these keywords are exported. The trailing 'Z' is not allowed
according to the FITS-file standard.
- Ticket #319 - Modified drms_link_getpidx(DRMS_Record_t *rec) to
return a status code that is used by drms_insert_series(). If
drms_link_getpidx() fails - in the reported case, because the linked
series did not exist - then drms_insert_series() fails with an error.
- Fixed segmentation fault in jsoc_info that could happen if a 'bad
segment' link exists.
- Removed some memory leaks and memory corruption problems with one of
the export-utility library source files.
- Ticket #306 - Added case statements for ARG_DOUBLE and ARG_DOUBLES
to the function that returns the name (string) for each argument data
- Fixed a problem with SUMLIB_Main_Update.pgc - there was an extra
declaration for SUM_Main_Update() which differed from the declaration
in sum_rpc.h. Removed the declaration in SUMLIB_Main_Update.pgc
- Fixed a problem in show_coverage where a failure occurred when the
user specified a key to use.
- Added missing return value from DoIt() function in show_series.
- Fixed problems with confidence and cleaned-up code in some
magnetic-pipeline modules.
- In delete_series, moved the call to delete SUs before the code that
deletes db tables. This way the db tables are not touched if there is
a failure deleting the SUs (and then the user can try delete_series
- Improved handling of negative pixel values in the level1 despike
- AIA level1 - Added code to set temperature and throughput (response)
related keywords.

- Please see http://jsoc.stanford.edu/trac/report/1 for a list and
description of most known bugs.

Karen Tian
Powered by
ViewCVS 0.9.4