GLOBUS-JOB-SUBMIT(1)

💖 GLOBUS-JOB-SUBMIT(1) 💖

okay bestie, welcome to the Grid Community Toolkit manual page for globus-job-submit 🎀 this is the one that yeets your batch job at GRAM, no cap.

✨ NAME ✨

globus-job-submit — submit a batch job using GRAM 🚀

✨ SYNOPSIS ✨

globus-job-submit [-dumprsl|-dryrun|-verify] [-file ARGUMENT_FILE]
SERVICE-CONTACT [OPTIONS] EXECUTABLE ARGUMENT...

globus-job-submit [-help | -usage | -version | -versions]

✨ DESCRIPTION ✨

so basically 💅 globus-job-submit builds a whole job description out of its command-line options and then submits that job to the GRAM service chillin' at SERVICE_CONTACT. the executable and the arguments you wanna hand to that executable go on the command line after all the other options, so the order is giving very much "options first, then the actual thing to run" energy.

⚠️ real talk though: the -dumprsl, -dryrun, -verify, and -file command-line options must occur before the first non-option argument, which is the SERVICE_CONTACT. no exceptions, bestie, that's the vibe check right there.

the way that globus-job-submit works is honestly giving globusrun-coded ✨ — it lets you do batch submission of GRAM jobs, same as that one. BUT. unlike globusrun, it uses command-line parameters to define the job instead of RSL expressions. so if RSL syntax makes you wanna scream into a pillow 😭, this is your moment, bestie.

now, to actually get at your job's output and error streams, you're gonna wanna use the program globus-job-get-output 💖. to reclaim the resources your job used up — like deleting cached files and job state — use globus-job-clean 🧚. and to cancel a batch job that you submitted with globus-job-submit, use globus-job-cancel. it's giving a whole little friend group of utilities, ngl 👑

✨ OPTIONS ✨

here is the full set of options for globus-job-submit, and yes, we're doing all of them, no skimming, periodt 💅:

• -help, -usage — shows you a help message on standard error and then exits. iconic behaviour.
• -version — prints the software version of the globus-job-submit program to standard output. slay.
• -versions — prints the software version of the globus-job-submit program to standard output, but with DiRT information included too. extra lore, we love it.
• -dumprsl — translates the command-line options you gave to globus-job-submit into an RSL expression, so you can use it with tools like globusrun. it's giving "translator bestie" 🌈.
• -dryrun — submits the job request to the GRAM service with the dryrun option enabled. when you do this, the GRAM service gets everything ready to execute the job but stops before submitting the job to the LRM. super useful for diagnosing some problems, like missing files 👀.
• -verify — submits the job request to the GRAM service with the dryrun option enabled, and then, if that dryrun was successful, submits it again without dryrun enabled. two-step queen behavior ✨.
• -file ARGUMENT_FILE — reads additional command-line options from ARGUMENT_FILE.
• -np PROCESSES, -count PROCESSES — starts PROCESSES instances of the executable as a single job. squad goals 👯.
• -m MAX_TIME, -maxtime MAX_TIME — schedules the job to run for a maximum of MAX_TIME minutes. ⏰
• -p PROJECT, -project PROJECT — requests that the job use the allocation PROJECT when submitting the job to the LRM.
• -q QUEUE, -queue QUEUE — requests that the job be submitted to the LRM using the named QUEUE. get in line, bestie 🎟️.
• -d DIRECTORY, -directory DIRECTORY — runs the job in the directory named by DIRECTORY. input and output files get interpreted relative to this directory. this directory must exist on the file system on the LRM-managed resource 🫶. if you don't specify it, the job runs in the home directory of the user the job is running as.
• -env NAME=VALUE — defines an environment variable named by NAME with the value VALUE in the job environment. you can specify this option multiple times to define multiple environment variables 💜.
• -stdin [-l | -s] STDIN_FILE — uses the file named by STDIN_FILE as the standard input of the job. if the -l option is specified, then this file is interpreted to be on a file system local to the LRM. if the -s option is specified, then this file is interpreted to be on the file system where globus-job-submit is being executed, and the file will be staged via GASS. if neither is specified, the local behavior is assumed.
• -stdout [-l | -s] STDOUT_FILE — uses the file named by STDOUT_FILE as the destination for the standard output of the job. if the -l option is specified, then this file is interpreted to be on a file system local to the LRM. if the -s option is specified, then this file is interpreted to be on the file system where globus-job-submit is being executed, and the file will be staged via GASS. if neither is specified, the local behavior is assumed.
• -stderr [-l | -s] STDERR_FILE — uses the file named by STDERR_FILE as the destination for the standard error of the job. if the -l option is specified, then this file is interpreted to be on a file system local to the LRM. if the -s option is specified, then this file is interpreted to be on the file system where globus-job-submit is being executed, and the file will be staged via GASS. if neither is specified, the local behavior is assumed.
• -x RSL_CLAUSE — adds a set of custom RSL attributes described by RSL_CLAUSE to the job description. the clause must be an RSL conjunction and may contain one or more attributes. this is your cheat code for including attributes that can't be defined by the other command-line options of globus-job-submit 🔥.
• -l — when included outside the context of the -stdin, -stdout, or -stderr command-line options, the -l option alters the interpretation of the executable path. if the -l option is specified, then the executable is interpreted to be on a file system local to the LRM.
• -s — when included outside the context of the -stdin, -stdout, or -stderr command-line options, the -l option alters the interpretation of the executable path. if the -s option is specified, then the executable is interpreted to be on the file system where globus-job-run is being executed, and the file will be staged via GASS. if neither is specified, the local behavior is assumed.

✨ ENVIRONMENT ✨

if the following variables affect the execution of globus-job-submit. 🌱

• X509_USER_PROXY — path to proxy credential. 🔐
• X509_CERT_DIR — path to trusted certificate directory. 📜

✨ SEE ALSO ✨

globusrun(1), globus-job-run(1), globus-job-clean(1), globus-job-get-output(1), globus-job-cancel(1) 🦋

✨ AUTHOR ✨

Copyright © 1999-2014 University of Chicago 🏛️

okay that's the whole page, you ate it, no crumbs 💅✨ this was Grid Community Toolkit 6, dated 03/31/2018 — mwah, sending you off with the biggest hug, bestie 🫶💖🌈