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: SkippyPB on 22 Sep 2007 12:08 On Fri, 21 Sep 2007 23:44:23 -0500, Robert <no(a)e.mail> wrote: >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. WOW! You need to put on large fishing boots to keep you knees out of the muck while reading the above! 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
From: Robert on 22 Sep 2007 12:44 On Sat, 22 Sep 2007 23:20:35 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: > > >"Robert" <no(a)e.mail> wrote in message >news:1fs8f3pd7mmkhnnf1s26a01df4bprbdr4f(a)4ax.com... >> On Fri, 21 Sep 2007 12:48:55 -0600, Howard Brazee <howard(a)brazee.net> >> wrote: >> >>>On Thu, 20 Sep 2007 19:46:02 -0500, Robert <no(a)e.mail> wrote: >>> >>>>Unexpectedly, the demand and pay for PL/SQL is sky high. It's number two >>>>after Java, ahead >>>>of C++ and dot-net. Evidently there are shops that write everything in >>>>PL/SQL and SQR. How >>>>desperate and sad. >>> >>>Why desperate? >>> >>>Sure, I would have more power if there was greater demand for my >>>skills, but I'm not selfish enough to wish the world would be designed >>>around me. (Unlike certain politicians) >> >> Because SQL isn't generalized enough to 'do everything'. It has difficulty >> doing things >> that are easy in traditional programming languages. If the only tool you >> have is a >> database query language, every problem looks like a query problem. > >Have you looked at the latest standard for SQL? It is very hard to >distinguish from a programming language. There are three 'new' SQL Standards: 99, 03 and 06. The most important changes were made in 99, which has been criticized for abandoning the relational model because it permits structures with more than two dimensions. The Standard committee could have saved time by simply adopting PL/SQL or PERL as the procedural language. SQL is similar to 02 Cobol in that vendors are treating it like a Chinese menu, adopting selected features rather than a whole Standard version. The 800 pound gorilla, Oracle, is seen as a de facto standard.
From: Charles Hottel on 22 Sep 2007 15:30 "Robert" <no(a)e.mail> wrote in message news:3kcaf394t2qabq20kh2beeu413ujua7gp6(a)4ax.com... > On Sat, 22 Sep 2007 03:20:19 -0600, Jeff Campbell <n8wxs(a)arrl.net> wrote: > >>Robert wrote: >>> On Fri, 21 Sep 2007 11:09:16 GMT, "William M. Klein" >>> <wmklein(a)nospam.netcom.com> wrote: >>> >>>> "Robert" <no(a)e.mail> wrote in message >>>> news:i3j6f3pa7ucignv34t4oklno0ht8jh2c5p(a)4ax.com... >>>>> On Fri, 21 Sep 2007 04:21:35 GMT, "William M. Klein" >>>>> <wmklein(a)nospam.netcom.com> wrote: >>>>> >>>> <snip> >>>>> I and Richard posted facts showing speed is the same. We have not seen >>>>> facts >>>>> from >>>>> mainframe-land,except a five year old study. Just post some facts and >>>>> skip the >>>>> ad homina. >>>> I do NOT have personal access to an Enterprise V3.4 COBOL compiler - >>>> and I do >>>> believe what IBM says about its performance (and don't believe that you >>>> know how >>>> they implement all their syntax -> machine code). HOWEVER, >>>> >>>> If you create a source program that you think tests subscripts vs >>>> indexes >>>> (whether it is comprehensive or not), then I think some CLC person >>>> might compile >>>> and run it for you. >>>> >>>> Therefore, please create and post a sample program that cleanly >>>> compiles with >>>> the Micro Focus directives: >>>> NOMF DIALECT(ENTCOBOL) FLAGAS(S) >>>> >>>> If you are not using a current-enough version of Server Express to >>>> include >>>> support for the DIALECT directive, then use: >>>> NOMF ENTCOBOL FLAG(ENTCOBOL) FLAGAS(S) ARITHMETIC(ENTCOBOL) >>>> PERFORM-TYPE(ENTCOBOL) >>> >>> That's not necessary. The code I posted is Standard-compliant except for >>> comp-5, which we >>> all know IBM can handle. >> >>No, it wasn't. Such things as mixed sectioned, non-sectioned code; exit >>section statements not in separate paragraphs; linkage section declared >>without a using clause in the procedure division. I could go on. > > Those things were in the first test, named speed1. The subscript v. index > test, named > speed2, does not have them. > > The current '02 Standard does not prohibit any of the things you > mentioned. Especially, it > does not require exit section to be in a separate paragraph, nor under a > paragraph name. > >>>> If you post such a program and no one else in CLC compiles and runs it >>>> (and >>>> posts the results) I will find someone who can and will. >>> >>> Any volunteers? > Speed1 is the only program I saw posted. When did you post it? I just searched Google groups for "speed2" and got no hits.
From: Robert on 22 Sep 2007 15:35 On Sat, 22 Sep 2007 05:52:35 -0700, Alistair <alistair(a)ld50macca.demon.co.uk> wrote: >On 22 Sep, 06:22, Robert <n...(a)e.mail> wrote: >> On Fri, 21 Sep 2007 09:52:17 -0700, Alistair <alist...(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. >> > >So, a bad analogy (Evolution) is being justified as applicable to >programming based upon a book telling me how to design a kettle? Again >you have failed. Evolution happens on many fronts simultaneously. A >successful evolution in one factor may result in the carriage of a >multitude of factors to the improved evolutionary form. Only some of >those improvements will be beneficial and many will be detrimental. >You can take the human as an example of the 'ultimate' evolved >organism on the planet. There is no form factor that the human has >that can be said to be the sole reason as to why we have become so >successful. However, other factors can be shown to be barely adequate >or even detrimental to human success: fallen arches; poor spinal >strucure; poor vision.... > >Evolution may appear to be one change at a time to a naive observer >but, in fact, there are many changes occuring all of the time. Here's more about Alexander's ideas, from the blog of a Swedish programmer, Peter Lindberg: Christopher Alexander�s OOPSLA �96 keynote is quite fascinating. Software patterns capture proven ideas in a convenient format, and surely you hear the idea that if you�re savvy about patterns and use them frequently, your software will be well-architected. (One of the early papers on patterns, by Kent Beck and Ralph Johnson, was titled Patterns Generate Architectures; I guess I should re-read that one.) In the keynote, Alexander says that his idea of pattern languages goes well beyond that: it was intended to generate �living structure [and] coherent wholes�, even when applied by laymen. Alexander mentions that he, after having worked for a while with pattern languages, found out that they didn�t succeed: [T]he buildings generated [by people using the patterns] were okay, but not profound. [���] I [�] realized that whatever was going wrong wasn�t going to be corrected by writing a few more patterns or making [them] a little bit better. There seemed to be something more fundamental that was missing from the pattern language. At about the same time I began to notice a deeper level of structure and a small number (fifteen) of geometric properties that appeared to exist recursively in space whenever buildings had life. These fifteen properties seemed to define a more fundamental kind of stuff; similar to the patterns we had defined earlier, but more condensed, more essential � some kind of stuff that all good patterns were made of. These were simple ideas. [P]roperties like �boundaries� which will not only delineate but connect the inside to the outside, or �positive space,� as when you look at a Matisse cutout and see that the space between the colored paper is not amorphous but also has form. These fifteen principles seem hard to swallow, but an immense amount of work has gone into them. For instance, Alexander has conducted experiments to verify that the presence of the fifteen principles in an object is empirically testable. People have been shown two objects and asked which of them makes them feel �more whole� or �more alive�. He writes: �it turns out that there is quite a striking statistical agreement, 80-90%, very strong, as strong a level of agreement as one gets in any experiments in social science.� In addition, he has written a series of four books about this, titled The Nature of Order: An Essay on the Art of Building and The Nature of the Universe. (The books have a website.) So, it doesn�t seem to be mere aesthetic principles. And the following claim (also from the keynote) is stunning: Compared to the pattern language that you�ve seen in A Pattern Language [Amazon.com] these generative schemes are much more like what you call code. They are generative processes which are defined by sets of instructions that produce or generate designs. They are, in fact, systems of instructions which allow unfolding to occur in space in just the way that I was talking about a minute ago [�], and are therefore more capable of producing living structure. The published pattern language by comparison is static. The new generative languages are dynamic and, like software, interact with context, to allow people to generate an infinite variety of possible results � but, in this case, with a built-in guarantee of well-formed results. The design that is created is guaranteed, ahead of time, to be coherent, useful, and to have living structure. He talks about paradigms and how the major players of the old paradigm aren�t the major players of the new paradigm. He says that architects may never realize this and suggests that programmers should become the new architects, by creating software that embodies these patterns and generative languages to support builders: What I am proposing here is [�] a view of programming as the natural genetic infrastructure of a living world which you/we are capable of creating, managing, making available, and which could then have the result that a living structure in our towns, houses, work places, cities, becomes an attainable thing. That would be remarkable. It would turn the world around, and make living structure the norm again [�] http://tesugen.com/archives/03/06/patternkeynote2 As I understand it, Alexander is supporting Pete's idea that design should be self-aware, recursive, what some call 'interactive'. The Pattern Languages he finds inferior are analogous to waterfall Cobol, being 'static', pretending the designer is capable of anticipating every turn of events that will occur during the creation of a system. >> >> 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. > >I'm poor, unhappy and lead a life that is largely unfulfilling. A >generalised example does not prove your case. That is an argument that >has raged elsewhere in this newsgroup. > >> >> >> 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. > >QED. > >> >> >> 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. > >And all the other evolutionary forms of cobol have satisfied your >requirements for change and yet you persist in denigrating cobol for >its' failure to adapt and change. Practitioners rejected changes to the language spec. They prefer to write Cobol in a style that hasn't changed in 20 years. Also, the changes were too little, too late. We didn't see foot-dragging when C++ was created in 1979. >> >> 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. > >It has already been observed by others that it is easier to write >cruddy code in Java than in Cobol. I believe that, with the wrong >attitude and poor application, it is possible to write cruddy code in >any computing language (with the possible excepetion of Befunge where >it could be argued that any program which executes is a success). Authors of cruddy Java KNOW they're writing crud; it takes a conscious effort. Authors of cruddy Cobol THINK they're writing good code. When I once wrote cruddy Cobol for a magazine article, the effort was more difficult than I expected. Numbered paragraphs and perform thru were easy. The hard part was cruddy structure and logic, for instance the bloat of redundant code.
From: LX-i on 22 Sep 2007 17:28
Pete Dashwood wrote: > "LX-i" <lxi0007(a)netscape.net> wrote in message > news:s8GdnRHyUvA0OGnbnZ2dnUVZ_g-dnZ2d(a)comcast.com... >> Pete Dashwood wrote: >>> "LX-i" <lxi0007(a)netscape.net> wrote in message >>> news:YaidncS6RurpsG7bnZ2dnUVZ_j6dnZ2d(a)comcast.com... >>>> 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. :) > > Not likely. They'd drag me off my couch to go with them... :-) Heh... We took a hike with the Cub Scouts last weekend. I was looking through my oldest son's workbook, and one of this tasks was "take a hike of at least 3 miles with your den". I started adding it up - 1.2 miles up, 1.2 miles back, .5 miles to and from the split each way... No *wonder* I was tired when we got back! :) > (Thanks for the support, anway, Daniel... :-)) Any time... -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ / \/ _ 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 |