Yep! As always it depends on the use case. I have seen great
savings and also none...
Gather data, evaluate, code and test to prove that it really
SOFTWARE ENGINEERING GmbH and SEGUS Inc.
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: [login to unmask email]<mailto:[login to unmask email]>
Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert
On 4 Mar 2018, at 09:51, Michael Hannan
<[login to unmask email]<mailto:[login to unmask email]>>
In Reply to Renato Delbrueck:
Can such a program perform a multi-row fetch?
What should be taken into account for this to work out?
Others answered well. A couple of things. Sometimes savings from
Multi-row Fetch is quoted at up to 50%. This is really useless an
misleading information. The savings are not a percentage of the
total Cursor cost at all, only a portion of the Fetch call
It is not worth the effort to code for multi-row Fetch unless you
typically have a very large number of Fetches per day especially in
Peak Hours. Also if you have only an average of 1.1Fetches per
Cursor Open (when most Fetches are a Not Found), the MRF does not
help you. You might need at least a few Fetches per Open to make
Consider this a batch Fetch might have an overhead of a 5 microsecs
(depending on processor speed). That is on a slow engine. If you
save 1 million Fetches through using multi-row fetch you might save
5 seconds of CPU. Not a lot if at a time when it does not matter.
In CICS the overheads can be about 3 times higher, if not using
The message is use your effort to code multi-row Fetch on the most
Fetch intensive processes in the installation.
I have seen a lot of MRF used where it just was not necessary, then
again not used when Fetches were really huge. Sometimes puzzling
DB2 Application Performance Specialist
CPT Global Ltd
-----End Original Message-----