Re: Key field info

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

Hi Tony,

> Also, I don't see a way of knowing how many fields are returned from
> the QUSLFLD API.  I currently have a DS based on a POINTER to the user
> space, and I increment the pointer after each field retrieval to the
> subfile.

Both of these APIs use the generic "User space format for list APIs".
More information about that is at the following link:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/info/apis/usf.htm

Basically, the generic header tells you everything you need to know to
traverse the list.  It contains 3 critical fields:

Offset 124, 10I 0, "Offset to list data section"
Offset 132, 10I 0, "Number of List Entries"
Offset 136, 10I 0, "Size of each entry"

At the start, you add the first number ("Offset to list data section") to
the pointer that QUSPTRUS returned.  This results in a new pointer that
points to the first entry in the list.

To get to each subsequent list entry, you need to add the 3rd number
("Size of each entry") to the pointer...

The total number of entries that you want to read is specified by the 2nd
number ("Number of List Entries")

Pretty much every "list" API uses this same format.  The only difference
between the various list APIs is what data is found in the list entries
themselves.


> I test the first character of the field name for containing
> an alpha character, and if it does not, I assume I have reached the
> end of the loop.  Kind of messy, but it works.  Is there a better way?

Checking the first character of the field name is not a good solution.
The problem with that solution is that you don't know what random garbage
data you'll pick up in memory -- it might be a valid numeric character,
and it might not.   Your code may work most of the time, but on occasion
fail.

The best way to do it is to use the method I outlined above, where the
"Number of List Entries" field tells you how many to read.