• Subject: Re: What bugs you about KLISTs in RPG IV?
  • From: "R. Bruce Hoffman, Jr." <rbruceh@xxxxxxx>
  • Date: Thu, 17 Jun 1999 14:04:07 -0400

John Hall wrote:
> 
> KLISTs CAUSE the information to be scattered across the program.  Having
> the variables passed to the chain opcode on the same line as the chain
> is having it in one place.  The closest I can come to that with a KLIST
> is to stick it in the code right before the chain.  If I need to chain
> to the file in more than one section of the program then the chain is in
> a completely different (scattered) place from its KLIST.  Also if I am
> not using the exact field names in the KLIST or If I need to retrieve
> records from a file where the values may be coming from more than one
> source then I have to do moves into each field of the KLIST prior to the
> chain.  So in order to properly check the code I MUST go to each chain
> statement using the KLIST and then check the code before it to see what
> fields are being moved into the KLIST.  If I am using the same fields in
> the chain or in all the chains then they can still be defined in one
> place.
> 

No, KLISTs do not CAUSE scattering.  Programmers CAUSE scattering.  If
given the opportunity.  I just don't need or want more opportunity
issued.


code
code
code
     KLIST blah
           blah

--- more code ---

     klist chain ...

--- move code ---

     klist chain ...

--- move code ---

     klist chain ....

still more code...

This example is still better than ...


code
code
code
    no klist

--- more code ---

    chain (some wild key list)

--- more code ---

    chain (completely different key list)

--- more code ---

    chain (with imbedded function in key list)

still more code...


Yes, with discipline an RPG programmer can put the chains in a
subroutine and isolate the code involved with the chain.  I think they
should.  I try to, but in RPG it is very hard to actually write a one or
two or few line subroutine.  RPG programmers just don't think and work
that way.
C programmers do.  COBOL programmers have a tendency to move all data
access into paragraphs even if it is only a READ.  RPG programmers just
don't in my experience.
I would just prefer that the key lists themselves continue to exist in
either the C spec or in a new D spec instead of now just arbitrarily
specifying them on the fly at each chain op code.  I also would like to
be able to just tell the key list that the key is externally described,
like I can in COBOL.  Give it a name and tell it where to find them. 
Just like a file spec.  Just like an externally described data area.
It isn't just the setting of the fields, it is the parsing that I would
then have to do at each and every chain.  With key list, I know what
fields I'm using, how many are expected, etc.  With a chain containing a
variable number of keys, I just don't.


-- 
===========================================================
R. Bruce Hoffman, Jr.
 -- IBM Certified AS/400 Professional System Administrator
 -- IBM Certified AS/400 Professional Network Administrator

"The sum of all human knowledge is a fixed constant.
    It's the population that keeps growing!"
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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 thread ...

Replies:

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.