Another advantage of the halt file is that it doesn't rely on the schedd to communicate with DAGMan -- on a submit machine with a very high load (perhaps caused by DAGs!), _condor_hold_ may time out, thereby preventing the user from holding the DAG to decrease the load on the machine. -Note that, while in halted mode, we run POST scripts for any nodes for which the Condor job finishes and there is a POST script. This is because if we didn't run the POST script, and then a rescue DAG got created, the node wouldn't be marked as done, and therefore the work done by the node job would be wasted. We _don't_ run any PRE scripts while we're halted, though. +Note that, while in halted mode, we run POST scripts for any nodes for which the HTCondor job finishes and there is a POST script. This is because if we didn't run the POST script, and then a rescue DAG got created, the node wouldn't be marked as done, and therefore the work done by the node job would be wasted. We _don't_ run any PRE scripts while we're halted, though. Each time through =Dag::SubmitReadyJobs()= we check for the existence of the halt file (the halt file name is defined by the =HaltFileName()= function, based on the primary DAG file name). If we find the halt file, we return from this method before submitting any more jobs (unless we're ready to run the final node). On the other hand, if we go from halted to unhalted, we start up the PRE scripts that have been deferred while we were halted.
