ViewVC Help
View File | Revision Log | Show Annotations | Root Listing
Revision: 1.2
Committed: Tue Apr 8 16:18:30 2008 UTC (15 years, 5 months ago) by arta
Branch: MAIN
CVS Tags: Ver_6-0, Ver_6-1, Ver_6-2, Ver_6-3, Ver_6-4, Ver_4-3, NetDRMS_Ver_8-8, Ver_4-4, Ver_8-5, Ver_4-7, Ver_5-14, Ver_5-13, Ver_5-12, Ver_5-11, Ver_5-10, Ver_LATEST, NetDRMS_Ver_LATEST, Ver_4-6, NetDRMS_Ver_8-12, NetDRMS_Ver_8-10, NetDRMS_Ver_8-11, NetDRMS_Ver_9-1, NetDRMS_Ver_9-0, NetDRMS_Ver_9-3, NetDRMS_Ver_9-2, NetDRMS_Ver_9-5, NetDRMS_Ver_9-4, Ver_7-0, Ver_5-6, Ver_4-5, Ver_4-2, NetDRMS_Ver_9-41, Ver_9-41, NetDRMS_Ver_8-4, NetDRMS_Ver_8-5, Ver_5-8, NetDRMS_Ver_8-6, Ver_5-7, Ver_8-8, NetDRMS_Ver_8-7, Ver_5-9, Ver_8-2, Ver_9-3, Ver_8-0, Ver_8-1, Ver_8-6, Ver_8-7, Ver_8-4, Ver_8-11, Ver_5-3, Ver_5-2, Ver_5-1, Ver_5-0, Ver_7-1, Ver_9-1, Ver_5-5, Ver_8-3, Ver_9-5, Ver_9-4, Ver_8-10, Ver_9-2, Ver_8-12, Ver_9-0, HEAD
Changes since 1.1: +1 -1 lines
Log Message:
Fix typo where V4.2 was instead V4.1

File Contents

