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.

    -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.

    -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.)

   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.