|
James, Look into the Define & Undefine compiler directives. They let you keep all your copy members in one source member and just copy in the lines you want, where you want them to go. -----Original Message----- From: James W. Kilgore <qappdsn@ibm.net> To: RPG400-L@midrange.com <RPG400-L@midrange.com> Date: Wednesday, June 16, 1999 12:08 AM Subject: Re: What bugs you about KLISTs in RPG IV? >Hans, > >I was hoping someone would bring up a similar point to mine, but no such luck. > >I believe that you have already noted that other responses have been for >maintenance benefits, and we are in the same camp. Although for different >reasons. > >As with a lot of "it depends" situations, our shop standards would be benefited >by "D" spec KLIST's. Why? Because we are lazy. =:-o > >We ran into a minor, labor intensive, whaa, whaa, whaa, in going from RPG/400 >to RPGLE. In our shop, for each file, we have (at least) three /COPY >statements. All of our program source members are defined as RPT although we >-never- use the program defined report format feature. Just the precompiler >feature to sort /COPY specifications. > >So lets say I have a file called "ITEM". And let's say I write a command and >appropriate programs for ITEMWRK. > >Now in these programs I have a /COPY which (under RPG/400) has both a data >structure for a compound key "I" spec (IMKEY) and a key list "C" spec >(IMKLST). A source type of RPT put the two different parts of the /COPY in >their appropriate place. The /COPY was in the 'I" spec location and the "C" >key list would appear at the beginning of the calculations. > >FYI, the data structure for compound key would be compared to last key >retrieved (IMKEY IFNE IMLAST) to skip the CHAIN and avoid unnecessary I/O >requests. This rule applies to all files. > >In trying to convert from RPT to RPGLE, we had to take a single /COPY member >and create two members (per file) , and visit each and every source member to >split the D/C specifications for each and every file. Whaa, whaa, whaa. ;-) > >So for our shop, I could care less if you make KLIST a "D" spec or not, what >would make us happy would be a RPTLE source type to sort the /COPY member >contents into their proper place. > >The same holds true for a /COPY array. We now (because of "no program defined >arrays" rule) have two /COPY members where one would work just fine under RPT >source type. > >We are at the baby steps of ILE and probably should/will take the "Month Name >Array" into a service program, but for xK programs, with n people hours/week, >eliminating the "smarts" to order a /COPY source member by specification type >didn't ease our transition to ILE. > >Thanks for hearing me out. > >James W. Kilgore >email@James-W-Kilgore.com > >P.S. We have to support V3R2 and really don't want to hear that "if you are at >V4Rx" as a solution. It just makes us feel bad. It's our face (not IBM's) in >the clients face. Saving face in a good thing. > > > >* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * >* This is the RPG/400 Discussion Mailing List! To submit a new * >* message, send your mail to "RPG400-L@midrange.com". To unsubscribe * >* from this list send email to MAJORDOMO@midrange.com and specify * >* 'unsubscribe RPG400-L' in the body of your message. Questions should * >* be directed to the list owner / operator: david@midrange.com * >* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This is the RPG/400 Discussion Mailing List! To submit a new * * message, send your mail to "RPG400-L@midrange.com". To unsubscribe * * from this list send email to MAJORDOMO@midrange.com and specify * * 'unsubscribe RPG400-L' in the body of your message. Questions should * * be directed to the list owner / operator: david@midrange.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
As an Amazon Associate we earn from qualifying purchases.
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.