Handling large ResultSets

Question

I want to retrieve about 30 rows at a time from our DB2/AS400. The table contains over 4,000,000 rows. I would like to begin at the first row and drag 30 rows over the network. Then get the next 30 if the user requests them. I know the answer is to use cursors but I cannot use these statements within my code on the AS400. Websphere Studio allows me to create jsp's using a <tsx:repeat> tag to iterate over the result set but the instructions on using these is pretty vague.
Can anyone direct me to some informative sites with examples or recommend a way to go about this?

Answer 1

That would be fantastic and my ideal approach but the
manager of the department wants to keep the
functionality of what they presently use and he and
his team wrote 20 years ago written in RPG with
loverly green screens. They scroll 10 rows at a time,
jump to the top or the bottom of of the table and
type in the first two three or four letters of the
search parameter and get the results which can also
be scrolled. Some tables are even worse, one contains
over 10 million rows.We have a lot of those green screen applications in our AS/400 systems too. So I can tell you (and your manager should be able to confirm this) that the "subfiles" that they scroll cannot contain more than 9,999 records. But in real life, even in our AS/400 environment, nobody ever starts at the beginning of our customer file (which does have more than 9,999 records) and scrolls through it looking for something. They put something into the search fields first.
So displaying the first 10 records of the file before allowing somebody to enter the search criteria is pointless. And jumping to the end of the table is pointless too -- unless the table is ordered by date and you want to get recent transactions, in which case you should be sorting it by descending date anyway. My point is that those AS/400 programs were written that way because it was easy to write them that way, not necessarily because people would ever use those features. When you have hundreds of tables (as we do), it's easier just to copy and paste an old program to produce a maintenance program for a new table than it is to start from scratch and ask the users what they really need. That's why all the programs look alike there. It's not because the requirements are all the same, it's because it's easier for the programmers to write them.
Here's another example: Google. When you send it a query it comes back with something like "Results 1 - 10 of about 2,780,000". But you can't patiently page through all of those 2,780,000 results: Google only saves the first 1000 for you to look at, and won't show you more than that.
So I agree, a program that's simply designed to let somebody page through millions of records needs to be redesigned. If you want to write a generic program that lets people page through small files (less than 1000 records, let's say) there's nothing wrong with that, but your users will curse you if you make them use it for large files.