|
R. Bruce Hoffman, Jr. wrote: > > Dan Bale wrote: > > > > Programmers are also able to throw KLISTs all over the source now (and, >boy, do > > they ever!). What happens more in maintenance? A) Keys to a file >changing? or > > B) trying to find the KFLD fields of the KLIST that is associated with a >CHAIN > > or a READE that is causing problems? In all the environments I've been in, >99% > > of the time it's "B". > > You know, searching for a klist is only an F16 key away. > > Or, if you use LPEX, ctrl-f. > > Just about any editor can find the klist. The problem is that you are > suggesting that we remove the klist and scatter the information across > the program instead of just one place. > > Standard tenent in coding: one op, one place, one change. > 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. John Hall > -- > =========================================================== > 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 * > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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.