Re: Sorting a user space -- RPG400-L

I am using a list api to fill a user space for a display program.
Apparently they do not support any sorting.  I suppose I could originally
load into an array, then SORTA that, then load the subfile.  Anything
easier?  Not that the above process is hard.  Just don't want to overlook
the obvious.

One of the problems with SORTA is that you have to hard-code the size ofeach element when you define the array. That's often a show-stopper forme, since the API will return an "entry length" field, and there's noguarantee that it won't be different every time you call the API.

Another problem with SORTA is when you have different fields that you needto sort by. If it's a "flat" array, that's not usually a problem, but ifit's an array of "records" and you need to be able sort by differentfields in those "records" you run into problems, since to do that withSORTA you have to create an "overlay array" in a data structure -- and themaximum size of a data structure is 64k. It doesn't take long to exceed64k when you're looking at data from a list API.

I've recently written my first draft of an article for iSeries NEWS thatcompares the different sort methods, and I had a heck of a time usingSORTA to sort anything but a very small array. Though, the performance(at V5R3, with %subarr) was very good.

The QSORT API doesn't have any of these problems. With QSORT, the lengthcan be a variable, you can sort by different fields, it doesn't have anypractical size limitation.... QSORT's speed is about the same as SORTAon a small array, and a little bit better than SORTA on a larger one.

Another option is the QLGSORT API, but I wouldn't recommend it since it'sboth slower and more awkward to use than QSORT. It does have bettercontrols for national language support than QSORT, and it's available toOPM languages which might be a plus to some people. But other than that,there's really no reason to use it instead of QSORT.

I also tried other methods that I wouldn't recommend for this project. Atemporary file with SQL worked okay, but nothing near the speed of QSORTor SORTA. If you have to read it from a file, SQL is the way to go, but ifthe data is in a user space or memory, it doesn't make sense.

Using a keyed data queue, and using a user index were the other twomethods I tried. Their performance was, frankly, pathetic by comparisonto the other methods. They were also much more complicated to code thanthe other methods, so I really wouldn't recommend them.

Unless your data is simple enough to use with SORTA without any hassle,I'd use QSORT.