RE: Resolution to my MCH3601 problem

["McCallion, Martin" <MccalliM@xxxxxxxxxxxxxxxx>]

Simon Coulter  wrote:

> I was about to write very much the same thing.  It bears 
> repeating.  If you 
> write your code correctly you are shielded from API changes 
> unless you actually 
> care about the newly available data.  The APIs are designed 
> to be extndable in 
> an upwardly compatible manner.

I'm not so sure.  We had a very similar situation recently, but between
V4R3 and V4R5, and for the list fields API.  As I understand it, both we
and David were using the APIs as recommended: get the generic header
from the user space; start reading your data using the start of data
offset and entry length  from the generic header; continue reading it by
incrementing the offset by the entry length.

Our program was compiled at V4R3 using the relevant /COPY from QSYSINC
for the data structure to receive the returned data; all perfectly
standard stuff.  But when we ran it at V4R5 we got the the dreaded
MCH3601.  Recompiling at V4R5 fixed it, even with a target release of
V4R3, because the V4R5 QSYSINC member is picked up, and it defines the
longer data structure.  It can also be fixed by specifying the length to
retrieve as the length of the V4R3 data strucuture (though you still
have to increment by the entry length, of course).

So: are we doing something wrong?  Are IBM doing something wrong?  Are
APIs just not as future-proof as we're told?  I think that always
specifying the length to retrieve as %len(data-structure) would prevent
it ever happening, but I don't think that's documented in the
recommended procedure.

Cheers,

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