Embedded SENSITIVE DYNAMIC SQL cursor question

I've searched around but haven't found clarity to get my understanding confirmed on this.

I'm working on getting to a solution to a horrendous performance problem in a set of programs that show different views to data that changes all day that a team is working on with customers. It is important that what they see is the most currently available status of the data.

I converted the primary file read that is input to populate the subfile to an SQL cursor as the first step but it's not enough. So now I'm doing a cursor with somewhat complex join logic including a couple of common table expressions, WITH clauses, and so on.

The same data set is used in various programs that they navigate.

I have changed the first program called from the menu from ACTGRP( *NEW ) to ACTGRP( XYZ ), and I've changed most of the first programs called from there to ACTGRP( *CALLER ). I am grateful for the response I got on this forum (and/or the midrange forum) for helping me to decide on a named activation group. And THANK YOU DAVID for creating these lists and managing them!

This is the idea I'm asking for confirmation for:

Now I'm proceeding with the idea of using a service program procedure to create a SENSITIVE DYNAMIC SCROLL CURSOR. That way it gets real-time changes all day. So first time in, the SQL cursor gets created, and the code reads it start to finish to populate the subfile. When the user refreshes, the FETCH FIRST returns the "pointer" to the first row and then FETCH NEXT reads thru the cursor and I can populate the subfile from that.

That should reduce performance time, should it not?

Sorry if this is more words than necessary,

---Alan