Usage: minos_jobsub [args] executable [exec_args] Possible [args]: Generic stuff: -h Print this help. -n Create the .cmd file and output its name, but do not submit the job(s). You can later submit the job with: condor_submit <cmd_file> -N <num> Submit <num> copies of the job. Each job will have access to the environment variable $PROCESS that provides the job number (0 to <num>-1) that is given after the decimal point in the job ID (e.g., 123456.2). -q Only send email notification if the job ends with an error. (Default is always to email.) -Q No email notification ever. -T Submit as a test job. Job will run with highest possible priority, but you can only have one such job in the queue at a time. Minossoft and enstore: -O Set up optimized minossoft (requires -r or -t). -r <rel> Set up minossoft release <rel> at the beginning of the job. -t <dir> Set up the test release in <dir> at the beginning of the job. -y <file> Get <file> (usually of the form /pnfs/...) from Enstore, point \$FROM_ENSTORE to it, and clean up when finished. You can use multiple -y options if you want \$FROM_ENSTORE to point to multiple files. You can also specify non-Enstore files if you want. (Perhaps you have a mixture of input.) Requires either -r or -t to get access to dccp. Environment: -c <ClassAd> Add condition <ClassAd> to the job. (See documentation on Condor ClassAds for more.) -e <var> Pass the existing environment variable <var> into the job. (No "$", e.g.: "-e MYVAR".) -l <line> [Expert option] Add the line <line> to the Condor submission (.cmd) file. See Condor help for more. Grid running: -g Run the job on the FNAL Grid. -d<tag> <dir> Writable directory $CONDOR_DIR_<tag> will exist on the execution node. After job completion, its contents can be moved to <dir> automatically by running the script minos_harvestfiles on a MINOS machine. This allows you to specify at submission time where your job's output should eventually end up, and minos_harvestfiles does the necessary moving for you. Specify as many <tag>/<dir> pairs as you need. AFS flags. You should never need any of these: -a If -g, then require true AFS on Grid node rather than using Parrot to get to minossoft and ups AFS areas. You shouldn't need to use this. Greatly limits the number of nodes available to you. -p Run job under Parrot. Automatically selected when running on Grid (-g), so you should never need to set this option explicitly. -pOFF Do NOT use Parrot when running on the Grid. Your job will not have AFS access in general. This setting is available mostly for testing. You shouldn't need to use -pOFF. Miscellaneous: -G <group> Submit job under group <group>. This is to allow high priority submission for batch production and critical analysis tasks. (Use of groups requires express permission.) NOTES: You can have as many instances of -c, -d, -e, -l and -y as you need. The -d directory mapping works on non-Grid nodes, too.