Resolution to my MCH3601 problem -- RPG400-L

Jim,

If the coder wanted to use the new fields in the enhanced data structure
then they would need to make appropriate coding changes and recompile.
But if all they wanted to do is use the same fields in the new release
as they did on the previous release(s), then no change or recompile is
needed.

Basically List APIs provide a common header which provides information
on the list returned.  This information (which is documented in the
System API Reference under Programming Tips for Using OS/400 APIs: User
Space Format for List APIs) includes things like the status of the
information in the list (Complete, Incomplete, Partial), the offset to
the first list entry, how many list entries are in the list, how big
each list entry is (1), etc.

The problem being encountered here is that the program was correctly
using the "how big is each entry" to move from one entry to the next,
but the program was inadvertently also indicating that it had allocated
storage of "how big is each entry" in terms of where to return the list
entry.  As an example, in some previous release a program used a List
API that, at that point in time, returned 10 bytes per list entry and
so the developer coded:

DMyListEntry      s             10
DMiscOther        s              5
DMiscData         s            100

Now a new release comes around and the API List entry size has been
changed to 70.  The developer is correctly using '70' to get to each
list entry, but has mistakenly also told the QUSRTVUS API that 70 bytes
of storage are allocated to MyListEntry (when in fact only 10 are) so
when the program gets the List entry data the contents of MiscOther and
MiscData get overwritten (2) by the List entry data.  As we have no idea
what MiscOther and MiscData might be used for it's rather difficult to
guess what may occur (but we know at least one program that experienced
MCH3601).  The call to QUSRTVUS should have used %len(MyListEntry) rather
than '70' (Size of API list entry).  Then all would have been OK.

(1) I simplify a bit here as there are also List APIs that return
variable length List entries, and in that case the Size of each entry
in the common header is 0 and the actual size of a given entry is part
of the entry.  Using this variable size of entry still however provides
upward compatibility.

(2) Again I simplify in that we really cannot say for sure that MiscOther
and/or MiscData will get overlayed by the API List entry data.  Just
because the RPG developer defines two standalone fields contiguously in
the D specs does not necessarily mean that's how they will really end
up being allocated in the *PGM.  The "extra" 60 bytes in my example
could just as easily overlay a file control block, unused storage, or
any old variable.  What we can say for sure is some storage just got
written to that was not really intended to be written to -- how that
error might manifest itself later in the program is anybodys guess.

Hope this helps,
Bruce

>
>Bruce,
>
>From what I understand of this tread, never coding it myself, even if it
>was coded as suggested, wouldn't the program still have to be recompiled
>to include the new structure as described in the header file?
>
>So wouldn't the change to the API need to be in the APIs by release?
>
>Or is there something I'm not understanding about the issue.  I have started
>to use some API's myself and this topic is of interest to me.
>


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---