DB2 allows a calling program to receive an entire result set from a stored procedure, by specifying something like "FETCH xxxxxxx FOR 500 ROWS INTO array". It's my guess this doesn't really have any effect on the way the cursor actually performs and is simply a way to transmit more data between calling program and SP. Since the calling program and SP run in different address spaces, the savings are simply due to fewer address space swaps.
Please comment.

the quote below comes from What's New in db2 vsn 8 (which is where you can find Figure 7, if you are so inclined)
, which is when multi-row fetch.... was introduced.
There is more in the
DB2 UDB for z/OS Version 8 Technical Preview, a Redbook found here
as well as this Redbook:
DB2 UDB for z/OS Version 8: Everything You Ever Wanted to Know, ... and More
found here


Multiple fetches and inserts allowed within a single SQL statement
You can enhance the performance of your application programs by using multiple-row FETCH and INSERT statements to request that DB2 send multiple rows of data, at one time, to and from the database. Using these multiple-row statements in local applications results in fewer accesses of the database. Using these multiple-row statements in distributed applications results in fewer network operations and a significant improvement in performance. Figure 7 illustrates the difference between a series of single fetches and a single, multiple-row fetch operation.

"Using these multiple-row statements in distributed applications results in fewer network operations and a significant improvement in performance" would seem to support what I said. If this were an advantage to the way the cursor performs, why wouldn't it be offered in a conventional batch DB2 program?

You have a different/new interface. The precompiler has to support that in order to generate the respective constructs in the host language.

If you have DB2 Vsn 8 (or higher), whether on mainframe or pc, you have multi-row constructs available.

There is no advantage to the way cursor performs. The benefit is you would perform far less fetches than you currently do. And, it is available for use in a conventional batch DB2 program.

Dave

This applies to a distributed client application calling a stored procedure, but not one stored procedure calling another stored procedure if both stored procedures are on the same physical server. Same applies to a batch program running on the database server.

Some, of course, will complain about WOW Gold the result, including those desperados in the stock exchange, the crave for any type of shock, however cynically orchestrated to Buy WOW Gold Japan from its economic and financial lethargy jerk. There are many reasons to doubt that Mr. Kan has the charisma and the ability to re-energize the country. He has failed to use the campaign to light on the need for final fantasy gil. He is WOW Power Leveling still not sufficient to achieve rival parties, the Aion Gold parliamentary havebeen overcome, he lost face for the DPJ Upper House majority in July.

In other words, I can't use this feature in a batch DB2 program that calls a DB2 module. I tried it in a batch COBOL program that invoked a COBOL stored procedure. It was pretty disappointing..... due to address space swaps.