Automic Workload Automation

Questions:
Is there any workaround, method, function, or hack-together to dynamically set the Fixed Value on the Runtime tab for the Maximum Runtime (MRT)?

An example is:
We would like this value to be able to be small for small file transfers, and large for large file transfers, equivalent to the byte size of the file based on our average transfer rate + a buffer to prevent false alerts.

Another Example:
This would also be helpful if a process is performing say a MONTH END run instead of a DAILY run, but using the same workflow.

Another Example:
If a process runs based on some input (file, setting, date range, etc), it would be nice to be able to dynamically increase the MRT based on foresight that the job will run longer than normal.

Anyways, examples aside, is there any way to change it through automation/script?

I would be interested in a solution for this too.  Currently we set our MRT's to the largest expectations which are our month-end and quarter-end executions.  But this setting is not of value to our daily executions.

One option we considered was maintaining two different jobs for the different run cycles since we can use calendar rules to tell us which one to use.  But we decided against this because then we would be required to maintain redundant code.

Maybe the MRT section could be enhanced to support different rules for different calendars?

If we are asking for a feature Pete, I'd say a simple :put_att that gives me the ability to set it in pre-process would be enough control.

MRT appears to be defined as [End - Start Time], not from Activation.  So this means that anything changed in the pre-process would be able to correct affect the MRT value, if a function was created or added for us to use.

To test and show this, if you put a :wait 120 in the Pre-pocess of a JOBS with an ls or dir in the PROCESS tab. Then set up an MRT of 1 minute to activate a call object to email you, the JOBS will never activate the call object because the End - Start Time will be 0-1 second.  Start Time - Activation Time will be about 120 seconds.

Anyways, yes, I want a feature if no one has any work around ideas :p

There is a script function to modify the MRT but it is a little bit tricky because you have to change the MRT from outside. You have to make a script which runs outside of the workflow but have all needed information. The script has to stop the workflow, modifies the MRT and starts the workflow again.

I do not change the MRT but a few different things. For this I have a script which activates a workflow. The workflow has a holdpoint at the start. Then the script stops the worfklow, modifies it and starts it by using MODIFY_TASK.

You can find more information about MODIFY_TASK in the documentation:
http://docs.automic.com/documentation/AE/10.0.4/english/AE_WEBHELP/help.htm#ucacpg.htm#06

I had never used MODIFY_TASK before and started playing with it today to test Tim's solution.  I'm satisfied that this can resolve this issue for us.   However I also agree with Tim that it is tricky to set up.  To successfully modify an MRT rule, the target workflow must be activated and the task you wish to modify can not have started yet.

This would be a feature request.  I need to be able to modify it at the object level.

So a JOBS in its PRE_PROCESS tab would need to be able to read information and make a determination then what to set the MRT value to.

While the  MODIFY_TASK would provide "a way".  The complexity of setting it up and having to edit it outside and before the step/job runs is a bit too much.

Additionally, what if its activated via activate_object and running perhaps in a Job group.  Now there is no workflow to modify and it becomes even more tricky.

MODIFY_TASK is using a gun to kill a fly as it doesn't include all the cases indicated by Jeremy. Plus to use it with workflows don't forget the nice anoying feature of the "generate at runtime" that is by default not set ... in the templates provided in client 0000.

I agree that this should be part of the "Attributes" that can be changed by a simple :PUT_ATT command.

This enhancement becomes more and more often indicated specially with the increase of the SLA requests from business where you need to get notifications as soon as something is out of scope. Dynamic modification of the "Runtime" attributes would fix all issues like the daily/weekly/monthly job that takes 1 to 10 times longer depending of the day of theweek or of the month.

Hope this will one day reach someone that put this on the to do list of the development.