Performance issue: starts during backup and continues after backup

I'm running a conversion job with a dozen programs reading and writing rows
with SQL using full commitment control. The job takes about three hours
when it runs through the day or during the early evening.

If the job runs through the daily save-while-active backup (a two-hour
process overnight), the job slows to a crawl *even after the backup is
complete*, sometimes running for more than 12 hours and apparently not
taking a lot of CPU (but I don't have performance tools to confirm that
assertion). There are no unexpected errors in the job log (just a bunch of
duplicate row messages early in the job) and we're pretty current on V7R3
PTF's. I'm COMMIT'ing on a regular basis in every program. I have not
been advised that the backup job is taking any longer (meaning it's taking
longer for SAVLIB to reach a checkpoint). I get a dozen 1.5 GB journal
receivers generated by the job. I'm also running some intense accounting
jobs (PF/LF database access, also journaled and committed) concurrent with
the backup and have never heard of any performance issues. My input data
is read-only from production files in read mode. I don't have indexes or
LF's but there are MTI's (50 spread over 10 tables).

Not running the job during the backup window or scheduling the job after it
completes are the obvious answers but my end-of-day is usually around 0100
and when you add a two-hour time zone difference into the mix, I'm ready to
run another test just as the backup is getting warmed up.

I can come up with three possible causes: the interaction of the MTI's; SWA
operation or something in the SWA backup continues to look for checkpoints
even after the backup is complete; and the system ASP (when temporary
objects like MTI's live) is filling up.

Solving the MTI issue is easy: create permanent indexes and re-IPL; plan B
is to delete the tables and that will kill the MTI's. If it's a SWA
behavior, I'm back to considering the obvious answers. Looking at SQL
performance statistics is probably a smart move too.

I'd be grateful for insight or suggestions.

Thanks!