Archiving tools are being created for stand-alone CAM that differ
in some ways from how CCSM currently does its archiving. Some of the
differences may be due to oversights, others we may want to adopt in
the CCSM scripts. It may be desirable to have a generic set of scripts
that could be used in all cases. Either way, the list of differences
that follows is worth a discussion.
- st archiving area is used only for archiving and not for staging data - ie no sub directory in st archive area for latest restart files or pointer files (copies of these should be in run directory)
- archiving directory tree (hist, rest, init, logs for each component) is established in st archiving area and then copied entirely to lt archive - no copying of individual files to lt storage...better if this were a tar file?
- validation of lt archiving is done immediately after copy, not on the next invocation of the lt archiving script
- the alphabetical listing of files is used to determine the latest restart files rather than the actual date/time of the files
- user has an option of whether to archive all restart files or just the last generated from a block run, and this is settled at time of st archiving, not lt archiving
- user has an option for the level of archiving integrity: high=pull back the file from lt storage for comparison before deleting local; low=simply compare file sizes remotely and delete local if equal
- executables are not archived
- now returns a non-zero return code if one or more files did not reach lt archive successfully