Improve CRUISE restore execution time

Improve CRUISE restore execution time by adopting multi I-Stream and multi ECB processing.

CRUISE Restore consists of 3 stages:
1. TAPE Rollin
2. Address Exchange (FAD Exchange)
3. Fixed Address Exchange (FAD Exchange Part TWO)

1. Tape Rollin (Need changes):
The initial phase where CRUISE is reading records from tape and filing them to DASD (tape roll in) is multi-threaded However, this first tape “roll in” phase appears to be running on 1 I-stream only. Even with 15% CPU it was crawling along no faster than the usual 3-5%. We reconfigured the test system with 1 I-stream so it would be able to use the full allocation of MIPS. With that CRUISE took off and was able to continue and complete the testing. This is one potential area for investigation and improvement (Change it to run on multiple I-Streams and Not a single I-Stream).

2. Address Exchange (FAD Exchange)
Following the tape “roll in” phase, there is a phase called address exchange or “fad exchange” where old imbedded file addresses in the restored blocks are replaced with new file addresses where the data copied to. This “fad exchange” phase is actually comprised of two parts internally. In “part one” of the fad exchange, the old FROM address references in new pool records are replaced by the new pool address where the old data was restored. This part is multi-threaded and is load balanced among I-streams. This is why this part takes up a comparatively short time.

3. Fixed Address Exchange (FAD Exchange Part TWO)(needs Changes):
In “part two” of the fad exchange the FIXED file blocks that were originally copied to POOL addresses references (or TOP as CRUISE calls it). This part is handled by a single ECB, which by definition implies the process is running on 1 I-stream. This is a serious bottleneck, but how serious it depends on the data profile.
If the database is NOT TOP Heavy, meaning that we have a small number of FIXED FILE Records but large number of POOLS, the TOP address exchange did not have a big impact on the overall restore time. Both sets of “fad exchange” completed in an acceptable time period.

On the contrary if it is TOP HEAVY meaning we have more Fixed records than pool records then the restore came to a crawl.

IBM should look into changing the above process into a MULTIPLE ECB's process and not a Single ECB process as it is currently set up.
In Addition it would be a good idea that instead of restoring to pool (the Fixed File Records) and then have the FIXED FILE exchange execute, it would be a good idea to at least give the OPTION to Restore directly to Fixed (To be used for test systems only) but make sure that the DEFAULT is always set to restore FIXED Files to POOL.