Hi Stuart,
We don't see that here and have a few DS6.9 SP6 servers. If the engine is still managing to schedule and execute scripts on other machines, it's not an engine failure (which can happen).
Sometimes, under high load, peculiar things can happen. This is particularly a concern when,
- many remote consoles are deployed as this can result in a high background of SQL CPU utilisation
- machines aren't retired and have jobs sceduled on them. This can be an issue particularly in a migration as the engine can get very busy trying to WOL machines that no longer exist in order to execute scheduled jobs.
Also, as a general rule the SQL database recovery mode should be set to 'simple'. This stops transaction log bloat which if unchecked with throw a few spanners into your system.
If your gut feeling is that Server resource isn't a concern, do you feel happy about attaching a .bin of the job that fails with a screenshot of what task is hanging? Or you can PM me with those things and I can take a look and report back.
There is this Symantec howto which contains a vbscript 4214.vbs which is very useful in keeping your environment in order,
http://www.symantec.com/business/support/index?page=content&id=HOWTO9089