Scott,
You are a true blessing. This is what I was gleaning from the dozens of
different examples, the replies to my question, and the vague memory of an
example you gave that I cannot find on the interwebs today. This was the
exact simple explanation I needed to move this forward. Yep, I'll
encapsulate away all the "ugly" stuff (I think its quite beautiful, but my
coworkers might disagree). Once I get this done I'll write up a blog post
or something. Maybe David will be gracious enough to use the midrange.com
blog?
Once you wrap your head around it, it really isn't that bad..... Once you
wrap your head around it. Kind of like recursion... another of my
personal favorites. :)
Thank you for taking your time to help me out today.
Bryce Martin
Programmer/Analyst I
570-546-4777
Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
10/08/2010 02:21 PM
Please respond to
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
To
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
cc
Subject
Re: Based data structure as dynamic array
Hi Bryce,
On 10/8/2010 12:15 PM, Bryce Martin wrote:
I know that there is a way to get past the 32767 DIM limit and rely
totally on the 16MB space limitation.
Ohhhhh... _that_ is what you're looking for. (I read the whole thread,
and you said you didn't want an array, you just wanted to grow your data
structure... and I kept thinking you wanted to add subfields that aren't
repeating like an array...)
You actually _do_ want an array (or perhaps a MODS) but you don't want
RPG to implement the occurrences... _you_ want to implement the
occurrences yourself so that you don't have the 32767 limit.
For me, it's easiest if I think abotu what an array (or MODS) really
are... I mean, how does the computer view them? I mean, variables
don't really exist -- they're just to make it easier for people.
Likewise, array indexes, don't really exist... they're just to make
things easier for people.
An array is a thing where the same size/type fields are repeated in
adjacent memory... that's all it is... So you asked for:
D MasterList_T...
D DS qualified based(TEMPLATE)
D Customer...
D 6s 0
D Rank...
D 6s 0
If you did use an array (just bear with me) you'd code it like this:
D myMasterList...
D DS likeds(MasterList_T)
D dim(5)
That means that each entry in your array is (6+6=) 12 bytes long. So
this being an array, the space in memory would be organized as follows:
bytes 0-11 = first element
bytes 12-23 = second element
bytes 24-35 = third element
bytes 36-47 = fourth element
bytes 48-59 = fifth element
Hopefully you see... they are just 12 byte chunks located in consecutive
memory locations. The second element of the array is
%size(MasterList_t) bytes later in memory than the first one. The third
element in the array is %size(MasterList_t) bytes after the second one,
and so on...
in other words... the formula is:
memory location = (elementno - 1) * %size(MasterList_t)
If I wanted to get the first element, I'd say 1-1=0. 0*12=0. Start at
offset 0 from the start of the array, and I have the first element.
If I wanted to get the fourth element, I'd say 4-3=3. 3*12=36. The
fourth element is 36 bytes from the start of the array -- in other
words, it's at offset 36. (Or byte position 36 if you like.)
So with that, why do we need a dim? Who cares about the DIM?
Redefine myMasterList as follows:
D p_WholeArray s *
D p_OneElement s *
D myMasterList ds likeds(MasterList_t)
D based(p_OneElement)
Now let's say we want to have 50 elements in the array:
/free
max = 50;
p_WholeArray = %alloc(max * %size(MasterList_t));
If I want to put data into element #42 (since that is *the* answer) I
could do:
x = 42;
p_OneElement = p_WholeArray + (x-1) * %size(MasterList_t);
myMasterList.Customer = 123456;
myMasterList.Rank = 100001;
If I wanted to test the rank of element 10, I could do:
x = 10;
p_OneElement = p_WholeArray + (x-1) * %size(MasterList_t);
if (myMasterList.Rank > 123456);
... do something...
endif;
If I later decided that 50 elements is not nearly enough, I could extend
my array, too... maybe I want 50000 elements (more than 32767!) I could
do this:
max = 50000;
p_OneElement = *null;
p_WholeArray = %realloc( p_WholeArray
: %size(Masterlist_t) * max);
Note that the existing entries (such as #42) will still be in my array
data... but the system may have changed the address in memory that they
are stored at. (The offsets will be the same, but the starting address
might not.) Therefore, I set p_OneElement to *null, that way I won't
accidentally use that area of memory (which is no longer valid.) It
just makes bugs in my program easier to spot...
Now, just as before, if I want to read element #42 (which, again, should
still be there) I can do this:
x = 42;
p_OneElement = p_WholeArray + (x-1) * %size(MasterList_t);
msg = '#42 is for customer ' + %char(myMasterList.customer);
But now if I want to access element #49876, I can do this:
x = 49876;
p_OneElement = p_WholeArray + (x-1) * %size(MasterList_t);
myMasterList.customer = xyz;
myMasterList.rank = pdq;
I _do_ recommend encapsulating as much of the pointer logic as possible
into a service program, and subprocedures.... I didn't do it in this
message, because I wanted to teach you how it works, not write the code
for you :) (And because I'm short on time, and this message already
took more than 30 mins to write!)
-SK
midrange.com
