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