Prev: Help with Tcal
Next: COBOL Error Handling (was: What MF says about ROUNDED(was:Cobol Myth Busters
From: Anonymous on 20 Sep 2007 10:16
In article <bhm3f3lhlko53ia8rbjg536gjqc95s344e(a)4ax.com>,
Robert <no(a)e.mail> wrote:
>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?
From: LX-i on 20 Sep 2007 18:53
> On Wed, 19 Sep 2007 13:28:48 -0700, Richard <riplin(a)Azonic.co.nz> wrote:
>> 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_
> 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
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.
>> 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
> 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
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
From: Pete Dashwood on 20 Sep 2007 20:28
<docdwarf(a)panix.com> wrote in message news:fctv68$h53$1(a)reader1.panix.com...
> In article <LJidnU64f4e7-2_bnZ2dnUVZ_hqdnZ2d(a)golden.net>,
> donald tees <donaldtees(a)execulink.com> wrote:
>>> This is one of the reasons I've coded
>>> ... or reasonable facsimiles thereof. When data volume goes a certain
>>> amount beyond program design then it's time to have a coder look at
>>> if only to say 'Oh, we're not limited to 32K tables any more, let's bump
>>> this baby up a few!'.
>>Probably a good example for two reasons ... it shows a "semi-micro"
>>example that *is* within a program, yet is still an algorithmic
>>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.
Computer systems, not being modes of transport, can be designed generically
from day one and expanded as the need arises without necessarily having to
make major code changes. It's called "scalability".
"I used to write COBOL...now I can do anything."
From: Robert on 20 Sep 2007 20:36
On Thu, 20 Sep 2007 14:16:24 +0000 (UTC), docdwarf(a)panix.com () wrote:
>In article <bhm3f3lhlko53ia8rbjg536gjqc95s344e(a)4ax.com>,
>Robert <no(a)e.mail> wrote:
>>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?
That's easy. Management doesn't get involved with 'technical stuff'. It lets techies slug
it out between themselves. Thus we have a technical bureaucracy that is separate from the
political bureaucracy where management lives. Programming Standards are the primary tool
of the technical bureaucracy.
Techies falsely claim that management supports these technical standards. That's not true;
management couldn't care less.
On many methodology checklists, the whole development process is reduced to a single line
item out of some 150. It basically says 'you techies do whatever you want; we'll catch
your mistakes during testing.' The single line includes programming, unit testing, code
review. etc. That's not management support, that's management throwing up its hands.
From: Robert on 20 Sep 2007 20:59
On Thu, 20 Sep 2007 16:53:29 -0600, LX-i <lxi0007(a)netscape.net> wrote:
>You've shown that what used to be significant overhead with subscripts
>is now gone in one particular environment.
It's gone on all platforms, or soon will be.
> 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.
That's true. Indexes were introduced 'recently' in the '74 Standard. My how time flies.
I SAID most Cobol programmers will continue using indexes. Every obsolete technology has
its defenders. If you want to hear an uproar, just wait till the FCC pulls the plug on
analog TV and second generation (900 MHz) cell phones next year. Defenders will predict
the downfall of Western Civilization.