if a bunch of tables are located in different tablespaces (300 tables in 4 different TSs), would it make sense to run 4 reorgs and then 4 runstats in parallel? will elapse time of the whole process be less then running it consequently? just trying to decrease the maintanence window on prod. database.

Sounds good to me.

TEMP tablespaces large enough?

we use only SMS tablespaces. So am I right saying that we don't need to use tablespace option in reorg in this case? So reorg is being done in table's own tablespace without space limitation.

How will you insure that your table is reorg before runstats job gets to it if you are running in parallel?

parallel means 4 different processes on 4 different TSs at the same time. But specifically to one TS and table I will be doing reorg and then runstats. So only 4 processes will be running at a time.

I think what Cougar meant is that a reorg(online) is an asyncrhonous task. Meaning you say "do reorg" and db says "ok done". You, actually, have to wait for the reorg to complete prior to getting your stats.
Dave

True when you are doing online reorgs.
Unpredictable when you are doing offline reorgs: if the table is large enough db2 will spill to TEMP storage, even if you did not specify it. TEMP tablespaces on SMS are common, so what I meant was: do you have enough disk-space when the "worse-case-senario" becomens true: all the biggest tables per tablespace are REORG-ed simultaniously and use the same TEMP space. Do not underestimate the this possibility: large tables take longer to reorg so it may seem that the large tables wait for each other.

I guess I will have to try and see.
Thanks for your input.