|
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.