|
Scott, your explanation is brilliant as usual. But my question remains unanswered. If I use file fields directly as KLIST variables, I believe using KLIST will make maintenance easier. And as for F11'ng - we need to see the KLIST quite often because we work on various projects and many a times debugging programs written by somebody else. Another doubt comes to mind - If you define a KLIST as a data structure, will there be any memory overheads? And secondly if I have many data structures already defined and used in the program (e.g. programs in CA-PRMS etc.), don't you think that this new set of data structures will further lengthen the list and make the life of a maintenance guy difficult? That too when you are battling against time in most of the cases. Cheers Vijosh A Systems & Software 123 , SDF- 4, SEEPZ Bombay, India. Email : <vijosha@alfuttaim.co.ae> -----Original Message----- From: Scott Klement [SMTP:infosys@klements.com] Sent: Wednesday, June 16, 1999 11:03 PM To: RPG400-L@midrange.com Subject: Re: RE: What bugs you about KLISTs in RPG IV? Vijosh A <VijoshA@alfuttaim.co.ae> wrote: > Your idea is interesting. > > But let me draw your attention to a problem that comes to my mind- I > suppose you do not have a KLIST and as it often happens there are > changes > to key fields (although not frequently). So if I use your method the > I will > have to change the same in many a places. Especially when you are > using > physical file fields in the KLIST. This may make maintenance > difficult. So > therefore I would still prefer to use KLISTS. I honestly don't see how it'd be any different making these changes using KLISTs vs. the free-form syntax. okay, here is a keylist example: C KeyList KLIST C KFLD KeyFld1 5 0 C KFLD KeyFld2 10 C KFLD KeyFld3 15 C KeyList CHAIN File 10 C* 50 lines later: C KeyList CHAIN File 11 C* 100 Lines later: C KeyList CHAIN File 12 Here is the same thing, with free-form syntax.... D KeyFld1 S 5 0 D KeyFld2 S 10A D KeyFld3 S 15A CF CHAIN(KeyFld1:KeyFld2:KeyFld3) File C* 50 lines later CF CHAIN(KeyFld1:KeyFld2:KeyFld3) File C* 100 lines later CF CHAIN(KeyFld1:KeyFld2:KeyFld3) File In both cases you only have to change the keys WHERE THEY ARE DEFINED. In BOTH cases, this is only in ONE PLACE. How is it different for the purposes of maintenance? Yes, you don't HAVE to specify the same variables on each chain statement with the freeform expression, but you also don't have to with the KLIST! For example: C KeyList KLIST C KFLD KeyFld1 5 0 C KFLD KeyFld2 10 C KFLD KeyFld3 15 C KeyList CHAIN File 10 C* 50 lines later: C KeyList2 KLIST C KFLD Key2Fld1 5 0 C KFLD Key2Fld2 10 C KFLD Key2Fld3 15 C KeyList2 CHAIN File 11 Would not be any "easier to maintain" than: D KeyFld1 S 5 0 D KeyFld2 S 10A D KeyFld3 S 15A D Key2Fld1 S 5 0 D Key2Fld2 S 10A D Key2Fld3 S 15A CF CHAIN(KeyFld1:KeyFld2:KeyFld3) File C* 50 lines later CF CHAIN(Key2Fld1:Key2Fld2:Key2Fld3) File When you're updating all of your programs because the keys have changed, you currently have to do this: 1) Search your program for all the CHAIN, SETLL, DELETE & READE op-codes for that file. 2) Find all of the keylists referenced in step 1, and determine what variables they are using. 3) Find out where those variables are used, and change their defs... However, with the proposed, new, free-form method you would: 1) Search for all the CHAIN, SETLL, DELETE and READE statements just like above. 2) Check the definitions for the variables used, and update them, just like step #3 above. Since the variables are referenced directly, you no longer have to do step #2. So, I'm very sorry, but no matter how I look at it, I can't see how this makes maintenance MORE DIFFICULT!!!! > > Another problem you have not addressed is the - facility to use F11 > a > KLIST. This is facility will be useful and will be highly appreciate > > Thanks > > Cheers > > Vijosh A > Systems & Software > 123 , SDF- 4, SEEPZ > Bombay India. Theres a very simple solution to the whole "debug a whole keylist" problem. Just put all of your keys in a data structure somewhere, and debug THAT. Maybe I'm weird, but its only once in a blue moon that I need to debug a keylist, and hitting F11 (or typing eval varname) for 2 or 3 different variables in a keylist doesn't bother me at all. If it did, I'd make a data structure that contained all of my keys, just to make it easier to debug them. Scott Klement Information Systems Manager Klement's Sausage Co, Inc. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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.