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: William M. Klein on 22 Sep 2007 00:40 "Robert" <no(a)e.mail> wrote in message news:gh29f3pge2r8ndkp9plkbtjdc1qib8avfq(a)4ax.com... > On Fri, 21 Sep 2007 00:29:49 -0700, Richard <riplin(a)Azonic.co.nz> wrote: <snip> >>Because indexes are tied to the occurs by the 'indexed by' you can't >>get the order of the subscripts wrong: x(a c b) will give an error if >>the correct order is x(a b c). Subscripts won't do that. > > Unless 'liberals' convince the compiler company to allow it, as they have. > Robert, Do you know of any compiler that does allow for index-names to be coded in the "incorrect" order? I don't. (I know of some that allow then to be used for other tables with identical structures - but not any that allow x (a c b) where x(a b c) would be correct. If you know of such a compiler, can you post a listing? -- Bill Klein wmklein <at> ix.netcom.com
From: Robert on 22 Sep 2007 00:44 On Sat, 22 Sep 2007 02:18:58 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: > > >"Robert" <no(a)e.mail> wrote in message >news:0hg6f3p406f6alsph4s3c2ef5u478bvq2t(a)4ax.com... >> On Wed, 19 Sep 2007 22:20:43 -0700, Richard <riplin(a)Azonic.co.nz> wrote: >> ><snip>> >> I'm throwing schoolboy insults at mainframers because they destroyed the >> programming >> language I love. >> >> I could easily have become a C, C++, C# or Java programmer. I did it full >> time for a year. >> I didn't love it like Cobol. >> >Could you explain how mainframe COBOL programmers destroyed COBOL, exactly? > >I am genuinely interested in your viewpoint, not looking for an argument. 1. Resistance to change. Applies to application code as well as language features. As a result, simple changes take too long and cost too much. 2. Substandard programming skill. In the mainframe/Cobol world, it is common to hear programmers say they are confused by complex conditionals and by NOT. That's not found in the culture of any other programming language. If a C# or Java contractor said that, he'd be fired for unsuitability. Logic is the foundation of programming. A programmer lacking logic skills is like an accountant lacking arithmetic skills. That's why in shops that do Real Programming, Cobol programmers are regarded as deadheads. Others mistakenly ascribe it to the language. They don't realize (or are too polite to say) it's really an attribute of the Cobol culture, most notably in mainframe shops 3. Programming standards that institutionalize bad programming and prohibit good programming. That's how they enforce 1. and defend 2. 4. Methodology (waterfall) that obstructs change. Testing standards that prevent reusable code. None of these are inherent to the Cobol language, but they found root in the mainframe/Cobol culture. I've worked at and managed mainframe Cobol shops that didn't have these deficiencies. Nowadays, such shops are running Unix.
From: LX-i on 22 Sep 2007 01:14 HeyBub wrote: > Probably I/O is, today, more efficient than table look-ups. The O/S has > buffered the last zillion reads and can probably find the desired record > faster than a program could in a table. With less chance of a mistake. I had to chuckle when I read this. :) Today, we sat through a preliminary report from a capacity planning company. Basically, if your "stretch factor" is 1, there is no queuing in your system. If it's a 2, there is as much queuing as their is work being done. Our reports system has been running slow, so that's why these folks came out. For 5 concurrent reports, our stretch factor is 12. For ten, it was up over 100. The bottleneck? Two disk partitions - 98%+ of the queuing was on those two partitions. I/O is not necessarily faster, depending on how it's used. :) -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ / \/ _ 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: LX-i on 22 Sep 2007 01:16 Pete Dashwood wrote: > "LX-i" <lxi0007(a)netscape.net> wrote in message > news:YaidncS6RurpsG7bnZ2dnUVZ_j6dnZ2d(a)comcast.com... >> Robert wrote: >>> 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. >> PICTURE was introduced in 68, if memory serves - is it obsolete too? > > I remember coding COBOL before there was a PICTURE clause (It was the COBOL > 59 compiler). We used SIZE, CLASS, and USAGE to achieve the same result. I > also remember being able to write OTHERWISE in an IF statement... happy > days...:-) heh... Of course, I said picture wasn't obsolete, but I know a lot of types now can be defined just with a USAGE clause. >> Just because something is old doesn't make it obsolete; sometimes its age >> is a testament to its usefulness. :) > > I keep telling my friends that, but they still think I'm obsolete...:-) Aw - tell 'em to take a hike. :) -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ / \/ _ 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: Robert on 22 Sep 2007 01:22
On Fri, 21 Sep 2007 09:52:17 -0700, Alistair <alistair(a)ld50macca.demon.co.uk> wrote: >I do wish you hadn't tugged my chain by bringing Evolution into the >argument. Especially as you don't appear to have much knowledge of how >Evolution works. > >Comments below: > >On 21 Sep, 01:16, Robert <n...(a)e.mail> wrote: >> On Thu, 20 Sep 2007 08:07:13 -0600, Howard Brazee <how...(a)brazee.net> wrote: >> >On Wed, 19 Sep 2007 21:51:48 -0500, Robert <n...(a)e.mail> wrote: >> > >> 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. > >Evolution is about incremental implementation of a multitude of >changes simultaneously (or even all at once). Wrong, it's about one change at a time. Recommended reading: Notes on the Synthesis of Form, by Alexander. It talks about how to design a teakettle, but is really about system development in the abstract. >> The resolutionary approach is to change everything at once, for example to a new >> language. >> >> Evolution is inherentely safe; > >Except for those who get left behind or out-competed or even those >blind evolutionary off-shoots which end up in dead-ends. Dead-end, left behind and out-competed depend on your definition of success, or which third party measure you choose to believe. I know poor people who live happy, rewarding lives. >> 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. > >You clearly don't have any idea why Cobol became so yesteryear and >java became the new fashion accessory. Conventional answer: Object Oriented. Wait a minute, Cobol has that. >> This could have been prevented by allowing Cobol to change at a normal rate. True >> conservatives would have seen that, and thereby conserved Cobol. > >Then which version of the myriad Cobols would be the one true cobol? There's only One True Cobol -- The ANS/ISO Standard. >> What about the ones who destroyed Cobol with excessive resistance to change? > >Resistance to change was not what killed Cobol. It's the easiest to talk about. Cobolers don't want to discuss the real reason -- lousy code. >> 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 .. except for a 'radical faction' that morphed into birds >> and an old school we now call crocodilians. Both are minor players in the biological >> world. > >And don't forget the mammals which also derived from the dinosaurs. >And just how rapidly do you expect creatures to evolve in order to >avoid being wiped out by a meteor strike? You chose a bad analogy. You're right about a bad analogy. You're wrong about mammals deriving from dinosaurs. Mammals originated during the carboniferous period, 350 to 300 million years ago. Dinosaurs originated during the triassic period, 230 million years ago, and hit their peak during the jurassic period, 150 million years ago. Didn't you see the movie? :) The two had common ancestors, most notably therapsids, which were the dominant animals during the permian period, 275 million years ago, before dinosaurs. |