× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



> I was just pointing out some things about the technique, since many
people who 
> read this list will see the ALIGN keyword, and the Filler field and 
> they'll think that they're required.  Since this stuff is posted
publicly 
> and available to every search engine, it makes sense to point these
things 
> out so that people aren't misled.

Fair enough. I'll be more accurate in the future OR make sure I use
pseudo-code to explain an idea.

>> And the filler is necessary - at least on the compiler I use. It
>> complains about alignment otherwise.

>Are you sure?  I tried it with a V4R4, V5R1, V5R2 and V5R3 compiler,
and I 
>did not have any problems.

>(Plus, it doesn't make sense, since the filler has nothing to do with
how 
>the field is aligned, the OVERLAY controls that)

A quick test of the same example I posted agrees with you - the filler
is NOT necessary. It must have been other pointer issues that I
encountered elsewhere to lead me to believe it was necessary. And
looking at it differently, you're right that the OVERLAY is controlling
the alignments.

Always good to avoid wasting space

Best wishes

JPW


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Wednesday, 14 September 2005 8:23
To: RPG programming on the AS400 / iSeries
Subject: RE: Sorting a user space


> Why 2047? I could make the PtrAry as large as I would like I think.
And
> if I ran out of room, I could use a file instead of the table -
although
> it would be slower.

Actually, I'm wrong.  If your array had a name (which it doesn't) then 
it'd be limited to 65535 bytes, and since each element is 32 bytes long 
you'd have a 2047 limit.

But, since it's unnamed, it doesn't have that restriction.  My mistake,
I 
looked at it too quickly.


> And the filler is necessary - at least on the compiler I use. It
> complains about alignment otherwise.

Are you sure?  I tried it with a V4R4, V5R1, V5R2 and V5R3 compiler, and
I 
did not have any problems.

(Plus, it doesn't make sense, since the filler has nothing to do with
how 
the field is aligned, the OVERLAY controls that)


> I think you're right about the Align verb though - it's just hanging
> there.

I tested it without that keyword on V4R4 and later as well, and the 
keyword had no effect.


> And the point was the idea - not necessarily my demonstration of
perfect
> syntax - I just typed this off the top of my head - after a glance at
> some other code. In this case - it's the idea of using pointers to the
> data in the user space as data itself that can be manipulated as any
> other data can be.

It's a good idea, and is probably the best solution if you need to be
able 
to sort a list where the entries can all have different lengths.  I was 
just pointing out some things about the technique, since many people who

read this list will see the ALIGN keyword, and the Filler field and 
they'll think that they're required.  Since this stuff is posted
publicly 
and available to every search engine, it makes sense to point these
things 
out so that people aren't misled.

Please don't take it personally.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.