Re: Resolution to my MCH3601 problem

Hello Martin,

You wrote:
>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.

I am sure!  That technique is correct and allows you to locate the START of 
each 
list entry.  The problem experienced here is that people are specifying the 
entry-length from the generic header as the length of data on parameter 3 of 
QUSRTVUS.  That is wrong and the source of the described woes.  The value of 
parameter 3 must be the size of the area provided in parameter 4.

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

And now your receiver is too long when you run this code on VRM430 and you run 
the risk of breaking on VRM430 when someday you modify your code to use the 
data 
in the extra space.  If you must use one code base for multiple releases then 
you must copy the smaller of the structure size or the list entry size.  Don't 
say you weren't warned!

>So: are we doing something wrong?  

Yes!

>Are IBM doing something wrong?  

No!

>Are APIs just not as future-proof as we're told?  

No!

Since your question contains a double-negative I can't guarantee that you'll 
correctly interpret a simple Yes or No.  So, APIs are exactly as future-proof 
as 
you are told.  The caveat is that they have to be used correctly -- both by you 
and IBM.

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

It is documented in the description of parameter 3 in the QUSRTVUS API 
documentation.  I accept that it could be worded better but the documentation 
is 
written from the point of view of experienced software developers and is 
intended for experienced software developers.  You and David have just had a 
learning experience that hopefully improves your basic skill set.  Evolve and 
survive  :)

Many of the IBM examples are not good from a future-proofing point of view but 
if you merely clone the examples without understanding the issues then it's 
your 
own fault.  Most people accept that software has bugs so why expect the 
examples 
to be any different?  (Note:- I am NOT defending that premise)

The ideal solution is to avoid QUSRTVUS and use a based data structure.  Then 
you avoid the issue of copying data and simply see as much as your view of the 
world allows.  That is, if your structure is 120 bytes long you only see 120 
bytes of each list entry, however incrementing the pointer by the size of the 
list entry (from the generic header) allows you to find the start of each entry 
in turn.

As an aside, this problem manifests itself most often in C programs where C 
programmers commonly increment a typed pointer and basically move the pointer 
by 
the size of the structure the pointer references.  As soon as IBM increase the 
size of the list entry the C code breaks.

For example, given a structure describing the list entry:

        typedef _Packed struct Qus_OBJL0100      
           {                                     
              char Object_Name_Used[10];         
              char Object_Lib_Name_Used[10];     
              char Object_Type_Used[10];         
           } Qus_OBJL0100_t;                     

and declari
 a pointer of that type:

        Qus_OBJL0100_t * objListEntry;

then after
        o calling QUSLOBJ to populate a user space with a list of objects
        o resolving a pointer to the user space
        o and setting the above objListEntry pointer to the first entry

you may see code like:

        objListEntry++;

which increments the pointer by the size of the structure it points to.  The 
code works as expected until the size of the list entry increases.  Then BOOM!

Regards,
Simon Coulter.

«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
«» FlyByNight Software         AS/400 Technical Specialists       «»
«» Eclipse the competition - run your business on an IBM AS/400.  «»
«»                                                                «»
«» Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\   «»
«» Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /   «»
«»                                                           X    «»
«»               ASCII Ribbon campaign against HTML E-Mail  / \   «»
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
+---
| 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
+---