|
Scott,
Interesting point about the potential MCH0601 error.
Here's another variation on your examples.
c eval p_ListEntry = p_ListHeader + DataOffset
- EntrySize
c for EntryNo = 1 to NumEntries
c eval p_ListEntry = p_ListEntry + EntrySize
c*** ... at this point, the JOBL0100 data structure contains
c*** ... one of the entries of the list.
c endfor
Keith
----- Original Message -----
From: "Scott Klement" <klemscot@xxxxxxxxxxxx>
To: <rpg400-l@xxxxxxxxxxxx>
Sent: Thursday, May 20, 2004 3:58 PM
Subject: Opinions Wanted: List API loop logic
>
> First, some background:
>
> In this morning's "Club Tech iSeries Programming Tips" newsletter, I
> listed the following code snippet:
>
> c eval p_ListEntry = p_ListHeader + DataOffset
>
> c for EntryNo = 1 to NumEntries
>
> c*** ... at this point, the JOBL0100 data structure contains
> c*** ... one of the entries of the list.
>
> c eval p_ListEntry = p_ListEntry + EntrySize
> c endfor
>
> This code is intended to run through a list of entries in a user space as
> a demonstration of how to use the list APIs.
>
> Now, because I have my pointer incremented at the end of the loop, it'll
> always do it one extra time. Barbara tells me that it's possible that
> p_ListEntry could be set to an illegal location, causing an MCH0601 error.
> (Before reading her note, I had thought that as long as I didn't use the
> data that the pointer points to after the loop ends, I was safe.)
>
> Even if the user space is set to auto-extend, it could still cause a
> problem because there's a limit to how large a user space might be, and I
> might happen to hit that limit exactly. (okay, it's not all that likely,
> but still possible...)
>
> Now my question:
>
> Which of the following code samples do you think is the best way to do it,
> and why?
>
> This is the way I used to write this sort of loop, but I've found that
> maintenance programmers don't like the way the pointer logic works, it
> confuses them, plus it's ugly when wrapped to two-lines:
>
> c eval p_ListStart = p_ListHeader +
DataOffset
>
> c for EntryNo = 1 to NumEntries
> c eval p_ListEntry = p_ListStart +
> c ( EntrySize * (EntryNo - 1) )
>
> c*** ... at this point, the JOBL0100 data structure contains
> c*** ... one of the entries of the list.
>
> c endfor
>
>
> Here's another alternative, where the pointer work is done at the start of
> the loop... but since it already starts on the first entry of the list,
> it's necessary to skip the pointer math the first time through. I don't
> know how intuitive it is to do it this way:
>
> c eval p_ListEntry = p_ListHeader + DataOffset
>
> c for EntryNo = 1 to NumEntries
>
> c if EntryNo <> 1
> c eval p_ListEntry = p_ListEntry + EntrySize
> c endif
>
> c*** ... at this point, the JOBL0100 data structure contains
> c*** ... one of the entries of the list.
>
> c endfor
>
> Finally, here's a similar example to the last one, except that it sets the
> first entry inside the loop as well as the others:
>
>
> c for EntryNo = 1 to NumEntries
>
> c if EntryNo = 1
> c eval p_ListEntry = p_ListHeader + DataOffset
> c else
> c eval p_ListEntry = p_ListEntry + EntrySize
> c endif
>
> c*** ... at this point, the JOBL0100 data structure contains
> c*** ... one of the entries of the list.
>
> c endfor
>
> So, what does everyone think? Which one is the most intuitive of the
> bunch? Or, does anyone have a better idea?
>
> Thanks!
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
>
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.