Feature Request: SMTDSettings.DependentJobIDs

Deadline
1

It’s easy to get the ID of the last job submitted but it’s harder to set this in a script.

We need to be able to pass the SMTDSettings.DeadlineSubmissionLastJobID to an array of Job IDs.

SMTDSettings.DependentJobIDs = #(SMTDSettings.DeadlineSubmissionLastJobID)

Otherwise you have to do a bit of a hack…

SMTDSettings.SubmitAsDependent = true SMTDSettings.DependencyJobItems = #(1) SMTDSettings.FullJobsArray = #(jobname + " : " + (SMTDSettings.DeadlineSubmissionLastJobID as string)) SMTDSettings.JobsArray = #(#("", (SMTDSettings.DeadlineSubmissionLastJobID as string), "3dsmax", "", "", "", "Queued"))

Which works but seems a bit long-winded…

Unless I’m missing something?

2

The two features (remembering the last job ID, submitting dependent jobs) were not originally designed to operate together.

I have here on my ToDo list the implementation of “chain dependency submitting” that would let you perform one submission, set an option to use its ID, and every following job can either become dependent on it, or update the ID and become the dependent job of the next one… So you can do multiple jobs dependent on one, or each dependent on the previous without having to select anything anywhere or wait for minutes to collect data. Once you are done, you just disable the option and the following jobs become independent again…

If you can wait a few weeks (next week I will be in Japan), the necessary properties and function will be available in the SMTD Functions file for your use…

3

No rush, my hack works well enough for our script. But your idea of having a ‘depends on last submission’ button sounds great, as it does take quite a while to get the list of jobs manually.

4

Hi Bobo, did you ever get around to changing this?

Building a tool which has dependencies in it at the moment and need a more efficient way of getting the jobID.

5

Yes, it is in SMTD in the latest 5.2 SP1 and in the 6.0 Beta.
It supports both chaining dependencies (each submission dependent on the previous), and daisy-chaining (each submission dependent on the same previous job(s)).
The IDs generated during the current session are collected in an array and can be accessed directly without querying the Repository (which was the point, since a query can take minutes on large farms).