Presently, "success" is defined to be "exit with code 0"; this will change in a future revision.
-In 8.5.3, "success" will be defined by three job ad attributes: SuccessCheckpointExitBySignal, SuccessCheckpointExitSignal, and SuccessCheckpointExitCode. If the first is true, then "success" occurs when the process exits on signal SuccessCheckpointExitSignal. Otherwise, "success" occurs when the process exits with code SuccessCheckpointExitCode. (As this is an experimental feature, you'll need to prepend a '+' to each of the preceeding attributes when you use it in a submit file.)
+In 8.5.3, "success" will be defined by three job ad attributes: CheckpointExitBySignal, CheckpointExitSignal, and CheckpointExitCode. If the first is true, then "success" occurs when the process exits on signal CheckpointExitSignal. Otherwise, "success" occurs when the process exits with code CheckpointExitCode. (As this is an experimental feature, you'll need to prepend a '+' to each of the preceeding attributes when you use it in a submit file.)
+
+In 8.8.2 (and 8.9.1), "success" will be defined in the same way, but the name of the attributes change to SuccessCheckpointExitBySignal, SuccessCheckpointExitSignal, and SuccessCheckpointExitCode, respectively. You will still need to prepend a '+'.
In 8.5.3, you may also set '+WantFTOnCheckpoint = TRUE'. If during the course of normal execution the job exits with "success", as defined above, file transfer will occur as if the job is being evicted.
@@ -24,6 +26,6 @@
{section: Random Thoughts}
-The code currently doesn't update the job ad on a successful checkpoint; it also does not correctly tell the shadow (and therefore the schedd or job log) if the job successfully checkpointed (it will always say it didn't).
+The code currently doesn't tell update the job ad on a successful checkpoint; it also does not correctly tell the shadow (and therefore the schedd or job log) if the job successfully checkpointed (it will always say it didn't).
The remote usage accounting is probably entirely wrong.
