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

File: [Development] / JSOC / CM / V3.8 / release.notes (download)
Revision: (vendor branch), Mon Oct 1 23:12:21 2007 UTC (15 years, 11 months ago) by arta
Branch: Vtag, 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-9, Ver_5-8, Ver_5-7, Ver_5-6, Ver_5-5, Ver_5-3, Ver_5-2, Ver_5-14, Ver_5-13, Ver_5-12, Ver_5-11, Ver_5-10, Ver_5-1, Ver_5-0, Ver_4-7, Ver_4-6, Ver_4-5, Ver_4-4, Ver_4-3, Ver_4-2, Ver_4-1, Ver_4-0, NewTree01_cp09_JSOC, NewTree01_cp08_JSOC, NewTree01_cp07_JSOC, NewTree01_cp06_JSOC, NewTree01_cp05_JSOC, NewTree01_cp04_JSOC, NewTree01_cp03_JSOC, NewTree01_cp02_JSOC, NewTree01_cp01_JSOC, 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
Changes since 1.1: +0 -0 lines
First new, reorganized JSOC tree

                       Release Notes JSOC V3.8         12Sep2007
                       -----------------------         ---------

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.

Updating to this release
Once you have a sandbox, you may want to update it to this release so that you
get new functionality that is stable (the binaries build and run properly).  
The general way of doing this is to run "cvs update -APd -r Ver_3-8" from $JSOCROOT.
The "-r" flag tells cvs to ensure that all your local files have the versions that
compose the 3.8 Release.  You would then need to run "make" from $JSOCROOT to 
build the binaries.  Alternatively, there is a script, $JSOCROOT/jsoc_update.csh
that can be used to both update to the latest release and to build JSOC on all
supported machines.  To do this, run $JSOCROOT/jsoc_update.csh -R.  The "-R" flag
tells cvs to update to the latest release before building on the supported
machine types.  This script generates log files for each machine type: 
$JSOCROOT/make_jsoc_linux_X86_64.log and $JSOCROOT/make_jsoc_linux_ia32.log.
You should examine these logs to look for errors.  Before updating to the release
with either of these alternatives, ensure that somewhere in your setup 
"source $HOME/.setJSOCenv" exists.  

If You Don't Have a Sandbox 
You need a cvs "sandbox" to contain your view of a JSOC release:
(There is no need to do this unless you're going to be a jsoc developer.)

Set the env variables:

Make a cvs dir and do:
> cd /home/you/cvs
> cvs checkout jsoc

This will copy the LATEST version of all cvs depot files to /home/you/cvs/jsoc.
These are not guaranteed to be stable.  This is something you may want to do if 
you are a developer, perhaps you are fixing a broken build.  If instead you want 
this stable release, then substitute "cvs checkout -r Ver_3-8 jsoc" for the above 
"cvs checkout jsoc" command.

You would then make changes to the checked-out files, and commit them back to the
depot with the "cvs commit files..." command.  Only after running this command
can users "see" your changes.  To "see" your changes, a user would need to update
their sandbox with the latest changes to the depot ("cd $JSOCROOT; cvs update -APd" )

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 last release (Version 3.5)

* New non-recursive make system.
* Port of time IO from MDI.
* Updated README describing new make system.
* Removal of several targts from the 'default make'.
* Environment-variable functionality to allow a debug make.
* Initial IDL interface added.
* DSDS interface added.
* Fortran interface plus make system changes to properly create 
  dependencies between Fortran modules.
* Factored out common jsoc_main code - put this into jsoc_main.c.
  Specific jsoc_mains are of the form jsoc_main_XXX.c
* Implement third-party library plan.  Update configure file so that 
  with "-l" flag, it prints out 3rd-party library dependencies, says 
  where the libraries should be installed, and says what version the 
  libraries should be.  Fix fortran_examples make rules - add dependencies 
  files, use installed 3rd-party libraries (not something in somebody's 
  home dir).  Remove from cvs 3rd-party libraries.  Remove libdsputil.a 
  from SRCLIBS - it is not used by any binary.
* jsoc_update.csh now builds on n02 for x86-64.  Added a new flag "R"
  that updates to latest release, not latest source.
* Removed warnings/loop vectorizaiton messages from default make.
* Fixed some compiler-warnings in cmdparams.
* Added params_get API functions that don't have a status parameter.
* Better diagnostics in hmi_ground/q_import_lev0_CIF_from_file.csh.
* Auto-download FDS and LZP data.
* mocDlFdsSpec.txt - Make the download script more efficient.  
  Group path specs together.  Add the span modifier in path specs.
* Add functionality to allow creating a new series on the fly.  
  Allows user to create a detached record template and subsequently 
  modify pieces of that template before creating a new series.
* Can create record, keyword, segment, etc. prototypes that are not
  cached in the record cache.
* drms_server.c - In drms_server_abort(), allow the sums_thread
  to finish. This gets rid of the error message when a drms_server aborts.
* Port v2helio to JSOC - called o2helio.

Karen Tian
Powered by
ViewCVS 0.9.4