Submitting Manual Plugin Jobs V5/V6

Deadline
1

We use deadlinecommand.exe in v5 to submit jobs manually (using the SubmitMultipleJobs option), and are in the process of upgrading from Deadline v5 to v6.
Using v5, we scrape the console output to identify highlighted text :

Deadline Command 5.2 [v5.2.0.49424 R]

Submitting to Repository: \xxx

Submission Contains the Following:
1) Auxiliary File #1 (“C:\path[b]Unique ID[/b]\max_job_info.job”)
2) Auxiliary File #2 (“C:\path\configurator_script.ms”)

Result=Success
JobID=001_049_005_263d73e7

However, trying to do the same with v6, the output differs and only includes the name of the auxiliary file, not the plugin file name and path (max_job_info.job)

Deadline Command 6.2 [v6.2.0.32 R (2563d5bc8)]

Submitting to Repository: \xxx

Submission Contains the Following Auxiliary Files:

  1. C:\path\configurator_script.ms

Result=Success
JobID=54589390b8d24b16042e8b8b

We scrape the path of the max_job_info.job file to link the specific request back to our internal database identifier.
Since this information does not come back in the V6 console output, we cannot complete the loop.

Is it possible to still get this information in the console output using this method ?

If not, can anyone confirm whether the sequence of the jobs reported back is identical to the order in which they appeared in the command line ?
For example, if I call:

deadlinecommand.exe SubmitMultipleJobs -job 1.job 1.plugin 1.ms -job 2.job 2.plugin 2.ms -job 3.job 3.plugin 3.ms -job 4.job 4.plugin 4.ms
and I get 4 JobIDs back in the console output, will the sequence match that supplied ?

Result=Success
JobID=54589390b8d24b16042e8b8b → is this my job 1
…
Result=Success
JobID=54589390b8d24b16042e8b8b → is this my job 2
…
Result=Success
JobID=54589390b8d24b16042e8b8b → is this my job 3
…
Result=Success
JobID=54589390b8d24b16042e8b8b → is this my job 4

Apologies for the long post, but I felt it best to try and include as much information as necessary

Thanks in advance for your time.
Pete

2

Hey Pete,

The order should be exactly the same. Most (probably all) of the work we do for submission is single threaded.

Now, the folder we’re submitting things to is going to be the same as the jobID. The nice thing in 7 is that the job id won’t change if you fiddle around with priorities and stuffs. In 5.x, everything before “263d73e7” was shorthand for us to scan the Repository faster (49 being priority, and I think the other two numbers being pool and group).

It’ll be a bit tricky getting the job files submitted, especially now with the SMTD throwing those into dated folders.

Were you actually copying those files after submission, or just recording their location?

3

Hi Edwin
Thanks for the reply.

Regarding the submission order, I have done my own tests and concur, so that’s good.

We don’t do anything specific with the folders after submission - I was just using the console output to pair up my ID with the Deadline JobID and status that comes back and update an internal database.

Regards,
Pete

4

Good stuffs. Well, the good news there is that the Deadline job id is set in stone now after the job is created.

If you’re archiving and unarchiving, I believe we create a new ID since we didn’t want to worry about collisions, but I don’t think that matters in your case.