Frank,
After careful examining of your DISPINFOC1 program I should say that
probably you misunderstood the idea of using user space.
Currently your program is not simply inefficient, but it is
"dangerously" inefficient in case you apply it to display files having
really big number of fields.
I had a look at our vendor's system and it has DSPF-s with hundreds
fields. By the time you are retrieving field nr. 300, you will call
API 600 times and will step 45000 times from one field to the next
one.
What was advised is the approach that I use in all cases where your
program is called in the same way as in your case:
1. Give me first;
2. Give me next;
3. Give me next;
.....
N. Give me next.
In this case on the first call program gets ALL the data required and
places it into the user space - possibly in a structured way. If you
are returning X numbers and Y strings, you just define a structure and
place these structures one after another into the user space (in your
case structure can be FieldData_t). Additionally in the beginning of
the user space I place 2 integers: one keeps a length of actual data
(or you can keep total number of data units) and a second points to
the first yet unsent data unit.
So after the first call (give me first) you fill the user space by a
number of FieldData_t structures (for all fields). And put the 2
integers in the beginning appropriately. Then you send out the first
structure and increment the pointer to the first unsent structure.
When you get "give me next" call, you do not call QDFRTVFD any more!
You rather get the user space and send away the first unsent structure
and increment the pointer. If the pointer to the next reached the end,
you inform the caller about that with the last structure.
This is one of the possible solutions using user space.
On Wed, Sep 17, 2014 at 2:13 PM, Frank Kolmann <fkolmann@xxxxxxxxx> wrote:
Hi
Thanks Gary and Charles for your suggestions.
FWIW I have updated the site with 2 additional versions, one using User
Space the other as C module.
The module was a bit harder to code because the C code remained in the
ACTGRP so I needed to have a CLLE to do a RCLACTGRP.
Regards
Frank
midrange.com
