RE: Renaming copy member data structure fields

rpg400-l-request@xxxxxxxxxxxx wrote:

>   2. Renaming copy member data structure fields (AGlauser)
>
>Now, on to my problem.  I don't like the names used in the qsysinc copy 
>members that define data structures for use with system APIs.  When using 
>these copy members in the past, I have either decided to live with the 
>arcane names or I have created my own data structures with readable names. 
> Neither of these solutions is really to my liking, as the first makes 
>code difficult to figure out later on while the second can be very work 
>intensive for large data structures.  The second method also makes it more 
>of a challenge to adapt to API format changes - perhaps this doesn't 
>really happen very often but I've already been burned by it once.

I tend to the opposite -- essentially never using the members directly from 
QSYSINC but rather using copies that I've modified as I want. I've been burned 
far more than once using QSYSINC directly and only been burned by my own when I 
tried to shortcut things. E.g., failing to obey CCSIDs or thinking "That offset 
won't change." And those would burn regardless of which version was used.

It's been especially true after OS/400 upgrades. The QSYSINC copies indeed 
often have bugs.

When using one for the first time, I copy it and then review it against API 
documentation, correcting every little bug I can find and making whatever 
structural modifications are needed to make it useful in the future. And if I 
find further bugs in testing, I correct my copy according to how IBM support 
says the API is _supposed_ to work, ignoring what the QSYSINC member seems to 
imply.

I look at QSYSINC the same way I've looked at QUSRTOOL for many years. It's 
examples to speed my understanding, NOT production code.

Tom Liotta