Home > Archive > Cobol > September 2007 > Re: COBOL "non-myth" confirmed - Index and subscripts (MF on Windows)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: COBOL "non-myth" confirmed - Index and subscripts (MF on Windows)
|
|
| Richard 2007-09-15, 3:55 am |
| On Sep 15, 2:56 pm, Robert <n...@e.mail> wrote:
> The basic difference is that subscript requires multiplication
> whereas index does not. SETTING an index does a multiplication, same as USING a subscript.
> I'm not surprised times are the same.
So, if for example, several array items were accessed for each SET
then with indexes there would be one multiply and several accesses but
with subscripts there would be several multiplys.
Just why is 'index is faster than subscript' a myth, again ?
Actually it is likely that a compiler could optimize the use of
subscripts by noticing that the value hadn't changed. So _if_ the
compiler optimizes well then they may be same speed, if not, or if
some other code interferes with the optimizer, index will be at worst
the same and may be faster.
So not only did you not establish adequately that it was a myth you
still haven't identified anyone who _wrongly_ believes it.
| |
| Robert 2007-09-15, 3:55 am |
| On Fri, 14 Sep 2007 22:51:45 -0700, Richard <riplin@Azonic.co.nz> wrote:
>On Sep 15, 2:56 pm, Robert <n...@e.mail> wrote:
>
>
>So, if for example, several array items were accessed for each SET
>then with indexes there would be one multiply and several accesses but
>with subscripts there would be several multiplys.
There would probably be one multiply on the subscript because the optimizer would use that
value on subsequent accesses. (I wrote that before reading your paragraph below sayig the
same thing.)
>Just why is 'index is faster than subscript' a myth, again ?
1. Because a timing test showed indexes are slower.
2. Because multiplication is now as fast as loading an index.
>Actually it is likely that a compiler could optimize the use of
>subscripts by noticing that the value hadn't changed. So _if_ the
>compiler optimizes well then they may be same speed, if not, or if
>some other code interferes with the optimizer, index will be at worst
>the same and may be faster.
Subscript was faster in my test because the subscript was optimized but the index
apparently was not. It appears the code was reloading the index on every iteration.
>So not only did you not establish adequately that it was a myth you
>still haven't identified anyone who _wrongly_ believes it.
Most people who use indexes believe it. Why else would they use indexes?
| |
| Judson McClendon 2007-09-15, 6:55 pm |
| "Richard" <riplin@Azonic.co.nz> wrote:
> Robert <n...@e.mail> wrote:
>
> I don't believe that you have surveyed anything but a tiny sample of
> coders so you have no idea, except for what, a few dozen, how many use
> indexes, nor what they believe, nor why they use indexes.
>
> I have actually done a test on Linux with Fujitsu 7. Within the
> perform loop it does a couple of moves totaling 4 uses of subscript/
> index:
>
> subscript comp-5 9.58
> index 9.52
> subscript comp 13.35
>
> Index _IS_ faster, at least on this system. Granted it is not much
> faster when the MF extension of Comp-5 is used.
>
> So there is no reason to stop using index at all. Your claims,
> methodology and assertions are crap.
Below is a post I made back in 2001 about the relative performance of
indexing and subscripting that may shed a bit of light on the issue, for
those not well versed in these things.
========
Here are a few of points to consider.
1. The relative difference is very dependant on the compiler and
hardware platform. For example, because the COBOL standard does
not specify how indexes are to be constructed, some compilers
default to simple numeric pointers, identically equivalent to
subscripts.
2. Whether to use subscripting or indexing in a particular situation
is a complex issue, and the answer depends primarily on these
factors:
a. Cost of setting/incrementing/decrementing index vs. subscript
b. Cost of reference using index vs. subscript
c. Ratio of times index/subscript is set/inc/dec vs. reference
d. Frequency of conversion between index and numeric field
In general, a program that does many references to a table for every
time the index/subscript is set, indexing will tend to be faster.
But if the ratio of table references to times the index/subscript is
lowered, particularly if an index is often converted to/from numeric
data fields, subscripting can be faster, even much faster (e.g. set
index to numeric variable, reference table only once.)
Another thing to consider is, in the tests we have done here in the
newsgroup, if you are using either indexing or subscripting to scan
a field character by character, it will probably be faster if you
use a numeric field and reference modification. The difference can
be significant. But again, it very much depends on the compiler and
platform. :-)
--
Judson McClendon judmc@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."
| |
| Robert 2007-09-15, 6:55 pm |
| On Sat, 15 Sep 2007 11:43:24 -0700, Richard <riplin@Azonic.co.nz> wrote:
>On Sep 15, 6:50 pm, Robert <n...@e.mail> wrote:
>
>And you have done a timing test on every machine in the universe.
If humans were unable to generalize, there wouldn't be any machines. We'd be living in
shacks and tents.
The Micro Focus page is generalized advice. Write and tell them generalization is BAD.
They shouldn't give advice until they test on every machine.
>
>I didn't notice the elves coming in and doing that to my machine.
You need to upgrade that '386.
>
>So you are saying that if you run in a loop accessing the _same_ item
>each time the subscript is faster (due to the optimizer). That
>certainly proves that everyone should use subscripts if they don't
>care about making the program do useful things.
Ok, I'll change the subscript inside the loop and rerun the test.
>Perhaps a test of actual usage (on their machines) with actual work
>shows that indexes _are_ faster, or at least the same.
Maybe they'll share the results of their test, probably not.
>
>You said above 'multiplication is now as fast ..'. Obviously that
>wasn't always true, and it wasn't true when the program was written,
>and it isn't true for all machines.
>
>It is also probable that they aren't running your compiler and their
>optimization does not make subscripts as fast as indexes.
>
>So they may well have used indexes when they wrote the system and
>indexes _were_ faster and be using indexes still because they don't
>see the need to re-engineer a few million lines of code which will
>make zero difference at best (or make it slower) just because Robert
>wants to denigrate 'legacy coders'.
>
>Or perhaps they use standard data types for subscripts instead of the
>extension of COMP-5 that you used and the way to get 'native' is
>'index' and thus index _is_ faster.
>
>Or perhaps they use index because it provides a degree of compiler
>error checking which subscripts cannot.
>
>Or maybe they still use indexes just to piss you off.
Maybe they use indexes out of habit, because no one told them the reason had disappeared.
| |
| Robert 2007-09-15, 6:55 pm |
| On Sat, 15 Sep 2007 13:09:52 -0700, Richard <riplin@Azonic.co.nz> wrote:
>On Sep 15, 6:50 pm, Robert <n...@e.mail> wrote:
>
>I don't believe that you have surveyed anything but a tiny sample of
>coders so you have no idea, except for what, a few dozen, how many use
>indexes, nor what they believe, nor why they use indexes.
>
>I have actually done a test on Linux with Fujitsu 7. Within the
>perform loop it does a couple of moves totaling 4 uses of subscript/
>index:
>
>subscript comp-5 9.58
>index 9.52
>subscript comp 13.35
>
>Index _IS_ faster, at least on this system. Granted it is not much
>faster when the MF extension of Comp-5 is used.
They're the same speed, as I said. Half of one percent is trivial.
>So there is no reason to stop using index at all. Your claims,
>methodology and assertions are crap.
You're ignoring your own evidence.
| |
|
| In article <rqnoe3hgjei5ir0b6ht4kefrmli2mr2cuq@4ax.com>,
Robert <no@e.mail> wrote:
>On Sat, 15 Sep 2007 11:43:24 -0700, Richard <riplin@Azonic.co.nz> wrote:
>
[snip]
[color=darkred]
>
>If humans were unable to generalize, there wouldn't be any machines.
>We'd be living in
>shacks and tents.
What Mr Plinston puts forward, Mr Wagner, may demonstrate why there is a
season to things and a time to every purpose. The above might be phrased
otherwise and yet still retain some original flavor, eg:
A: Just why is 'index is faster than subscript' a myth, again ?
B: Because a timing test showed indexes are slower.
A: '*A* timing test' (emphasis added) shows that under *a* set of
conditions one might not be better than the other; it is possible that
under other sets of conditions the other might be better than the one.
>
>The Micro Focus page is generalized advice. Write and tell them
>generalization is BAD.
Leaving aside the Brooklyn Bridge nature of this argument - 'Micro Focus
jumps off the Brooklyn Bridge, you will, too?' - one might believe that
when Micro Focus (or an appropriate representative thereof) comes
a-posting here the responses might be the same.
>They shouldn't give advice until they test on every machine.
It has been advised that one should tend to their own garden first, Mr
Wagner, before one tends to Micro Focus'... or something like that.
>
>
>You need to upgrade that '386.
Only 486 and above are elf-compatible, sure!
DD
| |
| William M. Klein 2007-09-16, 3:55 am |
|
"Robert" <no@e.mail> wrote in message
news:rqnoe3hgjei5ir0b6ht4kefrmli2mr2cuq@
4ax.com...
> On Sat, 15 Sep 2007 11:43:24 -0700, Richard <riplin@Azonic.co.nz> wrote:
<snip>
>
> The Micro Focus page is generalized advice. Write and tell them generalization
> is BAD.
> They shouldn't give advice until they test on every machine.
Robert,
You didn't originally CLAIM this(use index not subscript) was in any Micro
Focus documentation. Do you now claim it is in the Micro Focus documentation
and if so where?
(Some - but not all - of your original comments WERE about MF documentation -
and I would certainly say that some customer who has the relevant documentation
and compiler should send in a comment complaining about it. It is worth noting
that NONE of the "efficiency" recommendations from your original note were in
the Net Express documentation. It - as far as I can tell - never comments on
this topic.)
P.S. IBM has some interesting documentation for their z/OS COBOL compiler. For
example,
http://publibz.boulder.ibm.com/cgi-...gy3pg32/8.1.3.1
talks about some of the table reference optimizaiton that the compiler does do
(and therefore what types of code/structures they recommend using for optimal
performancer).
while
http://publibz.boulder.ibm.com/cgi-.../igy3pg32/8.1.3
does recommend the use of indexing over subscripts
However, they also "back this up" with the performance statistics that support
this, i.e.
"using binary data items (COMP) to address a table is 30% slower than using
indexes"
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Pete Dashwood 2007-09-16, 6:55 pm |
|
"Robert" <no@e.mail> wrote in message
news:rqnoe3hgjei5ir0b6ht4kefrmli2mr2cuq@
4ax.com...
> On Sat, 15 Sep 2007 11:43:24 -0700, Richard <riplin@Azonic.co.nz> wrote:
>
>
> If humans were unable to generalize, there wouldn't be any machines. We'd
> be living in
> shacks and tents.
>
> The Micro Focus page is generalized advice. Write and tell them
> generalization is BAD.
> They shouldn't give advice until they test on every machine.
>
>
> You need to upgrade that '386.
>
>
> Ok, I'll change the subscript inside the loop and rerun the test.
>
>
> Maybe they'll share the results of their test, probably not.
>
>
> Maybe they use indexes out of habit, because no one told them the reason
> had disappeared.
Or, maybe they didn't BELIEVE the reason has disappeared.
But if that were true, there'd be whole heap of posts showing flaws in the
Gospel...
Hang on a minute... :-)
(BTW, the reason I use indexes is not for any of the reasons you described;
I simply like INDEXED BY and SEARCH. Having gone to the trouble of defining
an index for a table it seems impolite to then use a subscript... :-))
Couldn't care less whether they're faster or slower; on modern hardware it
makes very little difference, and even if it did, I'd still do it. Because I
can.:-))
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Pete Dashwood 2007-09-16, 6:55 pm |
|
<docdwarf@panix.com> wrote in message news:fcht8h$cbo$1@reader1.panix.com...
> In article <rqnoe3hgjei5ir0b6ht4kefrmli2mr2cuq@4ax.com>,
> Robert <no@e.mail> wrote:
>
> [snip]
>
>
> What Mr Plinston puts forward, Mr Wagner, may demonstrate why there is a
> season to things and a time to every purpose. The above might be phrased
> otherwise and yet still retain some original flavor, eg:
>
> A: Just why is 'index is faster than subscript' a myth, again ?
>
> B: Because a timing test showed indexes are slower.
>
> A: '*A* timing test' (emphasis added) shows that under *a* set of
> conditions one might not be better than the other; it is possible that
> under other sets of conditions the other might be better than the one.
>
>
> Leaving aside the Brooklyn Bridge nature of this argument - 'Micro Focus
> jumps off the Brooklyn Bridge, you will, too?' - one might believe that
> when Micro Focus (or an appropriate representative thereof) comes
> a-posting here the responses might be the same.
>
>
> It has been advised that one should tend to their own garden first, Mr
> Wagner, before one tends to Micro Focus'... or something like that.
>
>
> Only 486 and above are elf-compatible, sure!
I'm fairy certain my core 2 duo is accommodating several billion pixies in
it's HD1080 display memory.
It's a gnome away from home.
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Pete Dashwood 2007-09-16, 6:55 pm |
|
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1189886992.443101.194330@g4g2000hsf.googlegroups.com...
> On Sep 15, 6:50 pm, Robert <n...@e.mail> wrote:
>
> I don't believe that you have surveyed anything but a tiny sample of
> coders so you have no idea, except for what, a few dozen, how many use
> indexes, nor what they believe, nor why they use indexes.
>
> I have actually done a test on Linux with Fujitsu 7. Within the
> perform loop it does a couple of moves totaling 4 uses of subscript/
> index:
>
> subscript comp-5 9.58
> index 9.52
> subscript comp 13.35
>
> Index _IS_ faster, at least on this system. Granted it is not much
> faster when the MF extension of Comp-5 is used.
>
> So there is no reason to stop using index at all. Your claims,
> methodology and assertions are crap.
>
D'jou think we might qualify that last to "Some of your claims..." or "Most
of your claims..." or specify "ALL" for North Americans who don't use
deductive logic? :-)
Pete.
--
"I used to write COBOL...now I can do anything."
>
| |
| Pete Dashwood 2007-09-16, 6:55 pm |
|
"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:plZGi.62611$U24.13876@bignews5.bellsouth.net...
> "Richard" <riplin@Azonic.co.nz> wrote:
>
> Below is a post I made back in 2001 about the relative performance of
> indexing and subscripting that may shed a bit of light on the issue, for
> those not well versed in these things.
> ========
> Here are a few of points to consider.
>
> 1. The relative difference is very dependant on the compiler and
> hardware platform. For example, because the COBOL standard does
> not specify how indexes are to be constructed, some compilers
> default to simple numeric pointers, identically equivalent to
> subscripts.
>
> 2. Whether to use subscripting or indexing in a particular situation
> is a complex issue, and the answer depends primarily on these
> factors:
> a. Cost of setting/incrementing/decrementing index vs. subscript
> b. Cost of reference using index vs. subscript
> c. Ratio of times index/subscript is set/inc/dec vs. reference
> d. Frequency of conversion between index and numeric field
>
> In general, a program that does many references to a table for every
> time the index/subscript is set, indexing will tend to be faster.
> But if the ratio of table references to times the index/subscript is
> lowered, particularly if an index is often converted to/from numeric
> data fields, subscripting can be faster, even much faster (e.g. set
> index to numeric variable, reference table only once.)
>
> Another thing to consider is, in the tests we have done here in the
> newsgroup, if you are using either indexing or subscripting to scan
> a field character by character, it will probably be faster if you
> use a numeric field and reference modification. The difference can
> be significant. But again, it very much depends on the compiler and
> platform. :-)
....and whether you do, or should, care...:-)
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Robert 2007-09-16, 6:55 pm |
| On Mon, 17 Sep 2007 01:17:37 +1200, "Pete Dashwood" <dashwood@removethis.enternet.co.nz>
wrote:
>(BTW, the reason I use indexes is not for any of the reasons you described;
>I simply like INDEXED BY and SEARCH. Having gone to the trouble of defining
>an index for a table it seems impolite to then use a subscript... :-))
>Couldn't care less whether they're faster or slower; on modern hardware it
>makes very little difference, and even if it did, I'd still do it. Because I
>can.:-))
I hope you use ODO on 'high speed' SEARCHes. If not, they're taking twice as long as they
should for serial, 10% longer for binary.
| |
| Richard Brady 2007-09-16, 6:55 pm |
| Pete Dashwood wrote:
[snip]
> D'jou think we might qualify that last to "Some of your claims..." or "Most
> of your claims..." or specify "ALL" for North Americans who don't use
> deductive logic? :-)
>
> Pete.
This North American uses only inductive logic, if you please.
Another Richard
| |
| Robert 2007-09-16, 6:55 pm |
| On Sun, 16 Sep 2007 06:01:20 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:
>
>"Robert" <no@e.mail> wrote in message
> news:rqnoe3hgjei5ir0b6ht4kefrmli2mr2cuq@
4ax.com...
><snip>
>
>Robert,
> You didn't originally CLAIM this(use index not subscript) was in any Micro
>Focus documentation. Do you now claim it is in the Micro Focus documentation
>and if so where?
Micro Focus does not say indexes are faster, in the efficiency tips nor elsewhere. Many
Cobol programmers still believe it, because it was true in the Old Days.
>(Some - but not all - of your original comments WERE about MF documentation -
>and I would certainly say that some customer who has the relevant documentation
>and compiler should send in a comment complaining about it. It is worth noting
>that NONE of the "efficiency" recommendations from your original note were in
>the Net Express documentation. It - as far as I can tell - never comments on
>this topic.)
Most of the recommendations are valid, at least on most platforms. I tested the ones that
didn't sound right to me.
>P.S. IBM has some interesting documentation for their z/OS COBOL compiler. For
>example,
>
> http://publibz.boulder.ibm.com/cgi-...gy3pg32/8.1.3.1
>
>talks about some of the table reference optimizaiton that the compiler does do
>(and therefore what types of code/structures they recommend using for optimal
>performancer).
>
> while
>
>http://publibz.boulder.ibm.com/cgi-.../igy3pg32/8.1.3
>
>does recommend the use of indexing over subscripts
>
>However, they also "back this up" with the performance statistics that support
>this, i.e.
>
> "using binary data items (COMP) to address a table is 30% slower than using
>indexes"
Relative speeds are changing. Subscripting was about 500% slower in the Old Days. I don't
doubt it WAS 30% slower when the above was written. My point is that subscripts are not
slower on modern machines.
| |
| Robert 2007-09-16, 6:55 pm |
| On Sun, 16 Sep 2007 00:26:57 +0000 (UTC), docdwarf@panix.com () wrote:
>In article <rqnoe3hgjei5ir0b6ht4kefrmli2mr2cuq@4ax.com>,
>Robert <no@e.mail> wrote:
>
>[snip]
>
>
>What Mr Plinston puts forward, Mr Wagner, may demonstrate why there is a
>season to things and a time to every purpose. The above might be phrased
>otherwise and yet still retain some original flavor, eg:
>
>A: Just why is 'index is faster than subscript' a myth, again ?
>
>B: Because a timing test showed indexes are slower.
>
>A: '*A* timing test' (emphasis added) shows that under *a* set of
>conditions one might not be better than the other; it is possible that
>under other sets of conditions the other might be better than the one.
I tried to make the tests represent typical usage AND I posted source code. If you think
the test is unfair, say so or write your own test. Thanks to Richard's complaints, I saw
the subscript test did NOT represent typical usage, so I'll fix it and rerun.
>
>Leaving aside the Brooklyn Bridge nature of this argument - 'Micro Focus
>jumps off the Brooklyn Bridge, you will, too?' - one might believe that
>when Micro Focus (or an appropriate representative thereof) comes
>a-posting here the responses might be the same.
I have no problem with generalizations, nor do I fault Micro Focus for making them. I
think a few of the SPECIFIC points are erroneous, because they're based on commonly held
belief (myth).
>
>It has been advised that one should tend to their own garden first, Mr
>Wagner, before one tends to Micro Focus'... or something like that.
We all plant our crops in the soil plowed by Micro Focus .. or something like that.
>
>Only 486 and above are elf-compatible, sure!
The elf is superscalar, which means multiple instructions per clock.
Itanium (formerly IA-64) is a radical change in CPU design. Many don't know its basic
design originated in HP, where it was named EPIC, not in Intel. It has been an
underperformer in sales and missed deadlines, but in execution speed it is noticably
faster than others. No chip maker has attempted to copy it. Surprisingly, Intel does not
make the companion "chipset" required to use the Itanium on a motherboard. Today, most
chipsets are made by HP. Silicon Graphics (SGI) is another big supporter.
If Itanium is unsuccessful, CPUs are close to hitting the wall in terms of speed. We can't
make them much more complex (required to avoid instruction collisions) because we can't
make traces much smaller. We're approaching the size of atoms.
| |
| William M. Klein 2007-09-16, 9:55 pm |
| Robert,
For what compiler? What operating systems? And your evidence is ...?
Of course, we all KNOW that there is no such thing as a "guaranteed" BINARY
search. (SEARCH ALL is not guaranteed to be "binary").
--
Bill Klein
wmklein <at> ix.netcom.com
"Robert" <no@e.mail> wrote in message
news:hvrqe394mgcejqa6bgfvu4ge141tmqtima@
4ax.com...
> On Mon, 17 Sep 2007 01:17:37 +1200, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz>
> wrote:
>
>
>
> I hope you use ODO on 'high speed' SEARCHes. If not, they're taking twice as
> long as they
> should for serial, 10% longer for binary.
>
| |
| William M. Klein 2007-09-16, 9:55 pm |
|
"Robert" <no@e.mail> wrote in message
news:k27re3tjim0q8bsqadfn1ehagf4ko407pj@
4ax.com...
> On Sun, 16 Sep 2007 06:01:20 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>
> Micro Focus does not say indexes are faster, in the efficiency tips nor
> elsewhere. Many
> Cobol programmers still believe it, because it was true in the Old Days.
>
>
> Most of the recommendations are valid, at least on most platforms. I tested
> the ones that
> didn't sound right to me.
>
>
> Relative speeds are changing. Subscripting was about 500% slower in the Old
> Days. I don't
> doubt it WAS 30% slower when the above was written. My point is that
> subscripts are not
> slower on modern machines.
You are trying to claim that the zSeries is NOT a "modern machine".
Your statement,
"Many Cobol programmers still believe it, because it was true in the Old Days."
It is still true on the environment where the recommendation is still
documented, i.e. IBM mainframe compilers. (If you haven't researched it,
although the pointed to "Performance Guide" is for Enterprise COBOL V3.1 and the
compiler is now on V3.4, IBM is on record as indicating that there have been few
"performance" enhancements between these releases.
As you have acknowledged elsewhere, your guess is that somewhere ABOUT 70% of
all COBOL code that is running today is on IBM mainframes (and I would guess
that it is certainly OVER 50^) then it is true that for majority of COBOL code,
the use of indices is to be preferred (for performance purposes) than
subscripts.
And of course, even your own test showed that indices are MINIMALLY faster than
subscripts, so the real question should be WHY would you ever use subscripts
where you could use indices?
| |
| Robert 2007-09-16, 9:55 pm |
| On Mon, 17 Sep 2007 01:15:35 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:
>Robert,
> For what compiler? What operating systems? And your evidence is ...?
It's true for every compiler and operating system. Telling Cobol to search 1,000 rows when
half of them are filled with high values will take log2 1,000 / log2 500 times as long.
Roughly 10% longer.
No timing test is necessary, although I'm tempted to write one just for fun. Deductive
logic OR common sense should tell you that.
>Of course, we all KNOW that there is no such thing as a "guaranteed" BINARY
>search. (SEARCH ALL is not guaranteed to be "binary").
That's true in Standard-land. In Reality-land, every compiler does a binary search.
I spent years trying to prove that 2 is not the optimal division factor. Based on
calculus, I really believed it was e - 1, which is approximately 1.7. I almost 'proved'
it with tests. Years later I saw that 2 really IS the optimal division factor. On well, I
tried.
| |
| William M. Klein 2007-09-16, 9:55 pm |
| An ODO is ONLY faster if the number of "filled in" table entries varies. If the
number of entries is stable AND all entries are filled in (which is the most
common situation in the SEARCH ALL programs that I have seen). For serial
SEARCHes where the "empty" entries are at the end, I can't see how or why an ODO
would ever be faster.
P.S. If you search the records of this group, there ARE compilers that have
used non-Binary searches for SEARCH ALL. However, I do agree that no one has
been able to point out any that are still sold/distributed that do so today.
--
Bill Klein
wmklein <at> ix.netcom.com
"Robert" <no@e.mail> wrote in message
news:7jlre31oq6blvdmk49jl2974tctunhkr43@
4ax.com...
> On Mon, 17 Sep 2007 01:15:35 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>
> It's true for every compiler and operating system. Telling Cobol to search
> 1,000 rows when
> half of them are filled with high values will take log2 1,000 / log2 500 times
> as long.
> Roughly 10% longer.
>
> No timing test is necessary, although I'm tempted to write one just for fun.
> Deductive
> logic OR common sense should tell you that.
>
>
> That's true in Standard-land. In Reality-land, every compiler does a binary
> search.
>
> I spent years trying to prove that 2 is not the optimal division factor. Based
> on
> calculus, I really believed it was e - 1, which is approximately 1.7. I almost
> 'proved'
> it with tests. Years later I saw that 2 really IS the optimal division factor.
> On well, I
> tried.
| |
| Pete Dashwood 2007-09-16, 9:55 pm |
|
"Robert" <no@e.mail> wrote in message
news:hvrqe394mgcejqa6bgfvu4ge141tmqtima@
4ax.com...
> On Mon, 17 Sep 2007 01:17:37 +1200, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz>
> wrote:
>
>
>
> I hope you use ODO on 'high speed' SEARCHes. If not, they're taking twice
> as long as they
> should for serial, 10% longer for binary.
>
I NEVER use ODO for ANYTHING.
The only time I would code ODO is when I am accessing something that
requires it.
I've seen the arguments for ODO on searches.
As the tables I search are rarely more than 1K in size (I think the largest
I can remember doing in COBOL recent was 8K),and I do use SEARCH ALL on
non-volatile data, I really don't care if it takes a few microseconds (or
even milliseconds) longer. The table is in memory.
To me ODO is just ugly pointless code that buys you nothing in terms of
saved space, so it doesn't deliver what it promises.
The last time I used COBOL for an application that was time critical where a
few Milliseconds MIGHT matter (it was a process control app), was nearly 30
years ago and GO TO was employed to get out of routines fast. I wouldn't
code normal COBOL apps like that and I don't use ODO in them either.
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Robert 2007-09-16, 9:55 pm |
| On Mon, 17 Sep 2007 01:23:37 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:
>
>"Robert" <no@e.mail> wrote in message
> news:k27re3tjim0q8bsqadfn1ehagf4ko407pj@
4ax.com...
>
>You are trying to claim that the zSeries is NOT a "modern machine".
>
>Your statement,
>
>"Many Cobol programmers still believe it, because it was true in the Old Days."
>
>It is still true on the environment where the recommendation is still
>documented, i.e. IBM mainframe compilers. (If you haven't researched it,
>although the pointed to "Performance Guide" is for Enterprise COBOL V3.1 and the
>compiler is now on V3.4, IBM is on record as indicating that there have been few
>"performance" enhancements between these releases.
>
>As you have acknowledged elsewhere, your guess is that somewhere ABOUT 70% of
>all COBOL code that is running today is on IBM mainframes (and I would guess
>that it is certainly OVER 50^) then it is true that for majority of COBOL code,
>the use of indices is to be preferred (for performance purposes) than
>subscripts.
>And of course, even your own test showed that indices are MINIMALLY faster than
>subscripts, so the real question should be WHY would you ever use subscripts
>where you could use indices?
Your own citation says "subscripting might be easier to understand and maintain."
| |
| Robert 2007-09-16, 9:55 pm |
| On Mon, 17 Sep 2007 13:52:58 +1200, "Pete Dashwood" <dashwood@removethis.enternet.co.nz>
wrote:
>
>
>"Robert" <no@e.mail> wrote in message
> news:hvrqe394mgcejqa6bgfvu4ge141tmqtima@
4ax.com...
>I NEVER use ODO for ANYTHING.
>
>The only time I would code ODO is when I am accessing something that
>requires it.
The only good ODO is a dead ODO.
>I've seen the arguments for ODO on searches.
>
>As the tables I search are rarely more than 1K in size (I think the largest
>I can remember doing in COBOL recent was 8K),and I do use SEARCH ALL on
>non-volatile data, I really don't care if it takes a few microseconds (or
>even milliseconds) longer. The table is in memory.
If it's in MEMORY, speed doesn't matter. I thought you were SEARCHing tables on disk.
(How do you do that in Cobol?)
>To me ODO is just ugly pointless code that buys you nothing in terms of
>saved space, so it doesn't deliver what it promises.
>
>The last time I used COBOL for an application that was time critical where a
>few Milliseconds MIGHT matter (it was a process control app), was nearly 30
>years ago and GO TO was employed to get out of routines fast. I wouldn't
>code normal COBOL apps like that and I don't use ODO in them either.
It is little known that ODO was invented in Russia. It's a Communist conspiracy to screw
up Western software.
| |
| Robert 2007-09-17, 3:55 am |
| On Mon, 17 Sep 2007 02:14:38 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:
>
>"Robert" <no@e.mail> wrote in message
> news:j6ore39s4saaeccj4mkfsghkb0s0blk19j@
4ax.com...
>
>Agan, your expereince is not the same as mine. In most (certainly NOT all)
>cases, SEARCH ALL is done on tables of things like "tax codes" "state
>abreviations", etc. Although it would certainly be "nice" if such code was
>dynamically read in, most that I have seen are "hard-coded" and the length of
>the table is changed when new entries are added (or entries removed).
That's how we did it in the Old Days. Today, a program change, no matter how trivil, takes
six months of approvals and testing. Hard coded tables, which were once cheap, have become
very expensive. It's easier to change a Reference Table in the database.
>Again, commonly (not always) when a smething needs to be "searched" in a file, a
>keyed (VSAM on IBM mainframes) are used and access is "direct" via the "searched
>upon" information.
Today, that's a index on a database table.
A smart program might cache the results of the last hundred lookups in a Cobol table. It
would look there first. The table shoudl be described with ODO so the search doesn't waste
time looking at filler entries.
| |
| Pete Dashwood 2007-09-17, 3:55 am |
|
"Robert" <no@e.mail> wrote in message
news:snore3pl4g4jglkiu4hmqn48967jiberjk@
4ax.com...
> On Mon, 17 Sep 2007 13:52:58 +1200, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz>
> wrote:
>
>
> The only good ODO is a dead ODO.
>
>
> If it's in MEMORY, speed doesn't matter. I thought you were SEARCHing
> tables on disk.
>
> (How do you do that in Cobol?)
>
>
> It is little known that ODO was invented in Russia. It's a Communist
> conspiracy to screw
> up Western software.
Yeah, them Commies is sly....
Just as well I never fell for it.
Pete.
--
"I used to write COBOL...now I can do anything."
| |
|
| In article <189re35chs8bfaq2riqhm1n0dod28c3qtr@4ax.com>,
Robert <no@e.mail> wrote:
>On Sun, 16 Sep 2007 00:26:57 +0000 (UTC), docdwarf@panix.com () wrote:
>
>
>I tried to make the tests represent typical usage AND I posted source
>code. If you think
>the test is unfair, say so or write your own test.
Were I to think such, Mr Wagner, I might consider doing such. Until I
state that I think such there's little reason to assume that I do.
[snip]
>
>We all plant our crops in the soil plowed by Micro Focus .. or something
>like that.
Or... nothing like that. Plural majestatus est... or something like that.
DD
| |
|
| In article <7jlre31oq6blvdmk49jl2974tctunhkr43@4ax.com>,
Robert <no@e.mail> wrote:
[snip]
>I spent years trying to prove that 2 is not the optimal division factor.
>Based on
>calculus, I really believed it was e - 1, which is approximately 1.7. I
>almost 'proved'
>it with tests. Years later I saw that 2 really IS the optimal division
>factor. On well, I
>tried.
'I try to make my words good 'n tender 'cause I might have to eat them
tomorrow' might be seen as a variation of 'Looking back and saying 'Oh,
that was but the folly of a decade past' might cause one to recall that
what one does, now, may be looked at, at some point... as the folly of a
decade past'.
(the second one is a memory-mangling of Nietzsche, I cannot recall the
original nor the source)
DD
| |
| Pete Dashwood 2007-09-17, 7:55 am |
|
<docdwarf@panix.com> wrote in message news:fcliei$57t$1@reader1.panix.com...
> In article <7jlre31oq6blvdmk49jl2974tctunhkr43@4ax.com>,
> Robert <no@e.mail> wrote:
>
> [snip]
>
>
> 'I try to make my words good 'n tender 'cause I might have to eat them
> tomorrow' might be seen as a variation of 'Looking back and saying 'Oh,
> that was but the folly of a decade past' might cause one to recall that
> what one does, now, may be looked at, at some point... as the folly of a
> decade past'.
>
> (the second one is a memory-mangling of Nietzsche, I cannot recall the
> original nor the source)
>
I've always thought that "Keep your words soft and sweet, for you may have
to eat them" was a Chinese proverb. But I can't cite and I haven't GOOGLEd,
so I could be wrong.
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Robert 2007-09-17, 7:55 am |
| On Sun, 16 Sep 2007 22:16:01 -0700, Richard <riplin@Azonic.co.nz> wrote:
>On Sep 17, 10:33 am, Robert <n...@e.mail> wrote:
>
>No, wrong. Itanium is 180nanom to 90nanom. Current stuff is down to
>40nanom.
Isn't the limit about 20 nanom? I may have been thinking 20 angstroms, which is 2.0 nm.
| |
|
| In article <ogrre3p3d1ps6i0kipohsgjpuog6chje0q@4ax.com>,
Robert <no@e.mail> wrote:
>On Mon, 17 Sep 2007 02:14:38 GMT, "William M. Klein"
><wmklein@nospam.netcom.com> wrote:
>
>
>That's how we did it in the Old Days. Today, a program change, no matter
>how trivil, takes
>six months of approvals and testing.
That might be, Mr Wagner, because in the Oldene Dayse the *real* work was
still being done by eyeshade-wearing, arm-gartered, quill-wielding
accountants in ledgers. Now that more data are being kept on a computer
it is necessary to make sure that changes introduced don't cause errors
when quarterly and annual processing are done.
(some people like seeing changes *banged* into Prod at a moment's
notice... and some people believe in 'job security via idiosyncratic
knowledge', as well)
[snip]
>A smart program might cache the results of the last hundred lookups in a
>Cobol table.
What an innovative thought... it is absoultely *nothing* like
IF INFILE-CURRENT-CLIENT NOT = WS-PREVIOUS-CLIENT
PERFORM A615872-GET-CLIENT-DATA THRU A615872-GCD-EX.
.... as used to be done in the Oldene Dayse.
DD
| |
| Howard Brazee 2007-09-17, 6:55 pm |
| On Sat, 15 Sep 2007 01:50:53 -0500, Robert <no@e.mail> wrote:
>Most people who use indexes believe it. Why else would they use indexes?
Habit.
| |
| Howard Brazee 2007-09-17, 6:55 pm |
| On Sat, 15 Sep 2007 21:19:28 -0700, Richard <riplin@Azonic.co.nz>
wrote:
>Do you really think that generalizing from a _single_ case has any
>value at all. Oh, wait, it supported your prejudice so it must be
>accepted as general.
I have the bumper sticker:
"Everybody generalizes from one example. At least, I do." - Steven
Brust
| |
| Howard Brazee 2007-09-17, 6:55 pm |
| On Mon, 17 Sep 2007 02:14:38 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:
>Agani, your expereince is not the same as mine. In most (certainly NOT all)
>cases, SEARCH ALL is done on tables of things like "tax codes" "state
>abreviations", etc. Although ti would certainly be "nice" if such code was
>dynamically read in, most that I have seen are "hard-coded" and the length of
>the table is changed when new entries are added (or entries removed).
>
>Again, commonly (not always) when a smething needs to be "searched" in a file, a
>keyed (VSAM on IBM mainframes) are used and access is "direct" via the "searched
>upon" information.
In real small sorted tables, I don't care whether a SEARCH ALL would
be optimized into a linear search - I avoid the command altogether.
| |
| Charles Hottel 2007-09-17, 6:55 pm |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:pabte318v4n344saoq74ifeh7u3t1f8v9n@
4ax.com...
> On Sat, 15 Sep 2007 01:50:53 -0500, Robert <no@e.mail> wrote:
>
>
> Habit.
When was the last time anyone posting here ever had a performance problem
whose solution was related to subscripting or indexing? Changing to indexes
in order to do a binary search being excluded. The few times that I have had
to optimize generally involved changing to a better algorithm. One program
on a 360/30 took over two hours. I changed it to use two 8000 byte
buffers (that was the largest I could make them due to storage constraints)
and the time dropped to 10 to 15 minutes. I have changed sequential sorts
to binary sort both hand coded using subscripts and using SEARCH ALL. The
hand coded subscript approach avoided searching any table entries that have
not been loaded with data just by proper setting of the HI subscript.
Although as Pete and other here have posted I don't recall ever having that
problem. Much later on I had to optimize a couple of programs that were
slow due to high volume random access of VSAM KSDS files. The solution was
to sort the input transactions which took away a lot of the randomness and
effectively resulting in cacheing where subsequent transaction could take
advantage of data already read by the previous transaction. I have not had a
performance problem of any type in the last 20 years.
I suggest we move on to another more interesting thread, perhaps one where
two fleas argue over which one owns the dog that they live on.
| |
| Robert 2007-09-17, 9:55 pm |
| On Mon, 17 Sep 2007 11:01:38 -0600, Howard Brazee <howard@brazee.net> wrote:
>On Mon, 17 Sep 2007 02:14:38 GMT, "William M. Klein"
><wmklein@nospam.netcom.com> wrote:
>
>
>In real small sorted tables, I don't care whether a SEARCH ALL would
>be optimized into a linear search - I avoid the command altogether.
Serial search is faster when the number of entries is fewer than 100 .. or maybe 50. One
would hope the compiler or library would switch automatically, but they don't.
| |
| Pete Dashwood 2007-09-17, 9:55 pm |
|
"Charles Hottel" <chottel@earthlink.net> wrote in message
news:13eu3serlerr449@corp.supernews.com...
>
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:pabte318v4n344saoq74ifeh7u3t1f8v9n@
4ax.com...
>
> When was the last time anyone posting here ever had a performance problem
> whose solution was related to subscripting or indexing? Changing to
> indexes in order to do a binary search being excluded. The few times that
> I have had to optimize generally involved changing to a better algorithm.
> One program on a 360/30 took over two hours. I changed it to use two
> 8000 byte buffers (that was the largest I could make them due to storage
> constraints) and the time dropped to 10 to 15 minutes. I have changed
> sequential sorts to binary sort both hand coded using subscripts and using
> SEARCH ALL. The hand coded subscript approach avoided searching any table
> entries that have not been loaded with data just by proper setting of the
> HI subscript. Although as Pete and other here have posted I don't recall
> ever having that problem. Much later on I had to optimize a couple of
> programs that were slow due to high volume random access of VSAM KSDS
> files. The solution was to sort the input transactions which took away a
> lot of the randomness and effectively resulting in cacheing where
> subsequent transaction could take advantage of data already read by the
> previous transaction. I have not had a performance problem of any type in
> the last 20 years.
>
Good post, re-establishing some perspective here...:-)
> I suggest we move on to another more interesting thread, perhaps one where
> two fleas argue over which one owns the dog that they live on.
Two fleas hop out of a theatre.
One says to the other: "Shall we walk home or catch a dog?"
Pete.
--
"I used to write COBOL...now I can do anything."
| |
|
| Robert wrote:
>
> Most people who use indexes believe [they are faster]. Why else would they use indexes?
I used indexes because I liked the way that they kept a table and its
pointer unified. I've also used indexes on large text-accruing tables.
I like the way they look. (And, I proved that they're a lot faster
than reference modification...)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \/ _ o ~ Live from Albuquerque, NM! ~
~ _ /\ | ~ ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ Business E-mail ~ daniel @ "Business Website" below ~
~ Business Website ~ http://www.djs-consulting.com ~
~ Tech Blog ~ http://www.djs-consulting.com/linux/blog ~
~ Personal E-mail ~ "Personal Blog" as e-mail address ~
~ Personal Blog ~ http://daniel.summershome.org ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ !O M--
V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e h---- r+++ z++++
"Who is more irrational? A man who believes in a God he doesn't see,
or a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| Charles Hottel 2007-09-18, 7:55 am |
|
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5l8qsuF70aj9U1@mid.individual.net...
>
>
> "Charles Hottel" <chottel@earthlink.net> wrote in message
> news:13eu3serlerr449@corp.supernews.com...
>
> Good post, re-establishing some perspective here...:-)
>
>
> Two fleas hop out of a theatre.
> One says to the other: "Shall we walk home or catch a dog?"
>
> Pete.
> --
> "I used to write COBOL...now I can do anything."
>
LMAO
| |
| pgx@pgrahams.com 2007-09-18, 6:55 pm |
| "Charles Hottel" <chottel@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
| |
| Howard Brazee 2007-09-18, 6:55 pm |
| On Mon, 17 Sep 2007 19:37:40 -0400, "Charles Hottel"
<chottel@earthlink.net> wrote:
>When was the last time anyone posting here ever had a performance problem
>whose solution was related to subscripting or indexing?
That has never been the solution for me.
| |
| Charles Hottel 2007-09-18, 6:55 pm |
|
<pgx@pgrahams.com> wrote in message
news:hjrve3hbgvbe06e474gjt8gdkgnaam5r6h@
4ax.com...
> "Charles Hottel" <chottel@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.
| |
| Robert 2007-09-18, 6:55 pm |
| On Mon, 17 Sep 2007 19:37:40 -0400, "Charles Hottel" <chottel@earthlink.net> wrote:
>
>"Howard Brazee" <howard@brazee.net> wrote in message
> news:pabte318v4n344saoq74ifeh7u3t1f8v9n@
4ax.com...
>
>When was the last time anyone posting here ever had a performance problem
>whose solution was related to subscripting or indexing?
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.
You showed the premise is false; I showed the solution isn't any faster. They probably
aren't convinced by either argument. They'll continue using indexes because .. indexes
were faster in the Old Days and that's what they've always done. Welcome to Cobol-land,
where thirty years ago seems like yesterday.
| |
| Judson McClendon 2007-09-18, 6:55 pm |
| "Robert" <no@e.mail> wrote:
>
> ... Speed is the only reason for using indexes. ...
Not entirely. Built in search and index offsets are handy as well.
--
Judson McClendon judmc@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."
| |
| William M. Klein 2007-09-18, 9:55 pm |
| "Robert" <no@e.mail> wrote in message
news:8sn0f35tq2j9hsrp75rulk5hsfksakvr8m@
4ax.com...
> On Mon, 17 Sep 2007 19:37:40 -0400, "Charles Hottel" <chottel@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
| |
|
| In article <8sn0f35tq2j9hsrp75rulk5hsfksakvr8m@4ax.com>,
Robert <no@e.mail> wrote:
>On Mon, 17 Sep 2007 19:37:40 -0400, "Charles Hottel"
><chottel@earthlink.net> wrote:
>
>
>Tell that to the people who use indexes because they THINK speed is a
>problem and indexes
>are a solution.
When such people start posting here, Mr Wagner, he might do just that.
[snip]
>They'll continue using indexes
>because .. indexes
>were faster in the Old Days and that's what they've always done. Welcome
>to Cobol-land,
>where thirty years ago seems like yesterday.
That might be due to the fact that thirty years ago was the last time some
of the modules were compiled, perhaps.
Anyhow... in my experience, Mr Wagner, that is the case in more places
than 'COBOL-land'... more than once I've heard a (n)decade-old person say
'I've thought/done it this way ever since I was a child'... and my
internal response is 'How interesting... on the one hand a child came to
the conclusions of a person several decades older; a bit precocious,
perhaps, but a Good Thing... on the other hand has this person seems to
have been unable to learn a new way of seeing/doing in the intervening
decades... and that is a  thing.'
DD
| |
| Pete Dashwood 2007-09-18, 9:55 pm |
|
"Robert" <no@e.mail> wrote in message
news:8sn0f35tq2j9hsrp75rulk5hsfksakvr8m@
4ax.com...
> On Mon, 17 Sep 2007 19:37:40 -0400, "Charles Hottel"
> <chottel@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.
Either way, it makes it pretty futile to respond to your posts, Robert.
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Charles Hottel 2007-09-18, 9:55 pm |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:SIZHi.263081$VU2.141742@fe02.news.easynews.com...
> "Robert" <no@e.mail> wrote in message
> news:8sn0f35tq2j9hsrp75rulk5hsfksakvr8m@
4ax.com...
> <snip>
> <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.
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'?
| |
| Robert 2007-09-19, 7:55 am |
| On Tue, 18 Sep 2007 21:58:41 -0700, Richard <riplin@Azonic.co.nz> wrote:
>On Sep 19, 1:55 pm, "Charles Hottel" <chot...@earthlink.net> wrote:
>
>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.
>
>
>He simply wants to denigrate anyone that has given advice on Cobol so
>that he becomes the sole messiah of 'good cobol'.
It's about time I got some recognition. All Hail!!
| |
| Robert 2007-09-19, 7:55 am |
| On Tue, 18 Sep 2007 21:41:57 -0700, Richard <riplin@Azonic.co.nz> wrote:
>On Sep 19, 1:48 pm, "Pete Dashwood"
><dashw...@removethis.enternet.co.nz> wrote:
>
>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.
| |
| Pete Dashwood 2007-09-19, 7:55 am |
|
"Robert" <no@e.mail> wrote in message
news:ojr1f31crnf222la325kviad8f67t8p9j7@
4ax.com...[color=darkred]
> On Tue, 18 Sep 2007 21:58:41 -0700, Richard <riplin@Azonic.co.nz> wrote:
>
>
> Someone said you can use indexes defined on one table for another. Seems
> weird to me; I've
> never tried.
>
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."
| |
| donald tees 2007-09-19, 6:55 pm |
| Pete Dashwood wrote:
> "Richard" <riplin@Azonic.co.nz> wrote in message
> news:1189886992.443101.194330@g4g2000hsf.googlegroups.com...
> D'jou think we might qualify that last to "Some of your claims..." or "Most
> of your claims..." or specify "ALL" for North Americans who don't use
> deductive logic? :-)
>
> Pete.
I think you miss the point on some of the wording stuff, Pete. A lot of
this usage is not really based on logic, but on manners. Blunt all
inclusive statements tend to be rude ... sort of an implicit "I don't
give a damn what you think". I think that transcends dialect, if understood.
RW, in fact, takes great pride in his rudeness. He seems to think that
it proves his intelligence. He enjoys being rude, which is why he ends
up in so many fights.
People fight back against rudeness in different ways. I just back out
of the conversation, unless I am really pissed off. You try to
reconcile and work around it. Richard is rude back, Bill becomes very
precise, etc.
Interesting places, newsgroups.
Donald
| |
| donald tees 2007-09-19, 6:55 pm |
| Charles Hottel wrote:
> <pgx@pgrahams.com> wrote in message
> news:hjrve3hbgvbe06e474gjt8gdkgnaam5r6h@
4ax.com...
>
> 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
| |
| donald tees 2007-09-19, 6:55 pm |
| Robert wrote:
> On Mon, 17 Sep 2007 19:37:40 -0400, "Charles Hottel" <chottel@earthlink.net> wrote:
>
>
> 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.
>
> You showed the premise is false; I showed the solution isn't any faster. They probably
> aren't convinced by either argument. They'll continue using indexes because .. indexes
> were faster in the Old Days and that's what they've always done. Welcome to Cobol-land,
> where thirty years ago seems like yesterday.
you are a rude XXXXXXX. plonk.
Donald
| |
| Judson McClendon 2007-09-19, 6:55 pm |
| "donald tees" <donaldtees@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@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."
| |
| Howard Brazee 2007-09-19, 6:55 pm |
| On Wed, 19 Sep 2007 10:59:14 -0400, donald tees
<donaldtees@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.
| |
| HeyBub 2007-09-19, 6:55 pm |
| donald tees wrote:
>
> you are a rude XXXXXXX. plonk.
>
Well, that's one.
RW was here a couple of years ago, managed to get plonked by almost
everyone. He then returned to the Mother Ship. Now he's back.
I guess they let him out, he got re-incarnated, developed tolerance to the
medicine, got bored with Tanzania, or something. Anyway, he'll probably be
gone by next spring.
| |
| donald tees 2007-09-19, 6:55 pm |
| Howard Brazee wrote:
> On Wed, 19 Sep 2007 10:59:14 -0400, donald tees
> <donaldtees@execulink.com> wrote:
>
>
> 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?
>
No, the exact opposite. I am saying that by the time you decide what
the main loop is, you are probably far enough into it that the major
efficiencies are relatively fixed. Maybe by the time you break it down
into program modules that is true.
Decisions like comparing various sorts are not as important as decisions
like "do I sort it, or do I keep it in an ordered data base from the
start and do lookups?"
> 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.
Closer to what I mean. Two completely different methodologies,
depending on requirements. I do not think that something like testing
indexing vs subscripting is going to make nearly as big a difference,
and is usually a moot point. There are exceptions to every rule, of
course, and such a tiny issue may turn out to be important in some very
specialized instance, but in the normal turn of things, micro-level
coding is a waste of effort.
Donald
| |
|
| In article <X9-dnYZshvgMLGzbnZ2dnUVZ_remnZ2d@golden.net>,
donald tees <donaldtees@execulink.com> wrote:
>Howard Brazee wrote:
[snip]
>
>Closer to what I mean. Two completely different methodologies,
>depending on requirements.
This is one of the reasons I've coded
READ INFILE
AT END SET NO-MORE-INPUT TO TRUE
NOT AT END
ADD 1 TO LOOKUP-TBL-ENTRY-NO
IF LOOKUP-TBL-ENTRY-NO > MAX-TBL-ENTRIES-ALLOWED
MOVE 'LOOKUP TABLE EXCEEDS MAX ENTRIES - CALL PROGAMMING'
TO WS-ABEND-REASON
GO TO ABEND-RTN
ELSE
MOVE INREC TO LOOKUP-TBL-ENTRY (LOOKUP-TBL-ENTRY-NO)
END-IF
END-READ
.... or reasonable facsimiles thereof. When data volume goes a certain
amount beyond program design then it's time to have a coder look at it...
if only to say 'Oh, we're not limited to 32K tables any more, let's bump
this baby up a few!'.
DD
| |
| Pete Dashwood 2007-09-19, 9:55 pm |
|
"donald tees" <donaldtees@execulink.com> wrote in message
news:SLqdnfXdv8OapWzbnZ2dnUVZ_remnZ2d@go
lden.net...
> Pete Dashwood wrote:
>
> I think you miss the point on some of the wording stuff, Pete. A lot of
> this usage is not really based on logic, but on manners. Blunt all
> inclusive statements tend to be rude ... sort of an implicit "I don't give
> a damn what you think". I think that transcends dialect, if understood.
Yes, you're right.
>
> RW, in fact, takes great pride in his rudeness. He seems to think that it
> proves his intelligence. He enjoys being rude, which is why he ends up in
> so many fights.
I think he likes to rattle cages and rock boats. I don't always agree with
HOW he does this, but I respect his right to do so in an unmoderated forum,
and it can be beneficial for all of us if it makes people re-evaluate what
"everybody knows"
>
> People fight back against rudeness in different ways. I just back out of
> the conversation, unless I am really pissed off. You try to reconcile and
> work around it. Richard is rude back, Bill becomes very precise, etc.
>
> Interesting places, newsgroups.
>
Yeah, ain't they, though :-)
This was a very insightful piece, Donald. I agree wholeheartedly with your
assessment, although I hadn't realised it as clearly as you expressed it.
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Robert 2007-09-19, 9:55 pm |
| On Wed, 19 Sep 2007 12:52:00 -0500, "HeyBub" <heybubNOSPAM@gmail.com> wrote:
>donald tees wrote:
>
>Well, that's one.
>
>RW was here a couple of years ago, managed to get plonked by almost
>everyone. He then returned to the Mother Ship. Now he's back.
>
>I guess they let him out, he got re-incarnated, developed tolerance to the
>medicine, got bored with Tanzania, or something. Anyway, he'll probably be
>gone by next spring.
The problem is I want to talk about Cobol while others want to defend the mainframe
culture. Perhaps there should be a new newsgroup: comp.lang.cobol.mainframe.
Notice I did NOT use the word dinosaur, even though that's what it's about.
| |
| Robert 2007-09-19, 9:55 pm |
| On Wed, 19 Sep 2007 13:28:48 -0700, Richard <riplin@Azonic.co.nz> wrote:
>On Sep 19, 11:43 am, Robert <n...@e.mail> wrote:
>
>Robert, you haven't demonstrated, or even attempted to, that _anyone_
>FALSELY believes this. It is merely an assertion from you that there
>are such 'legacy coders' and that on their systems indexes are not
>faster.
>
>Just because you have an optimizer that on your system can make
>subscripts almost as fast as indexes, or faster when doing nothing,
>proves absolutely nothing about _their_ systems. How much code did you
>have to rewrite to find something that actually did get optimized
>away ?
>
>First you need to find someone who does actually think indexes are
>faster, and then you need to show that they are wrong on _their_
>system.
I posted timing tests showing index and subscript run at the same speed. No one has posted
evidence that indexes are faster.
The only defense for indexes is invectives and ad hominem. Readers will decide which they
choose to believe. If indexes really were faster, defenders of the index would simply post
evidence showing it. They wouldn't resort to schoolyard insults.
>
>You have already admitted ignorance about indexes on at least one
>count.
>
>I have shown on my system that indexes _are_ (marginally) faster, and
>certainly no slower, even against COMP-5 and much faster against COMP.
>When will you look at actual evidence instead of just your
>prejudices ?
You showed speed is the same, which is exactly what I said.
>
>If there is no speed difference then the choice makes no difference.
>It isn't 'indexes' you are attacking it is some 'legacy coders', it is
>'choice'.
What an odd thing to say. I advocate modern Cobol; legacy coders have 'standards'
restricting their victims to 1970s style Cobol.
>What is it with you. Did you screw up some coding that used indexes
>and get fired for incompetence and are trying to put the blame on
>indexes, or legacy coders ? It was all their fault because they didn't
>know that Robert was superior ?
You're just taunting.
>
>No, Robert, they will continue using indexes because there is _NO_
>reason to change.
Here's a good reason: Cobol is being replaced by Java. Management found it easier to
change the language than do battle with the Cobol bureaucracy. It might not have happened
if Cobol people hadn't been assholes, as evidenced in this message.
| |
| Pete Dashwood 2007-09-20, 3:55 am |
|
"Robert" <no@e.mail> wrote in message
news:bhm3f3lhlko53ia8rbjg536gjqc95s344e@
4ax.com...
> On Wed, 19 Sep 2007 13:28:48 -0700, Richard <riplin@Azonic.co.nz> wrote:
>
>
> I posted timing tests showing index and subscript run at the same speed.
> No one has posted
> evidence that indexes are faster.
>
> The only defense for indexes is invectives and ad hominem. Readers will
> decide which they
> choose to believe. If indexes really were faster, defenders of the index
> would simply post
> evidence showing it. They wouldn't resort to schoolyard insults.
>
>
> You showed speed is the same, which is exactly what I said.
>
>
> What an odd thing to say. I advocate modern Cobol; legacy coders have
> 'standards'
> restricting their victims to 1970s style Cobol.
>
>
> You're just taunting.
>
>
> Here's a good reason: Cobol is being replaced by Java. Management found it
> easier to
> change the language than do battle with the Cobol bureaucracy. It might
> not have happened
> if Cobol people hadn't been assholes, as evidenced in this message.
>
Hang on a minute...
It's YOUR message... :-)
Seriously, Robert, you are saying that Java is replacing COBOL because of an
entrenched COBOL bureaucracy that wouldn't move with the times.
I would agree that that was a contributing factor, but in and of itself, no
way could that alone cause the shift.
Are you saying there has been no paradigm shift and Procedural code is still
the way to go?
(This is true for some existing legacy systems, and possibly for Batch
Processing, and that is why COBOL will be with us for a few years yet, but
the bulk of mission critical processing will be transfererred to Networked
solutions, and the development will be with OO languages.)
Most of the COBOL user base never embraced OO, even after COBOL supported
it. And a lot of that was because of what you are arguing. You are not
entirely wrong.
I appreciate your qualification in the statement:
"It might not have happened if Cobol people hadn't been assholes, as
evidenced in this message."
The "might" makes your statement worth thinking about (leaving aside the
colourful description of "COBOL people" :-))
On thinking about it, I am forced to the conclusion that while it MIGHT not
have happened if there had been a huge COBOL OO base that was delivering the
goods, it is pretty hard to call with any degree of certainty.
The world embraced OO and didn't use COBOL. (if the COBOL world had embraced
OO, it MIGHT have had a "balancing" effect and made more people take COBOL
seriously)
Even a dyed-in-the-wool COBOL advocate like myself, having used both OO
COBOL and other OO languages, can see that COBOL simply doesn't compete well
in this arena. (Actually, I spent several years building OO Components with
COBOL and it was fine for that; now I'm building them in C# and it is even
better. Mainly because it integrates seamlessly with the platform I'm using
(DotNET Framework) so I can use all of the FCL and do loads of things that
would require API calls in COBOL, with simple intrinsic language functions.)
We can speculate on what MIGHT have happened (and it is even fun to do so)
but we will never know.
To blame the intransigence of COBOL people for the demise of COBOL is not
entirely fair, even if there may be elements of truth to it.
There were many factors at work and no single one (apart maybe from missing
the paradigm shift) can be said to have caused the replacement of COBOL as
an on-site development language.
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| William M. Klein 2007-09-20, 3:55 am |
| Robert" <no@e.mail> wrote in message
news:ptl3f3h73j49rr3q148la84am7t8v59r1o@
4ax.com...
> On Wed, 19 Sep 2007 12:52:00 -0500, "HeyBub" <heybubNOSPAM@gmail.com> wrote:
><snip>
> The problem is I want to talk about Cobol while others want to defend the
> mainframe
> culture. Perhaps there should be a new newsgroup: comp.lang.cobol.mainframe.
>
<snip>
So, let me get this straight, you want to talk about "COBOL" but not about COBOL
as used on mainframes, but by your best guess is that 70% or so of COBOL is
running on IBM mainframes. Therefore, you think that the mainframes should get
a new newsgroup.
Does this seem logical to you? It sure doesn't to me.
Now, I did change your "defend the mainframe culture" to "talk about COBOL as
used on mainframes", but I think as I read your posts, you think that the latter
IS always the former.
If I thought that anywhere CLOSE to 70% of the (COBOL-related) posts in this
newsgroup were <IBM> mainframe oriented, I would be THRILLED.
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| William M. Klein 2007-09-20, 3:55 am |
| "Robert" <no@e.mail> wrote in message
news:bhm3f3lhlko53ia8rbjg536gjqc95s344e@
4ax.com...
> On Wed, 19 Sep 2007 13:28:48 -0700, Richard <riplin@Azonic.co.nz> wrote:
>
<snip>
> I posted timing tests showing index and subscript run at the same speed. No
> one has posted
> evidence that indexes are faster.
>
Did you read the Performance paper for Enterprise COBOL that I have mentioned in
a number of posts? Do you think those timings are not true? Do you still think
that 70% (or so) of all COBOL runs on IBM mainframes?
Again, what am I missing here?
(No problem with you saying that if a COBOL program is targeted for Micro Focus
on Unix platforms, you have yet to see any evidence that indices are ever FASTER
than subscripts. However, that is all you have demonstrated.)
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Roger While 2007-09-20, 7:55 am |
|
"HeyBub" <heybubNOSPAM@gmail.com> schrieb im Newsbeitrag
news:13f2obsnscsk09c@news.supernews.com...
> donald tees wrote:
>
> Well, that's one.
>
> RW was here a couple of years ago, managed to get plonked by almost
> everyone. He then returned to the Mother Ship. Now he's back.
>
> I guess they let him out, he got re-incarnated, developed tolerance to the
> medicine, got bored with Tanzania, or something. Anyway, he'll probably be
> gone by next spring.
>
This is getting confusing. I am also a RW :-)
Roger
| |
| donald tees 2007-09-20, 7:55 am |
| Pete Dashwood wrote:[color=darkred]
>
> I think he likes to rattle cages and rock boats. I don't always agree with
> HOW he does this, but I respect his right to do so in an unmoderated forum,
> and it can be beneficial for all of us if it makes people re-evaluate what
> "everybody knows"
I agree, completely. However, even if everyone has a right to be rude,
they do not have a right to courtesy back. Nor do they have a right to
attempted reasonable discourse.
Somebody starts deliberately rocking *my* boat, I just toss them
overboard. They can either act in a civilized manner, or swim alone. A
boat requires an appreciation of unspoken co-operation to stay afloat.
That is why navies are so formally correct.
Donald
| |
| donald tees 2007-09-20, 7:55 am |
| docdwarf@panix.com wrote:
> In article <X9-dnYZshvgMLGzbnZ2dnUVZ_remnZ2d@golden.net>,
> donald tees <donaldtees@execulink.com> wrote:
>
> [snip]
>
>
> This is one of the reasons I've coded
>
> READ INFILE
> AT END SET NO-MORE-INPUT TO TRUE
> NOT AT END
> ADD 1 TO LOOKUP-TBL-ENTRY-NO
> IF LOOKUP-TBL-ENTRY-NO > MAX-TBL-ENTRIES-ALLOWED
> MOVE 'LOOKUP TABLE EXCEEDS MAX ENTRIES - CALL PROGAMMING'
> TO WS-ABEND-REASON
> GO TO ABEND-RTN
> ELSE
> MOVE INREC TO LOOKUP-TBL-ENTRY (LOOKUP-TBL-ENTRY-NO)
> END-IF
> END-READ
>
> ... or reasonable facsimiles thereof. When data volume goes a certain
> amount beyond program design then it's time to have a coder look at it...
> if only to say 'Oh, we're not limited to 32K tables any more, let's bump
> this baby up a few!'.
>
> DD
Probably a good example for two reasons ... it shows a "semi-micro"
example that *is* within a program, yet is still an algorithmic difference.
I think most such differences, though, take place well before you get
into the middle of a single program. They take place at the design level.
Donald
| |
| donald tees 2007-09-20, 7:55 am |
| Roger While wrote:
>
> This is getting confusing. I am also a RW :-)
>
> Roger
>
>
Sorry Roger. ;< )
Donald
| |
| Howard Brazee 2007-09-20, 6:55 pm |
| On Wed, 19 Sep 2007 21:51:48 -0500, Robert <no@e.mail> wrote:
>What an odd thing to say. I advocate modern Cobol; legacy coders have 'standards'
>restricting their victims to 1970s style Cobol.
We have such standards which say nothing about EVALUATE, reference
modification, and END-IFs. So I am not restricted from using
these.
| |
| Howard Brazee 2007-09-20, 6:55 pm |
| On Wed, 19 Sep 2007 21:51:48 -0500, Robert <no@e.mail> wrote:
>Here's a good reason: Cobol is being replaced by Java. Management found it easier to
>change the language than do battle with the Cobol bureaucracy. It might not have happened
>if Cobol people hadn't been assholes, as evidenced in this message.
CoBOL people are pretty conservative, with a tiny minority moving on
to OO CoBOL, although a majority moved to beyond the oddly structured
code you used to push on this forum.
Conservatism makes decision making easy, and works quite well - until
our environment changes. So while we have methods that work very
well in the old environment, we need to adapt or retire. And
adaptation to the new world order is hard.
| |
|
| In article <LJidnU64f4e7-2_bnZ2dnUVZ_hqdnZ2d@golden.net>,
donald tees <donaldtees@execulink.com> wrote:
>docdwarf@panix.com wrote:
[snip]
[snip]
[color=darkred]
>
>Probably a good example for two reasons ... it shows a "semi-micro"
>example that *is* within a program, yet is still an algorithmic difference.
>
>I think most such differences, though, take place well before you get
>into the middle of a single program. They take place at the design level.
There's the rub, Mr Tees... at 'design level' one of my questions (if I'm
on-site for it or allowed to ask any) is 'what is the expected data
flow?'; I've heard - from Corner-Office Idiots, usually - 'That's a
goooood question... why do you think that is important?' and had to
explain that a system is designed using different criteria depending on
the amount of data running through it, just as one chooses a vehicle using
different criteria depending on the amount of stuff one wishes to move
around in it.
If the system gets used then the amount of data going through it may
increase... and, similarly to a vehicle, one will have to decide at which
point one puts aside the old three-speed Humber with handlebar-basket -
which was most suitable for moving one'sself around during one's earlier
years - and replaces it with a vehicle which can carry one'sself, one's
spouse and (n) children... perhaps a motorscooter (which in some places,
eg Southeast Asian countries, are made to carry all that and more),
perhaps an automobile of some sort, perhaps a van, etc.
DD
| |
|
| In article <bhm3f3lhlko53ia8rbjg536gjqc95s344e@4ax.com>,
Robert <no@e.mail> wrote:
[snip]
>Management found
>it easier to
>change the language than do battle with the Cobol bureaucracy.
Mr Wagner, this is confusing... how can a computer programming establish a
bureaucracy rather than the Management which employs it?
DD
| |
| SkippyPB 2007-09-20, 6:55 pm |
| On Wed, 19 Sep 2007 21:51:48 -0500, Robert <no@e.mail> wrote:
>On Wed, 19 Sep 2007 13:28:48 -0700, Richard <riplin@Azonic.co.nz> wrote:
>
>
>I posted timing tests showing index and subscript run at the same speed. No one has posted
>evidence that indexes are faster.
>
>The only defense for indexes is invectives and ad hominem. Readers will decide which they
>choose to believe. If indexes really were faster, defenders of the index would simply post
>evidence showing it. They wouldn't resort to schoolyard insults.
>
>
>You showed speed is the same, which is exactly what I said.
>
>
>What an odd thing to say. I advocate modern Cobol; legacy coders have 'standards'
>restricting their victims to 1970s style Cobol.
>
>
>You're just taunting.
>
>
>Here's a good reason: Cobol is being replaced by Java. Management found it easier to
>change the language than do battle with the Cobol bureaucracy. It might not have happened
>if Cobol people hadn't been assholes, as evidenced in this message.
That is one of the most ridiculous things I've heard..Java replacing
Cobol.
It was estimated in 1997 that 300 billion lines of code existed
worldwide, 80% were in Cobol.
It was estimated in 1999 that over 50% of mission-critical
applications still being coded in Cobol.
It was estimated in 2002 that there were ~2 million Cobol programmers,
~1 million Java, ~1 million C++.
It was estimated in 2004-05 that 15% of new applications developed in
Cobol, 80% include extensions into legacy programs
It is estimated that it costs $25 per line to replace Cobol.
To replace a Cobol program with Java or C/C++, may cost $100 million.
Ease of maintenance makes Cobol language of choice for vertical
markets. Companies do not want to invest in changing to a new
language.
(Note: estimates curtesy of Gartner Group).
Cobol is successful because it works in both horizontal and vertical
software markets.
A Vertical Software Market:
Cost many millions to produce, custom made for specified company,
encapsulate all business rules, and only a limited number of
copies may be in use;
Low profile, very high per copy replacement cost, and very long
lifespan
A Horizontal Software Market:
May still cost many millions to produce, but thousands or millions
of copies will be in use
High profile, low per copy replacement cost, short life span.
Java is falling out of favor in many industries in favor the newer
..NET and Mono.
Regards,
////
(o o)
-oOO--(_)--OOo-
"I knew I was an unwanted baby when I saw that my bath toys were a toaster
and a radio."
-- Joan Rivers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove nospam to email me.
Steve
| |
|
| Robert wrote:
> On Wed, 19 Sep 2007 13:28:48 -0700, Richard <riplin@Azonic.co.nz> wrote:
>
>
> I posted timing tests showing index and subscript run at the same speed. No one has posted
> evidence that indexes are faster.
>
> The only defense for indexes is invectives and ad hominem. Readers will decide which they
> choose to believe. If indexes really were faster, defenders of the index would simply post
> evidence showing it. They wouldn't resort to schoolyard insults.
I posted a defense of indexes that was neither invective nor ad hominem,
as have several other people. Proving that subscripts are "the same" on
one particular architecture/compiler is *not* sufficient reason to stop
using them!
Indexes are a facility that is somewhat unique to COBOL - a data item
associated with a particular table. In most other languages, you just
define a numeric variable, and use it to step through your arrays. That
doesn't mean that it's a superior technique, and many programmers
(myself included) prefer them because we have learned their usage.
>
> What an odd thing to say. I advocate modern Cobol; legacy coders have 'standards'
> restricting their victims to 1970s style Cobol.
I wholeheartedly agree with Richard on this point. Your argument is
pretty much "they're the same, so why not use mine?" Well, a perfectly
valid reply to that is "because I like doing it this equivalent but
familiar way."
You've shown that what used to be significant overhead with subscripts
is now gone in one particular environment. But, the completeness of
being able to define an array with (an) index(es) of its' very own
appeals to some people, who will continue to do it. Using an index
isn't 1970's COBOL.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \/ _ o ~ Live from Albuquerque, NM! ~
~ _ /\ | ~ ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ Business E-mail ~ daniel @ "Business Website" below ~
~ Business Website ~ http://www.djs-consulting.com ~
~ Tech Blog ~ http://www.djs-consulting.com/linux/blog ~
~ Personal E-mail ~ "Personal Blog" as e-mail address ~
~ Personal Blog ~ http://daniel.summershome.org ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ !O M--
V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e h---- r+++ z++++
"Who is more irrational? A man who believes in a God he doesn't see,
or a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| Robert 2007-09-20, 9:55 pm |
| On Thu, 20 Sep 2007 08:07:13 -0600, Howard Brazee <howard@brazee.net> wrote:
>On Wed, 19 Sep 2007 21:51:48 -0500, Robert <no@e.mail> wrote:
>
>
>CoBOL people are pretty conservative, with a tiny minority moving on
>to OO CoBOL, although a majority moved to beyond the oddly structured
>code you used to push on this forum.
>
>Conservatism makes decision making easy, and works quite well - until
>our environment changes. So while we have methods that work very
>well in the old environment, we need to adapt or retire. And
>adaptation to the new world order is hard.
This is about evolution versus revolution. The evolutionary approach is to change one
thing, give it enough time to succeed or fail (testing) before moving on to the next
change. The resolutionary approach is to change everything at once, for example to a new
language.
Evolution is inherentely safe; revolution is inherently prone to failure. Evolution is the
preferred approach. The problem is it may be too slow to keep up with environmental
changes, either because the environment is changing rapidly or because resistance to
change slows evolution to a crawl. With Cobol, the latter is the case. Institutionalized
foot dragging (standards) slowed Cobol's evolution so much that it was doomed to failure,
to fall behind even a moderate pace of environment change. The only alternative, albeit an
undesirable one, was a revolutionary change to another language: Java.
This could have been prevented by allowing Cobol to change at a normal rate. True
conservatives would have seen that, and thereby conserved Cobol.
What about the ones who destroyed Cobol with excessive resistance to change? They are
demonstrably not conservatives because they didn't conserve it. The most common
perjorative, dinosaur, might be appropriate. Dinosaurs became extinct because they were
incapable or unwilling to change . | | |