Hi,
well ... tons of questions ... some of them would be better answered by migration specialists that have used SPLITTED_LOAD in migration projects. Let's try anyways.
The default for DB6LOAD_CPU_PARALLELISM is 4 in current R3load versions . This should be for the CLI LOAD into the temporary tables. If you fell that you have free CPU resources for the LOAD FROM cursor, you can try to set DB6LOAD_SPLITTED_CPU_PARALLELISM to a somewhat higher value.
I do not advice to change DB6LOAD_DISK_PARALLELISM andDB6LOAD_INDEXING_MODE for SPLITTED_LOAD. Only for sequential LOAD of data pieces into one table DB6LOAD_INDEXING_MODE=2 is sometimes beneficial. You can set DB6LOAD_DATA_BUFFER_SIZE to a fraction of your memory available in UTIL_HEAP . Increasing UTIL_HEAP explicitly while your R3load is running may also be a good idea. For productive database UTIL_HEAP=AUTOMATIC is a good setting but for LOAD allocating some memory explicitly is a good idea. If UTIL_HEAP is large enough LOAD should be able to pick a good default for DB6LOAD_DATA_BUFFER_SIZE automatically.
Since SPLITTED_LOAD is using LOAD anyways you can ignore DB6LOAD_FORCE_LOAD.
A lot of useful hints are already contained in the note mentioned at the beginning. For example using INTRA_PARALLEL=YES is a good idea for the SPLITTED_LOAD merge phase. Also putting the temporary tables into a seperate tablespace using DB6LOAD_TEMP_TBSPACE is a good idea.
Thats almost all I know about SPLITTED_LOAD. Hope other can provide more hints...
Regards
Frank