COBOL "non-myth" confirmed - Index and subscripts (MF on Windows)
in [Cobol]
|
Prev: Help with Tcal
Next: COBOL Error Handling (was: What MF says about ROUNDED(was:Cobol Myth Busters
From: Robert on 19 Sep 2007 05:53 On Tue, 18 Sep 2007 21:41:57 -0700, Richard <riplin(a)Azonic.co.nz> wrote: >On Sep 19, 1:48 pm, "Pete Dashwood" ><dashw...(a)removethis.enternet.co.nz> wrote: >> "Robert" <n...(a)e.mail> wrote in message >> >> news:8sn0f35tq2j9hsrp75rulk5hsfksakvr8m(a)4ax.com...> On Mon, 17 Sep 2007 19:37:40 -0400, "Charles Hottel" >> > <chot...(a)earthlink.net> wrote: >> >> <snip> >> >> > Speed is the only reason for using indexes. >> >> No it isn't. Many posts here have shown a number of reasons why people use >> indexes. You are STILL stating what you stated before those posts. >> >> So, either, you cannot change your mind, or, you simply ignore what people >> say if it doesn't match your idea. > >Have you just noticed that ? > >It usually takes about three posting before Robert even notices >disagreement, and a couple more before he sees that he was wrong, and >then he tries to hide his mistake. Mistake? What mistake? I don't make mistakes.
From: Pete Dashwood on 19 Sep 2007 06:24 "Robert" <no(a)e.mail> wrote in message news:ojr1f31crnf222la325kviad8f67t8p9j7(a)4ax.com... > On Tue, 18 Sep 2007 21:58:41 -0700, Richard <riplin(a)Azonic.co.nz> wrote: > >>On Sep 19, 1:55 pm, "Charles Hottel" <chot...(a)earthlink.net> wrote: >>> "William M. Klein" <wmkl...(a)nospam.netcom.com> wrote in >>> messagenews:SIZHi.263081$VU2.141742(a)fe02.news.easynews.com... >>> >>> >>> >>> > "Robert" <n...(a)e.mail> wrote in message >>> >news:8sn0f35tq2j9hsrp75rulk5hsfksakvr8m(a)4ax.com... >>> >> On Mon, 17 Sep 2007 19:37:40 -0400, "Charles Hottel" >>> >> <chot...(a)earthlink.net> wrote: >>> >>> > <snip> >>> >> Tell that to the people who use indexes because they THINK speed is a >>> >> problem and indexes >>> >> are a solution. Speed is the only reason for using indexes. >>> >>> > <sarcasm intended - generalization noted> >>> >>> > Tell the people who use subsripts that they are NEVER faster ( >>> > although >>> > they might be comparable)- to never use them over indices. Speed is >>> > the >>> > only rason to use subscripts and that never is provided. >>> >>> > -- >>> > Bill Klein >>> > wmklein <at> ix.netcom.com >>> >>> If the speeds are comparable then I don't understand what the argument >>> is >>> about. Why be for or against either, just use the one that fits your >>> individual style. >> >>Index use should give a compiler error if you use the wrong index for >>a table. Thus indexes are safer. > > Someone said you can use indexes defined on one table for another. Seems > weird to me; I've > never tried. > >>> Well I remember it use to be that indexex were harder to find in a dump. >>> I >>> think I still have an atricle about how to locate them. But surely that >>> is >>> not relevant today. Robert sure knows how to stir up 'much ado about >>> nothing'. Or is that 'doodoo'? >> >> >>He simply wants to denigrate anyone that has given advice on Cobol so >>that he becomes the sole messiah of 'good cobol'. I had to smile at that. It's like wanting to be the top analog telephone engineer, in a world with a digital broadband cell phone in every pocket. Pete. -- "I used to write COBOL...now I can do anything."
From: donald tees on 19 Sep 2007 10:59 Charles Hottel wrote: > <pgx(a)pgrahams.com> wrote in message > news:hjrve3hbgvbe06e474gjt8gdkgnaam5r6h(a)4ax.com... >> "Charles Hottel" <chottel(a)earthlink.net> wrote: >> >> | I have not had a >> |performance problem of any type in the last 20 years. >> | >> Do you pay for the CPU time our of your own pocket? >> >> Phil > > No, but ever since I took a COBOL Efficiencies class long ago I have tried > to write reasonably efficient code. It is just as easy to get in the habit > of doing that as it is to avoid it until you have to. > > I've always believed that 99% of efficiency is in the algorithmic design. Once you've decided on the data structure, and the general approach to the problem, tiny code level decisions are not going to affect the speed much. They will have an effect, sure, but they won't fix an inefficient methodology, nor will they completely screw up an efficient approach. Donald
From: Judson McClendon on 19 Sep 2007 12:21 "donald tees" <donaldtees(a)execulink.com> wrote: > > I've always believed that 99% of efficiency is in the algorithmic design. Once you've decided on the data structure, and the > general approach to the problem, tiny code level decisions are not going to affect the speed much. They will have an effect, sure, > but they won't fix an inefficient methodology, nor will they completely screw up an efficient approach. I agree with you 99%. ;-) There are a few times when poor coding choice can make for enormous performance hits. One of the things that used to be a big deal was in blocking and assigning extra buffers for sequential files. In today's environment, where so much of the 'underpinnings' are already in place, there are probably a lot fewer of those. Anybody know of any sequential 'master files' being used anymore? -- Judson McClendon judmc(a)sunvaley0.com (remove zero) Sun Valley Systems http://sunvaley.com "For God so loved the world that He gave His only begotten Son, that whoever believes in Him should not perish but have everlasting life."
From: Howard Brazee on 19 Sep 2007 12:33
On Wed, 19 Sep 2007 10:59:14 -0400, donald tees <donaldtees(a)execulink.com> wrote: >I've always believed that 99% of efficiency is in the algorithmic >design. Once you've decided on the data structure, and the general >approach to the problem, tiny code level decisions are not going to >affect the speed much. They will have an effect, sure, but they won't >fix an inefficient methodology, nor will they completely screw up an >efficient approach. I'm not sure what this means. Does it include moving stuff outside of a loop that don't need to be in the loop? Does it include understanding the database processes and structure? Does it include understanding how to optimize swap space in the OS? Does it measure the costs and benefits of a CoBOL sort vs. an external sort? I have a program that looks to see what campus is running that program. If it is one of the big campuses, it does an area sweep, if it's one of the small campuses, it walks the set. This was determined by testing the speeds of the two choices. |