# Content
1 Release Notes JSOC V4.2 8Apr2008
2 ----------------------- --------
4 A release is a set of files, each having a specific version. And a release typcially
5 has a version number because over time you have newer and newer releases of the
6 same product. For example, a hypothetical 1.3 release may contain fileA#1.8,
7 fileB#1.2, fileC#2.2 and a 1.4 release may contain fileA#2.5, fileB#2.1, fileC#2.9.
8 JSOC releases are similarly versioned and contain a set of such files. JSOC release
9 code is guaranteed to compile on cluster nodes (eg., n00, n02). The resulting binaries
10 have been minimally tested. At the time of the creation of the release, the
11 release versions of each file will be the most recent. But as time passes, newer versions
12 of some files will be made, and there is no guarantee that these changes will
13 not destabilize JSOC (ie., they may cause JSOC to no longer compile or execute
14 properly).
16 There are several ways to use this release. If you wish to simply use pre-built
17 binaries, you can simply use the production binaries, which are located at
18 /home/production/cvs/JSOC. Every time a release is created, the binaries in
19 this location get updated. Only the production user can update these binaries.
20 So, you could run /home/production/cvs/JSOC/bin/linux_x86_64/show_keys, for example.
21 If instead you want to work with stable source files, then you must have a sandbox,
22 which is a local copy (in your home directory) of the files in the cvs depot.
23 You would probably want to work with a sandbox if you plan on making eventual
24 changes to the depot files. Changes you make to your sandbox files are not visible
25 to other users until you "commit" those changes back to the cvs depot. Please see
26 "If You Don't Have a Sandbox" below for more information on how to create a sandbox.
27 There is also a "working" release which resides in in /home/jsoc/cvs/JSOC. New
28 files may be placed here and existing files may be edited for common use before the
29 next official release. Each time a release gets created, the source and binaries of
30 the working release get updated. WARNING: the files you see here may not be stable
31 since by the time you see them, another user may have edited them. Only the production
32 release is guaranteed to be stable and unchanged between releases.
34 Obtaining the Release
35 ---------------------
36 To update your working directory to this release, or to check-out this release anew,
37 please visit Please keep in mind that
38 users may have modified files since the release was created, so use of the
39 scripts documented in the web page may result in a working directory whose
40 content is not identical to the release. If updating, you can supply
41 the flag "-R" to the and scripts to download the
42 latest release. This will ensure that your working directory has the exact, latest
43 release versions of the files (eg., jsoc_sync.csh -R). If checking-out,
44 you can supply the argument "-r Ver_LATEST" to the "cvs checkout" command
45 to achieve the analogous result, but for a fresh checkout. WARNING: if you use
46 the "-R" or "-r" flags, please use only or to update
47 your sources thereafter. Use of "-R" or "-r Ver_LATEST" will result in a cvs
48 "sticky flag" being set. and clear this sticky flag.
50 Additional Info
51 ---------------
52 If you are unfamiliar with the use of cvs see the file:
53 JSOC/CM/working_with_sandbox.txt.
55 There's a linux4 cvs gui at xim:/usr/bin/lincvs
56 Also on our jsoc web page:
60 Use the Apache cvs gui to see the diffs. For example, go to
62 and click on the name in the File column and then click on
63 "diffs to previous #" to see the diffs.
65 Changes since previous release (V4.1 - March 3, 2008)
66 -------------------------------------
67 * drms_segment_read() and drms_segment_write() now use a new library, fitsrw, to read and write FITS files. Previously, this FITS access was achieved via functionality in drms_fits.c. fitsrw, a wrapper around CFITSIO, is much more robust.
68 * Implemented drms_export API. This includes several functions that export fits files to an output series (eg, jsoc.exports). A recordset, a record, a segment can all be exported. These functions convert internal drms kewords into external fits keywords, using a hierarchy of mapping instructions (user-specified mapping, class mapping, default mapping). Also created a module, jsoc_export, that takes as input a recordset query and exports one or more records into the export series jsoc.exports.
69 * Added Level 0 scripts for getting and making housekeeping(hk) configuration data and creating hk data series. Currently runs on local JSOC workspace(carl@yeti) and in future to run on production account.
70 * Moved scripts to JSOC environment from EGSE environment. These scripts are used in JSOC in cron job to get latest STANFORD_TLM_HMI_AIA.txt(STANFORD) and GROUND_to_CODE_ids.txt (GROUND) files from server and then calls other scripts to create HKPDF small apid files, check into cvs STANFORD, GROUND, gtcids.txt, and HKPDF small apid files, build preliminary and final hk JSDs files, build map file for JSOC version numbers, create hk data series, and send email to interested parties on status. Also creates a log file to trace status.
71 * Added scripts which run on LMSAL HMIFSW1 machine which secure copy latest STANFORD and GROUND files to for scripts on JSOC to pickup.
72 * Changes so that our JSOC code builds on Mac: don't use strndup as it is not POSIX-compliant (rewrote code to use strdup instead); modify make files and configure to use $JSOC_MACHINE == mac_osx; don't use the _GNU_SOURCE flag; ensure SUMS functions that were defined in multiple files and had the same name didn't collide; work-around if __attribute_used__ is not defined (in apple); add defines like #define xdr_uint_t xdr_u_int_t; Fix case constants so they are POSIX-compliant (they were const ints variables - changed them to const ints); remove hard-coded icc compilation from SUMS.
73 * Update configure script to make the check for 3rd-part libraries machine dependendent (in other words, display linux_x86_64-specific warnings if the user machine is linux_x86_64).
74 * Update configure script to make links from the top-level include directory to base/include.
75 * Update configure script with template 3rd-party links for non-Stanford users.
76 * Fix the capture of the output of the script.
77 * Update to better synchronize the user's workspace with the repository. First call 'cvs update'. This will add/remove files from the existing working directory directories. This will remove obsolete files from the user's working directory. Then call 'cvs checkout <module>. This will add directories to the working directory that were added to cvs (within the module <module>) since the last checkout by the user.
78 * Fix - it wasn't running the configure script because there was a missing semicolon.
79 * Set -L and -l flags for cfitsio compile for gcc build.
80 * Remove -lm from icc builds.
81 * Change SUMS from gcc/icc hybrid to either all icc (default) or all gcc.
82 * Added minimal SUMS support for Itanium. SUMS builds and runs on ia64, but has not been tested.
83 * Documentation for several drms utilities added: drms_log, drms_query, drms_server, masterlists, create_series, delete_series, describe_series, modify_series. Add masterlists description for user vs sys for nsgrp.
84 * masterlists: added dbidx to drms_series table.
85 * Add ringfit_ssw.f in the proj/examples/apps directory - this is a Fortran module that calls D. Haber's ringanalysis Fortran function.
86 * Fixed drms_free_env() to handle early bailout, e.g., missing namespace.
87 * Added time mapping (from date strings or enum vals to doubles) to drms_types.c since TIME is one of the drms types. There are only a couple of time functions so keep them merged in drms_types.c, not a separate new file. Add time epoch defines to timeio, and have drms use them.
88 * Change index keyword type to long long (was type 'int' before).
89 * slotted-keywords: move the 0th slot so that its CENTER corresponds to the epoch.
90 * Break up drms_ismissing() into type-specific inline functions.
91 * Remove the 32-byte limit on primekey query string that does not have the keyword name in it.
92 * Fix drms_sscanf(), when parsing time, always succeeds if a string is passed in. Make drms_names check for duration first before attempting to parse time.
93 * Allow empty strings in jsds and command line when a drms string is expected; fix crash in cfitsio_write_file - don't use unitialized fptr; fix problem with fitsio type TLONG - it corresponds to C 'long' data type.
94 * Define 'DRMS_MISSING_VALUE' as the string to use in the jsd to cause DRMS to set a value to missing.
95 * Store dbindex information in the drms_series table.
96 * Fix the drms_protocol code - got rid of redundant enum listing all types (one enum was in a different order than the other too), enhance efficiency of lookup.
97 * Removed order by clause if no prime key.
98 * Initialize rs->records to prevent segfault when fail to allocate recnum.
99 * Add drms_query_string().
100 * Bug fix to handle no dbidx case.
101 * Fix drms_sscanf() - must return a value to indicate an invalid time because drms uses this code to test time strings and performs one action if the time string is valid, and another if the time string is invalid. This value should be -1 to be consistent with the non-time data types. If it is ever changed from -1, then the entire drms must be scanned to find the reliance upon -1 and changed appropriately.
102 * Fixes for release - change inappropriate uses of drms_missing() to drms_ismissing(); change signature of drms_missing() so that future uses are less likely to be wrong. ; added a new script for helping to generate cvs comments since a specified date.
103 * Update jsoc_main documentation.
104 * Unlock db handle in db_dms_array upon query error.
105 * In FITSRW, remove trailing / if no comment follows.
106 * In FITSRW, added combined read img + header function.
107 * Set _POSIX_SOURCE to prevent compilation problems with icc10 and gcc.
108 * Add new SUMS flags: SUMT120, SUMT950.
109 * show_info: reinstate DBindex printing in -l case.
110 * show_series: modified JSON output to include prime keys and note.
111 * use actual comment as key, not time because CVS lamely records the actual modification time of files being modified, not the time that the commit was performed.
112 * Addition of the module jsoc_info.
113 * Add webapp (lookdata) that provides series information.
114 * Various minor fixes to hmi_time_setting, hmi_import_egse_lev0.
115 * Move img->dat and img->hist initialization to the end of img struct initialization.
116 * ingest_lev0: fixed up some lev0 keywords, add exposure time and mech values.
117 * hk dayfiles: update sprint_time format argument from UT to UTC, Added line to fix bug. Initialized pointed to NULL, Update with checks for environment variable setting, Added write to ISPSNAME and ISPPKTIM for lev0 data series.
118 * Moved script to JSOC enviroment from EGSE environment. This scripts builds HKPDF small apid files, checks into JSOC cvs automatically the STANFORD,GROUND, gtcids.txt, and HKPDF small apid files for the Level 0 code to use.
119 * Moved script to JSOC enviroment from EGSE environment. This scripts builds HKPDF small apid files, checks into JSOC cvs automatically the STANFORD,GROUND, gtcids.txt, and HKPDF small apid files for the Level 0 code to use.
120 * updated archive setting for temporary test data series to "Archive 0".
121 * moved script to JSOC enviroment from EGSE environment. This script creates JSD files based on a list of new JSD files creates.
122 * Moved script to JSOC enviroment from EGSE environment.This script is used in cron job to get latest STANFORD and GROUND file from server and then calls other scripts to create HKPDF small apid files, checkin STANFORD,GROUND,gtcids.txt, and HKPDF small apid files, build preliminary and final JSDs files, build map file for JSOC version numbers, create data series, and send email to interested parties of status. Also creates a log fileto trace status.
123 *, Move from EGSE environment to JSOC workspace enviornment.
124 * moved script to JSOC enviroment from EGSE environment. This script create the JSOC Version Number map file per APID, updated script to create map files for only HK Packets with the VER_NUM keyword.
125 * moved script to JSOC enviroment from EGSE environment. This script is used to create HKPDF small apid files based on the STANFORD_TLM_HMI_AIA.txt file. The HKPDF file are save in a directory based on the File Version Number in the STANFORD file. This File Version number matches the version number in CVS. There are HKPDF files created for each APID or based a list of APID given to script.
126 * updated script to create final and Preliminary JSD files for only; fixed path to new_jsd_file.txt file which contains a list new jsd file versions created; moved script to JSOC enviroment from EGSE environment. This script create preliminary and final JSD files based on arguments passed to script. The preliminary JSD files are used to help create the JSOC Version Number map files by another script. The final JSDs are created for each APID when new keyword data occurs. The final JSDs are used to create data series for housekeeping data in DRMS.
127 * moved script to JSOC enviroment from EGSE environment. The Make Housekeeping Data Series(mhds) script is use to detect new JSDfile has been created. The onces created are added to file based on a list of APID data series want to create. This scripts call to create the new data series.
128 * Hook in the fds ingest script into the cron job script so that FDS data files are downloaded to /surge, then ingested into sdo.moc_fds, then deleted from /surge.
129 * mocDlFds.csh: use real jsoc:sdo.moc_fds data series to ingest to; use ~jsoc/sdo/fds for download status file.
130 * Add json creation tool library.