RE: Renaming copy member data structure fields

Sorry if this is a silly question, but I've only been working on an 
iSeries system for a year and a bit.  How exactly does one determine API 
changes when a new version is announced?  Is there a specific way in which 
IBM announces such changes, or do you have to compare your copy books to 
the new info on the new version's information centre?

I really hope it's not the latter :)
Adam





"Holden Tommy" <Tommy.Holden@xxxxxxxxxxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
16/03/2006 03:12 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
"RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: Renaming copy member data structure fields






APIs don't generally have massive changes....I usually generate my own
copybooks.  The key is when planning an OS upgrade check for API
changes, if there are any then be proactive and make a copy of your
existing copybook & make the changes prior to the upgrade.  You'll also
need to check your programs that use the copybook for recompiles anyway
so it's not like you're doing a lot of unnecessary work.

Plus This:
USHeader        ds 
HdrUserArea                   64a 
HdrHdrSize                    10i 0 
HdrStrLvl                      4a 
HdrFormat                      8a 
HdrAPIUsed                    10a 
HdrCrtDate                    13a 
HdrInfoSts                     1a 
HdrSizeOfUS                   10i 0 
HdrOffsetToInp                10i 0 
HdrSizeOfInp                  10i 0 
HdrOffsetToHdr                10i 0 
HdrSizeOfHdr                  10i 0 
HdrOffsetToDtl                10i 0 
HdrSizeOfDtl                  10i 0 
HdrNumberOfDtl                10i 0 
HdrEntrySize                  10i 0 

Looks much better than this:
DQUSH0100         DS 
D* 
D QUSUA                   1     64 
D* 
D QUSSGH                 65     68B 0 
D* 
D QUSSRL                 69     72 
D* 
D QUSFN                  73     80 
D* 
D QUSAU                  81     90 
D QUSSGH                 65     68B 0 
D* 
D QUSSRL                 69     72 
D* 
D QUSFN                  73     80 
D* 
D QUSAU                  81     90 
D* 
D QUSDTC                 91    103 
D* 
D QUSIS                 104    104 
D* 
D QUSSUS                105    108B 0 
D* 
D QUSDTC                 91    103 
D* 
D QUSIS                 104    104 
D* 
D QUSSUS                105    108B 0 
D* 
D QUSOIP                109    112B 0 
D* 
D QUSSIP                113    116B 0 
D* 
D QUSOHS                117    120B 0 
D* 
D QUSSHS                121    124B 0 


Thanks,
Tommy Holden


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of
AGlauser@xxxxxxxxxxxx
Sent: Thursday, March 16, 2006 1:29 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Renaming copy member data structure fields

Hi all,

First I would like to thank the list for the many tidbits I've found 
scanning the archives in the past.  Thanks!

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.

Searching the archives I found this suggestion from Rob Berendt (sorry
if 
spacing is off):

     D FLWORKREC       DS                  likerec(flworkr)
     D pDuh            s               *   inz(%addr(flworkrec))
     D duh             ds                  based(pDuh)
     D  col                          15p 4 overlay(duh:39) dim(389)

This is similar to something I had done when talking this problem
earlier 
today:

      // IBM copy member for API error data structures
      *+  PLEASE keep the next two lines TOGETHER!!!           -
     D/Copy qsysinc/qrpglesrc,qusec
     D QUSED01                     1024
      *+  PLEASE keep the previous two lines TOGETHER!!!           -
...
      // rename QUSEC to make things easier to read
     D pAPIErrorDS...
     D                 S               *   inz(%addr(QUSEC))
     D APIErrorDS...
     D                 DS                  based(pAPIErrorDS)
     D                                     qualified
     D bytesProvided...
     D                                     like(QUSBPRV)
     D bytesAvailable...
     D                                     like(QUSBAVL)
     D errorID...
     D                                     like(QUSEI)
     D errorData...
     D                                     like(QUSED01)

I'm not really happy with either of these solutions because both make 
assumptions about the order of the fields in the copied data structure.

What I'd really like to be able to do is this:

     D APIErrorDS...
     D                 DS                  likeDS(QUSEC)
     D bytesAvailable...
     D                                     like(QUSBAVL)
             D                                       overlay(QUSBAVL)

This way, if I only want to use the bytesAvailable variable in my
program 
I don't have to worry about any of the others.  I can also use
APIErrorDS 
wherever I would use QUSEC.  The best part is that if the layout of the 
QUSEC data structure were to change between releases, all I have to do
is 
recompile the program.

My preferred method doesn't work because using likeDS precludes defining

extra fields on the DS.  Does anyone have any suggestions of another way

to do this?

Thanks in advance,
Adam
########################################################################
#############
Attention:
The above message and/or attachment(s) is private and confidential and
is intended 
only for the people for which it is addressed. If you are not named in
the address 
fields, ignore the contents and delete all the material. Thank you.

For more information on email virus scanning, security and content
management, please contact administrator@xxxxxxxxxxxx
########################################################################
#############