Changing priorities and runtime characteristics can help some...
As CharlieBrowne mentioned, in light of the "reduce the down time" part of the question, there wouldn't seem to be any advantage to moving into an interactive subsystem nor even to changing priorities or other job attributes.
"Down time" somewhat implies lack of competition for resources from interactive jobs. If other jobs aren't taking resources away, then there aren't any resources to add that will help. Timeslice for batch is already much higher by default than for interactive for example.
If "down time" is the actual problem, then improving batch programming would be a better way to go. But without knowing where the time is spent in the batch jobs, it's guesswork on what might be changed.
Your statements are confusing.
You want to reduce down time and yet you are asking if you can run some interactively.
I am assuming when you say reduce down time, that would be the period of time all users must be off the system.
Along with the suggestions alrady made, you can look into some jobs simutaneouls from different job queues.
Also look at moving memory to a different pool at the start of the job and reseting it at the end of the job.
The main thing I beleive to is do a good analysis of exactly what is running and how long each step is taking. Then, determine why jobs run so long and see what you can do to impove performance with coding changes. This may be more logical files, ot a host of other possibilities.
You also want to determine which of these jobs must have the users off the system. You may find that only a small portion of processing is required on a dedicated system.
Bottom line is you have to understand what is happening and why.