It's a bit unusual (but not impossible) for multiple instances of the LOAD operator to make that much difference with tbuild.
You might also investigate simply allocating more sessions to the job but keeping the number of instances the same; e.g. QueryBandSessInfo='UtilityDataSize=Large;' is configured for this purpose by default.
Your feedback was not clear.
Which version took 4 hours, and which version took 8 hours?
I do not think you answered the question of how many sessions you are allowed to connect.
That would be the maximum number of instances you could use (because each instance has to connect at least 1 session).
Having an instance connect just one session is not ideal.
You want to achieve parallelism by having an instance control more than one session.
The Load operator does not have to use very many instances to be effective. Although performance is based on quite a few factors (CPU bandwidth, network bandwidth, disk I/O speed, number of sessions available for use, etc.).
It is really rare that you would ever need 11 instances of the Load operator. And from the original error, you do not even have 11 sessions to work with (else the orginal error would not have occurred). Thus you have <= 10 sessions to work with. That is not very many sessions to get any type of good performance.
You indicated that the job with one instance took 8 hours.
Did you try 2 instances?
I would also talk to your sysadmin to see if you can get allocated more sessions for your job.
How many AMPs are available on your system?
I think you can also get more sessions by submitting a query band with the load job to indicate to TASM that your job is a "large" job.
Talk to your sysadmin or DBA.
If you have 86 AMPs, then you have 86 sessions to work with.
But since your job terminated, with an error when running with 11 instances of the Load operator, that at least one instance could not connect sessions, this tells me that something limited the number of sessions you could use.
This could be due to TASM.
If you run tlogview on the job that failed, you will be able to see if there was an override.
tlogview -j <job-id> -f "*" -g
or you can simply do this:
tdlog <job id>
and redirect the output to a file.
If you can/want, post the output here and we can take a look.