Sorting and Searching Arrays Becomes More Manageable in V5R3

[MCWebsite.Staff]

** This thread discusses the article: Sorting and Searching Arrays Becomes More Manageable in V5R3 **
** This thread discusses the Content article: Sorting and Searching Arrays Becomes More Manageable in V5R3 **
This is a discussion about Sorting and Searching Arrays Becomes More Manageable in V5R3.

Click here for the article.

[msny@buckeye-express.com]

Sorting and Searching Arrays Becomes More Manageable in V5R3

** This thread discusses the article: Sorting and Searching Arrays Becomes More Manageable in V5R3 **
I modified the code a little and get a Decimal Data error. Here is my code. I get it on the increment to the array in the DO loop. My idea here is to see if I could sorta partially in the first 366 elements and leave the rest. When I remove the pointer field from the logic it works fine. I've never used pointers before so sorry for my newbie stupidity....

---

Code

[R.Cozzi]

Sorting and Searching Arrays Becomes More Manageable in V5R3

** This thread discusses the article: Sorting and Searching Arrays Becomes More Manageable in V5R3 **
The array is Packed(5,0) that you're using so the program is working as designed. You need to initialize each element to zero once you've allocated storage for it. Try this: eval %subarr(myarr: 1: 500) = 0

[BWierman]

Sorting and Searching Arrays Becomes More Manageable in V5R3

** This thread discusses the article: Sorting and Searching Arrays Becomes More Manageable in V5R3 **
Has the SORTA function been enhanced, or are we still better off using the "C" sort?

[msny@buckeye-express.com]

Sorting and Searching Arrays Becomes More Manageable in V5R3

** This thread discusses the article: Sorting and Searching Arrays Becomes More Manageable in V5R3 **
Ya that worked Bob. So when allocating storage it must have an initial value no matter the type I assume. Your example shows: D DailySales S 7P 2 Dim(3660) BASED(pArr) eval pArr = %Alloc(%Size(DailySales)*366) Did you mean 3660 elements ? Is the *366 corresponding to the array elements or the storage space based on a formula ? Can you clear this up please. Thanks for your help. Nice article.

[Guest.Visitor]

Sorting and Searching Arrays Becomes More Manageable in V5R3

** This thread discusses the article: Sorting and Searching Arrays Becomes More Manageable in V5R3 **
I can't believe RPG is getting such a ridiculous function! Why encourage such a silly programming technique as dynamic arrays, using ALLOC and REALLOC? Think about it for a moment: You implement array growth using inherently inefficient reallocation. Do you get efficient storage management in return? Noooo! at best, considering the overhead of the reallocation as well as previously allocated unused sotrage in the heap, the storage overhead is roughly three times the size of storage needed for the array data. Add in other allocs and fragmentation of the heap and it only gets worse. If youhave to put up with such disadvantages when doing things like CGI programming, you might just as well use a more productuve language like Perl. q

[David Abramowitz]

Sorting and Searching Arrays Becomes More Manageable in V5R3

** This thread discusses the article: Sorting and Searching Arrays Becomes More Manageable in V5R3 **
I will agree with this, but for a completely different reason. I've always felt that many internal array processing functions, particularly large ones, belong in a database. Consequently and with rare exception array and internal table processing is limited to relatively small sizes. The amount of memory used for such programs is negligible. Other programs are not affected when even the largest arrays are being processed. On a practical basis, it is just not necessary, nor desired, to dynamically allocate arrays. Dave

[Guest.Visitor]

Sorting and Searching Arrays Becomes More Manageable in V5R3

