× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.