On Wed, 18 Apr 2012 23:04:51 +0200 (CEST), in bit.listserv.ibm-main Nomen Nescio wrote:
* this is a response to a posting to just the newsgroup and not the listserv >mathwst...@bellsouth.net (Matthew Stitt) wrote: > >> Having said that, I still use GO TO extensively, and have not kept up with >> the "modern" programming extensions and constructs. >> I've had many instances in my career where a "structured" program has been >> "straight lined" with extremely dramatic performance >> results. Mostly I believe that knowing Assembler language and how the COBOL >> compiler would generate the assembler code version >> of the program provided the reasons for my coding techniques. I would write >> the program as close to what the assembler code >> would be as possible. This would usually provide some great performance >> at run time (and at compile time). > >&& > >> One example (out of several) was a program which normally took 4-6 hours to >> do its magic. When I re-wrote it due to the necessity >> of adding more functionality, I went ahead and "straight lined" it according >> to the logic of what the program was supposed to do. >> When the re-write was finished, the new program took 20 minutes to run the >> first time it was in production. I have several other >> examples with these type of results. > >This gets back to what I said. PERFORM is net 5 instructions more *per PEFORM* >than two GO TOs (to and fro) so loops processing millions of records get very >expensive fast and avoiding GO TO by being forced to use PERFORM causes you >to create more loops than you would have used with GO TO since it changes >the paradigm from essentially full steam ahead (straight line) to LET'S MAKE >A LOOP! Last time I looked, COBOL doesn't inline PERFORM so you pay the >penalty hundreds or thousands of millions (yeah billions, definitely >billions) of times in a big program processing a big file. And paging is >usually significantly worse because of the unnatural long branches caused by >PERFORM, when straight line coding with careful use of GO TOs would have >reduced paging since only errors and stuff like page breaks are handled out >of line. What you are saying was true with the COBOL VS (1974 standard) compiler. If you use OPTIMIZE AND do not reach any PERFORMed paragraph via GO TO or fall through, with VS COBOL II V1R4 and subsequent 390 and z compilers, the PERFORM will NOT take 5 instructions and depending on various conditions the PERFORM will be replaced by the code of the paragraph being PERFORMed. Having coded many programs using ALTER switch-paragraph TO next-para GO TO process-paragraph to save perform overhead, the change was dramatic. The addition of inline PERFORM, the EVALUATE statement and the END-IF, END-EVALUATE etc. statements have drastically changed the ball game. If you are still coding COBOL for use on IBM z series boxes spend time reading both the Language Reference and the Programmers Guide. Understand and select the OPTIMIZE and TRUNC options that work in the environment you are coding for and then code some programs and look at the code generated. Programs with large numbers of GO TO statements will drive the optimizer crazy. I just wish that IBM would find it worth while to add the really useful constructs in the 2002 standard such as USAGE BIT, bit manipulation, EXIT PARAGRAPH and others. However if the majority of programmers remain actually or mentally stuck on the 1974 compiler, it probably would be a waste of money. Clark Morris > >> Also, CICS used to treat the "HANDLE CONDITION" API as a GO TO, not a >> perform. Went to the Well in the early-mid 80's over that >> one with a bunch of certain "whiz-kids" who were trained under the good >> doctors premises. > >Thanks for your post, it is what I experienced as well and not just once but >dozens of times. In the old days this was never a question but decades later >I fixed a lot of code by tearing out the spaghetti PERFORMS and processing >forward in an orderly fashion. It is easier to understand and maintain and >it works a lot better. For COBOL and assembler programmers that is. I don't >really care what the C and Java crowd think of it and if they push me I'll >rip out all their do whiles and fors and replace them all with GOTOs. Don't >make me open this can! > >Practical experience beats the college boys every time, especially burnt-out >duffers like Dijkstra who never sold a line of code and probably never wrote >one either. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
