Resolution to my MCH3601 problem

Specifying the length to retrieve as %len(data-structure) is indeed the
way to avoid this problem.

The QUSRTVUS (Retrieve User Space) API documents the Length of data
parameter as "The length of the data to retrieve.  This length must not
be larger than the size of the variable that is to receive the data..."
which equates to %len(data-structure).

Variations of this can also be found in the System API Progamming manual.
Common API Programming error 3 has to do with too small a receiver
variable, Common API Programming error 4 with using a hard coded length
of entry when stepping through list entries (but shows the correct usage
of Length when actually retrieving the list entry -- well, correct
within the confines of OPM RPG anyway which doesn't have %len).  Neither
of these examples of common errors hilight this specific coding
problem, but do show the upwardly compatible way to code the list entry
access.

Bruce

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


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