Queueing Jobs Manually

[jhg]

If I start Job A which uses BackupSet-1 and then attempt to start Job B, which also writes to BackupSet-1, Retrospect complains that the backup set is in use and refuses to queue the job to wait for the backup set to become available.

However, if I edit Job B and add a one-time schedule entry to start 1 minute from now, while Job A is still running, Retrospect dutifully queues Job B and runs it when Job A finishes.

This is probably a feature request.  In the first situation, where I attempt to run a job for which a resource is currently in use, I would like for Retrospect to queue the job just the way it does when the job is started by the scheduler instead of manually.

[DavidHertzberg]

jhg,

If you want to submit an enhancement request, here's why and how to do it.

However I suspect that Retrospect Tech Support's answer will be along the lines of "it's already the way we'd like it to be".  Their explanation would be that anyone who submits two Immediate operations whose destination is the same Backup Set is more likely than not to have made an error.  Starting with version 8.0 in 2009, Retrospect Mac did away with Immediate operations; clicking the Backup button in Retrospect Mac generates a script scheduled for the current date-time with whatever source-destination-etc. you specify.  A few weeks ago, doing an experiment for other purposes, IIRC I clicked the Run button in the Scripts panel to schedule the same script twice with exactly the same source-destination-etc..  Retrospect Mac 16 wouldn't submit the results of my second Run click, but would do so if I added  a Repeat Never schedule of the same script 2 minutes later.  That smells to me as if the engineers took the trouble to convert the Retrospect Windows behavior you don't like so that it works the same way in a dramatically-revised GUI.  If I paraphrased H. L. Mencken to say "Nobody ever went broke underestimating the competence of backup administrators", I suspect the engineers would say they already have the equivalent statement on a wall plaque in Walnut Creek CA.

[x509]

On 8/22/2019 at 12:08 PM, DavidHertzberg said:

jhg,

If you want to submit an enhancement request, here's why and how to do it.

However I suspect that Retrospect Tech Support's answer will be along the lines of "it's already the way we'd like it to be".  Their explanation would be that anyone who submits two Immediate operations whose destination is the same Backup Set is more likely than not to have made an error. 

"We'd like it to be."  David, you are probably right, but it you are, that's appalling.  Retrospect exists to solve customer problems.  One of those problems is the need to do what the OP described.  In effect, "set it and forget it."  I have run into the same problem many times, and Retrospect's behavior here is annoying.  The OP definitely needs to submit an enhancement request that includes a clear rationale for why he wants this new or changed feature.