AW: Renaming copy member data structure fields -- RPG400-L

Hi,

IBM confirmed APIs will run for future releases without any required
changes:

1. Field length or definitions won't change.
2. If additional parameters are necessary, they'll be added at the end of
the current parameter list and will be optional parameters.
3. If additional fields in data structures are necessary, they'll be added
at the end of the data structure and be optional.
   The offset of the data structure may change, but as long as you use the
offset and/or pointer arithmetic instead of hard coding the start position,
your programs will run without problems.
   If additional fields cannot be added to an existing data structure a new
one will be created and used.
4. If additional fields in formats are necessary, they'll be added at the
end of the format and optional.
   If the information cannot be added to the existing formats new ones are
created.

Mit freundlichen Gruessen / Best regards

Birgitta

"Shoot for the moon, even if you miss, you'll land among the stars."
(Les Brown)

-----Ursprungliche Nachricht-----
Von: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]Im Auftrag von
AGlauser@xxxxxxxxxxxx
Gesendet: Donnerstag, 16. Marz 2006 22:12
An: RPG programming on the AS400 / iSeries
Betreff: 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
########################################################################
#############
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.


--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



############################################################################
#########
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
############################################################################
#########
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.