Re: What bugs you about KLISTs in RPG IV? -- RPG400-L

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