** This thread discusses the article: Sorting and Searching Arrays Becomes More Manageable in V5R3 **
qm: "You implement array growth using inherently inefficient reallocation" Ha, in a word -- Baloney. We're talking about the iSeries here, a relational database machine with million row tables. RAM operates on billionths of a second, disk reads on thousanths of a second. So, the bottleneck in most any program will not be reallocating memory once in a while but rather disk I/O. You could also state that division and multiplication are slower than addition and substraction so avoid division and multiplication in programs. I dynamically allocate space to an array if necessary. If you're loading a small master file into an array to speed a program up, you have to decide how big to make the array. If you don't allocate space dynamically, you have make the array size extra "big" so you never fill it. Now that's a waste of memory. You can get cute and stop filling the array if you hit %Elem(MyArray) but then you don't load some records into the array if the size of the master file increases. Imagine your fixed size array blew up because you tried to load too many elements into it, or you didn't load enough because you filled the array up. Are you going to tell the CEO, CFO, CIO that you chose to cause down time for the company because you didn't want to make the program "inherently inefficient"? There's always a technical side and business side of a program. You have to blend the two. Chris

[David Abramowitz]

Sorting and Searching Arrays Becomes More Manageable in V5R3

** This thread discusses the article: Sorting and Searching Arrays Becomes More Manageable in V5R3 **
Ringer Software wrote: If you're loading a small master file into an array to speed a program up You can load a small file into memory by using the NBRRCDS (sic) parameter on the OVRDBF command. You can also use "Table Files" to load an entire file into an array. I use both techniques for different purposes. Using the OVRDBF command means no programming changes whatsoever. Dave

[Guest.Visitor]

Sorting and Searching Arrays Becomes More Manageable in V5R3

** This thread discusses the article: Sorting and Searching Arrays Becomes More Manageable in V5R3 **
David: You can load a small file into memory by using the NBRRCDS (sic) parameter on the OVRDBF command. Yes, I love record blocking. That's a great way to speed up many programs. But that doesn't guarantee that the record you need is in memory. SETOBJACC isn't either. David: You can also use "Table Files" to load an entire file into an array. And here is my point. How big do you define that array in your program? Dim(###)? How do you find out a year from now if that definition is no longer big enough? Chris

[David Abramowitz]

Sorting and Searching Arrays Becomes More Manageable in V5R3

** This thread discusses the article: Sorting and Searching Arrays Becomes More Manageable in V5R3 **
Ringer Software wrote: But that doesn't guarantee that the record you need is in memory. Sure it does. . . . .See the code below: The entire file will be placed in memory. Dave

---

Code

[dmjae2004@yahoo.com]

Sorting and Searching Arrays Becomes More Manageable in V5R3

** This thread discusses the article: Sorting and Searching Arrays Becomes More Manageable in V5R3 **
I believe this would only guarantee that your program would need to block each time it performs a read until the entire file was retrieved into memory. In the context of using the file as a cross-reference file this could deliver some horrible performance compared to the array lookup and in fact compared to non-blocking the file.

[Guest.Visitor]

Sorting and Searching Arrays Becomes More Manageable in V5R3

** This thread discusses the article: Sorting and Searching Arrays Becomes More Manageable in V5R3 **
Dave400: I believe this would only guarantee that your program would need to block each time it performs a read until the entire file was retrieved into memory. No, the chances are "good" that for a small file, the record will be in memory, but only if doing sequential access. If the program does a SETLL/READxx, the buffering will not occur (see job log). If doing sequential access, the READ will only go to disk if the record it needs is not in memory, which is good. There is a chance though that the memory occupied by the blocked records in the transfer unit will be overwritten before the program tries to access them. Chris

[Guest.Visitor]

Sorting and Searching Arrays Becomes More Manageable in V5R3

** This thread discusses the article: Sorting and Searching Arrays Becomes More Manageable in V5R3 **
David, You missed my two questions: "And here is my point. How big do you define that array in your program? Dim(###)? How do you find out a year from now if that definition is no longer big enough?" :-) Chris

[dmjae2004@yahoo.com]

Sorting and Searching Arrays Becomes More Manageable in V5R3

** This thread discusses the article: Sorting and Searching Arrays Becomes More Manageable in V5R3 **
Chris, It sounds to me that you are intertwining the NBRRCDS on the SEQONLY of the OVRDBF and NBRRCDS on the OVRDBF. The prefetch etc applies to the SEQONLY I am not sure it applies to the OVRDBF. The NBRRCDS in that instance denotes "Specifies the number of records read from auxiliary storage as a unit and written to main storage as a unit."