|
midrange.com
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 *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
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.
