RE: User space, outfile or workfile

Scott,
>From the tone of your reply I think you feel that I was somehow stating
that your solution was inferior.  That is not the case and I apologize
if I came across that way.
As to the points made in your reply:

>      c                   eval      US_PTR += %Size(fld)
Move to next field

>This is incorrect code...   you have to advance the pointer by the
>size of the entry as returned by the API, rather than the size of the
>structure.   Otherwise, if IBM ever adds more fields to the structure,
>your code will break.

True.  I was merely using the existing example to show how it might be
done a different way.  I didn't want to take the time to provide every
detail of how to code for the API return value.

>User spaces are generally stored in auxiliary storage, whereas
variables
>are stored in main storage.  Granted, OS/400 will move frequently
accessed
>Items from aux storage into RAM in order to make them faster, and it
will
>also move data from RAM into disk if you don't have enough RAM to
handle
>everything on the system.   So, the difference is where things start --
>a user space will start on disk, and because of frequent access will be
>promoted to RAM.   Variables start in RAM, and only get moved to disk
if
>you're running out of RAM.   Consequently, variables will be faster for
>the first few accesses.

>However, in this case, he still has to read the user space, so it may
end
>up making no difference, or making very little difference.   But, I
would
>still opt on the safe side.
Like you said, the user space still has to be accessed.  The disk I/O
still occurs.  To fill the array you have to read each entry in the user
space.  With the pointer method you just process the entries as you read
them.  One loop to process through a list of fields instead of two.  I
agree the time difference is probably negligible.

>Furthermore, saying that accessing a user space by pointer is more
>"straightforward" is a strange statement to me.   You really think that
>pointer math is easier for the average programmer to understand than an
>array?

The answer here depends on the programmer.  I have tried to teach this
concept to different experienced programmers in our shop with mixed
results.  Some grasp it readily and others struggle for a little bit.
Conversely how readily was the array data structure technique grasped by
those responding to this thread?  When someone is introduced to a new
concept there is always a learning curve.  Sometimes small sometimes
large.
As mentioned above, when using the pointer there is only one loop to
process the returned fields.  Having a second loop to read through the
list of fields a second time may cause confusion to someone not familiar
with the program but knowing generally how it works.  I see the thought
process going something like "The program reads the fields from the user
space and puts them into an array then it reads the list of fields from
the array and acts on them.  Why am I reading the list of fields twice?"

>Or, is it just that I'm using new features of the language that's got
you
>thinking that it's not straightforward?  If I used a MODS instead,
would
>you like that better?
I would have made the same suggestion whether this was a data structure
array, MODS, or a series of individual arrays.  The suggestion was based
on the fact that the data was being written to a user space initially
and then needing to be acted on.  Nothing else.  It simply cuts out the
middle step.