Release Notes JSOC V8.8 2APR2015 ----------------------- --------- A release is a set of binary and text files, each having a specific version. The release itself is also versioned to facilitate the identification of the release. For example, release 1.3 may contain fileA#1.8, fileB#1.2, and fileC#2.2 and release 1.4 may contain fileA#2.5, fileB#2.1, and 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 (e.g., n04 and solar3). At the time of the creation of the release, the versions of each file will be very recent - most will be the "head" versions. The set of files is stable. They have been tested and verified to work properly on the supported systems. As time passes, newer versions of files will be committed to the code repository and there is no guarantee that these changes will not destabilize JSOC (i.e., 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 use the production binaries, which are located at /home/jsoc/cvs/Development/JSOC (The release binaries are actually in /home/jsoc/cvs/JSOC, but as our production code changes more quickly than releases are generated, we put critical fixes in the "Development" tree. To be sure you use code that has been built with these critical fixes, you'll need to use the "Development" tree. As time passes our production code will stabilize. When that happens, you should use /home/jsoc/cvs/JSOC. But for now, you should use the "Development" tree.). Every time a release is created, the binaries in this location get updated by the jsoc user. To use these binaries, you can run them directly, "/home/jsoc/cvs/JSOC/Development/bin/linux_x86_64/show_info -j hmi.M_45s", for example. Or you can put /home/jsoc/cvs/JSOC/Development/bin/linux_x86_64 in your path environment variable. If instead you want to work with stable source files, then you must have a local copy (e.g., in your home directory) of the source code in the CVS code repository. You must "build" or "make" the code this local code before it can be used. You will want to work with a local copy if you plan on making changes to the repository files (i.e., you plan on doing development). Changes you make to your local copy are not visible to other users until you commit those changes back to the CVS repository. 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 see the section entitled Update Your Existing Working Directory ("Sandbox")). 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. Additional Info --------------- Use the Apache CVS gui to see diffs between file revisions. For example, go to http://jsoc2.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 (V8.7 - February 19, 2015) ---------------------------------------------------------- NEW FEATURES: - The build now has two variants: a full build, and a incremental build. In the full build, the bin and lib links are deleted and remade, the localization files are deleted and regenerated, and globalhs is made. In the incremental build, none of these happens. Prior to this, there was only a full build. The purpose of the incremental build is to provide a way to re-build only the binary files that are out-of-date. The globalhs target builds all binaries, regardless of their up-to-date status, so it was removed from the incremental build. - The pass-thru code was redesigned. The implementing code was moved from the web-page Javascript (it was partially implemented in the Javascript) to the CGI layer. - To use the jsoc_fetch CGI, users must provide a registered email address. The implementation of this requirement was incorporated into the build. - The checkAddress CGI was modified to return the name of any missing arguments in the case where the user fails to provide all required arguments. - The email-registration system now provides the confirmation code in the body of the email instead of in the subject line. There were issues where SMTP servers were modifying the subject line and, in a few cases, deleting the confirmation code for reasons unknown. LOCALIZATION: - There is a single new localization parameter: REGEMAIL_TIMEOUT. The value of this parameter is the number of minutes, after which a pending email registration process will be canceled. If you are not running at Stanford, the value will not matter. DEFECTS FIXED: - The make system had been unnecessarily rebuilding binary files that were already up-to-date. Several make files were edited to fix this. - The make system had a bug that resulted in certain libraries being built twice. These were lower-level libraries, so the result was that almost every binary was getting rebuilt every time make was run. - The -d flag of the configure script, which is supposed to cause the script to not remake bin and lib links, was in fact not preventing this from happening (links were not being deleted, which is good, but there was an attempt to recreate them). - The drms_parserecset program, which emits JSON, was failing to escape characters that needed to be escaped (the defect was noticed when a record-set specification was provided that contained double-quote characters that were not being escaped). - show_series, publish.pl, unpublish.pl, create_series, and delete_series used to make use of a database table, drms.allseries, to speed up certain operations. However, as part of pass-thru feature redesign, drms.allseries was removed. These modules were then modified to not use this database table. - jsoc_info was modified to properly extract the two 16-bit retention values from the seriesinfo->retention field. Prior to this, the single 32-bit value was displayed as the new-SU retention value. - jsoc_info had been attempting to follow links to a linked segment, even if the original segment was not linked to a linked segment. - Some bugs were fixed in the sharps code - one was a crash. The memory footprint was reduced as well. - Fixed a deadlock in remote-sums code. - Merged some JMD-support changes from NSO. The changes were to deal with some memory stomping they were seeing. RINGS: apps/datavg added initializations of several variables; made calculation of power values conditional on presence of the appropriate segment in the output record apps/rdcover initialized tlast; removed needless (and uninitialized) interpolation code and verbose messages of same scripts/avgpsbycr new cluster queues, and submit limits; fuller diagnostics on failures