Consider these settings for a process with a starter actvity, say a JMS receiver

:
Flow limit =100
Max jobs =25
There are 200 messages on the receiving queue before the process starts.
Once the process starts then what could be the statistics?
1)
Jobs in memory :25
Jobs paged to disk :100
Messages waiting on the queue :75
or
2)
Jobs in memory :25
Jobs paged to disk :75
Messages waiting on the queue :100

Thread Count is the number of BW worker threads, each of which is entitled to ru

n a job that is scheduled for execution, i.e. in the run-queue. Just because you
have the thread does not mean it actually runs as that depends on the OS schedu
ling which also depends on the actually number of available hardware threads (co
res plus hyper-threading) and on the state of the process (it could be blocked o
n IO for example). So strictly speaking even the BW worker threads only run viru
ally concurrently - how many run physcial concurrently is a matter of HW and sta
tements.
Max Jobs is number of jobs that can be in-memory and that are also entitled to r
un. So they may not run physical' at the same time as not all of them can have a
BW worker thread in your example but they run logical concurrently as BW has it
s own scheduling which will result in jobs having to give up the BW worker threa
d when they reach an asynchronous activity or they executed to many steps in seq
uence. In that it is not much different than the OS scheduling of threads on the
processors.
All of the above is also detailed in the BW documetation - there is a whole chap
ter on that - but sure it is one of the more difficult subjects.
For the JMS receiver also the acknowledgment mode comes into play. For CLIENT AC
K the number of session determines how many jobs can be created concurrently (de
fined from start to confirm activity which most times is at the end anyway). Thi
s mean you do not have to set maxJobs or flowLimit. Now let's say you use EXPLIC
IT ACK then the maxJobs and flowLimit are again important as only way to define
concurrency and thus memory footprint and other resoruce consumption. In this ca
se flowLimit=100 will suspend the BW process starter once 100 jobs are created b
ut not yet terminated. It will resume the job creation only once 1/2(=50) jobs r
un to their end. The maxJobs of 25 does result in 75 of those 100 jobs to be pag
ed to disk - which is not really a good idea (page out and page in cost) unless
you have large jobs and they are so long running that they all must be started.
That is for activationLimit equals false.
With Activation Limit equals true BW would have stopped to create jobs once it r
eached maxJobs = 25 and thus only 25 would be in memory at any time and the high
er flowLimit would be meaningless