On Tue, 17 Apr 2012 02:06:31 +1200, in bit.listserv.ibm-main Peter Dashwood wrote:
I'll put most of my comments at the end and have included the postings by Nomen Nescio and Peter Dashwood of New Zealand so that they go to the listserv as well as the newsgroup. Peter has been in the field for many years and has mainframe experience including CICS. I disagree with him in some areas but he is an expert in COBOL so this is a disagreement among those who know data processing and not one where people are quoting airline magazines. My comments apply mainly to IBM z series COBOL because that is the one I know most and the only one in current production that I have seen the code generation for since the RCA 301 bit the dust decades ago. See below >Nomen Nescio wrote: >> [email protected] (Jake anderson) wrote: >> >>> Hi All, >>> >>> Apology for asking a basic question and Being Ignorant. We know that >>> GO TO statments are a big "NO" in many production sites and one of >>> the reason being it monopolizes the entire CPU. >> >> Nothing you can do from a COBOL program can monopolize the CPU or >> even the OS in the z/OS environment. >> >>> Are there any documentation explaining about the GO TO statements >>> which clearly describes how it effects the System CPU and >>> performances ? >> >> Avoiding GO TO is a religious belief and it is wrong. It is not >> rooted in performance or other real considerations. GO TO is often >> the best way to code in COBOL. You should not write C like a COBOL >> programmer but you should also not write COBOL like a C programmer. >> People should code idiomatically and not try to make everything look >> like Pascal, C, etc. And let's be honest, by the time your program is >> compiled all those structured verbs are really nothing more than >> piles of GO TOs, usually 4 times as many as you would have generated >> if you simply coded GO TO in the first place because of the extra >> loops you have to code to be able to say you avoided GO TO. >> >> Blind obesance to Dijkstra's idiotic structured programming tenets >> will get you nowhere in the real world except long wall clock times. >> Do you really want to code according to the principles of a guy who >> never delivered anything in his life but reams of paper and diatribes >> about things he wasn't even involved in? He and his pals did more >> damage to commercial programming than any other single thing I can >> think of, maybe with the exception of the H1B program. >> >> The alternative to GO TO in COBOL is PERFORM which is much more >> costly than GO TO and most often contributes to poor program design >> by making everything a loop. Yes, most commercial processing is a big >> loop, but it is not necessarily concentric circles of loops. >> Structured programming assumes everything is algorithmic and consists >> of concentric loops. This is simply not a valid assumption for >> commercial COBOL code. Use the LIST option and compare the object >> code from a small sample program you write in two different ways, one >> using GO TO sensibly and one using PERFORM and avoiding GO TO >> entirely. Consider how much overhead those extra 5 instructions will >> make in a 5 or 10 million record batch run. Then consider how many >> more loops you had to code to do things you should have handled with >> GO TO like checking return codes from called routines, VSAM file >> status, etc. A good program is a good program and branching is part >> of life. If you can't write good COBOL with GO TO and PERFORM (very >> sparingly) then yes, you should focus on academic arguments and FUD >> to cover up the fact you have no idea what the compiler or OS are >> doing (see your opening question). >> >> If being a mindless lemming or meme is considered a virtue where you >> work and it wouldn't be the first place that was true, by all means >> avoid GO >> TO. It is often much safer to do the wrong thing that is now a >> standard than to do the right thing that isn't popular with the >> know-nothing generation. > >I really enjoyed this and it made me smile. > >Very well written. > >It made me remember (and God knows, I've been trying to forget it for many >years now... :-)) a seminar in London I attended where Michael Jackson (he >of "Jackson Structured Programming" fame, sadly, not the pop star (which >would have been much more entertaining and probably cost less...)) >vehemently evangelized the power of GOTO-less programming. The only trouble >was that anyone who looked at the tangled mess generated by his system would >simply be bewildered by it. I raised this point with him and he said it >didn't matter because that was generated code and nobody would be >maintaining it. Draw your own conclusions. (I can tell you that the code >generated from my own generators is not a tangled mess and, while it is >complex in places, I'm not ashamed to show it to people...AND, they CAN >alter it if they want to (although I don't recommend that)) > >GO TO is generally one of (if not THE) fastest executing instructions in the >set on most platforms. But the issue is not about efficiency, it is about >ease of maintenance. For COBOL, that's pretty important. (For Object >languages it really isn't; encapsulated functions and components tend not to >be maintained in the way that COBOL is. They do what they do. If that needs >to be changed Classes get overridden, extended, rewritten, or discarded. >Actually changing them is much too risky and usually unnecessary. > >The post was a little hard on Edgar Dijkstra; much of what he said was >tongue-in-cheek and his three basic functions of programming are true and >useful. I don't think we can dismiss the body of his work because he may not >have coded a three file merge in COBOL... > >I'm not really impressed by the old "5 or 10 instructions in a 10 million >record batch run..." chestnut. If you're processing volumes like that, for >Chrissake, load level and distribute the job. But I shouldn't comment on >batch processing; I see it as evil beyond imagination, a constant reminder >of the inadequacies of past system design and centralized hardware, and >something that has no place in a properly designed modern system which >should reflect the real world at any given moment. Waiting 24 hours to get a >result is just pathetic and lame. It means that no-one had the imagination >to build a proper system and implement it on a proper network with >appropriate processing power. > >I'm a fan of GOTO-less programming, but that's probably because I am one of >the know-nothing generation. :-) On the very rare occasions when I might >need to branch somewhere, I make sure that any GO TOs I code branch within >the local scope only (usually to an exit or entry point). It was amusing to >me that I had been writing C# for several years before I even knew it has a >GOTO command in it :-) I have never used it. > > The bottom line really is that there is no point in being passionate about >GO TO or GO TO-Less programming. Experienced programmers make informed >decisions and use what is needed and works. Modern equipment removes the >efficiency constraint (it doesn't matter what you code; processors are so >unimaginably fast it will all get processed in a time frame that doesn't >apply to Human Thought), and using GO TO as an excuse to write spaghetti >code is just one of many cardinal sins that really have no place in rational >computer programming. > >Pete. GO TO will not monopolize even one CPU since COBOL code executes in problem program state except for system routines invoked by I-O verbs such as OPEN and READ and other requests for system services. However starting with COBOL II V1R4, there was a major change in code generation which means that GO TO can prevent certain code optimization. The COBOL PERFORM verb unlike subroutine calls in many other languages assumes that a routine can either be PERFORMED or entered from the previous paragraph or section and the code can fall through to the next section. Elimination of the use of GO TO allows the compiler to use simpler entry exit code and to use code movement where the code for a PARAGRAPH can be moved inline so that there is no branching. The code for PERFORM UNTIL also was greatly improved. In short, I modified my coding techniques to eliminate GO TO because the PERFORM optimization is so good and GO TO had little value for ease of code in most circumstances. Contrary to Norman's comments I have found most of the code generated by the newer IBM COBOL compilers quite good when using the right options and the use of structured code easier to read 6 months later. Now if IBM would only implement the 2002 Standard's EXIT PERFORM, EXIT PARAGRAPH and EXIT SECTION. Code which was very efficient using COBOL VS (the 1974) standard became less so with VS COBOL II V1R4 through Enterprise COBOL. Unfortunately our shops probably are in just a maintenance mode regarding COBOL and would have no interest in taking advantage of the efficiencies in coding and performance associated with the newer constructs in the 2002 COBOL standard. Clark Morris ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
