Re: GO TO cobol
On Sun, 29 Apr 2012 16:22:48 +0200 (CEST), Nomen Nescio nob...@dizum.com wrote: much snipped Newsgroups: bit.listserv.ibm-main,comp.lang.cobol Subject: Re: GO TO cobol References: 9v9ac3fpj...@mid.individual.net Message-ID: 0820aa7adfc1d5a4b35ae840243ab...@dizum.com Date: Thu, 19 Apr 2012 11:42:24 +0200 (CEST) snip I wrote COBOL doesn't inline PERFORM. A coder can choose to code an inline PERFORM, so there is a good example of one thing the coder can do better in source than the compiler. If PERFORM READ-RECORD performs a paragraph that CAN NOT be reached via GO TO or a fall through from the previous paragraph AND there is no GO TO or GOBACK / STOP RUN / EXIT PROGRAM in the paragraph AND the OPTIMIZE option is chosen on any IBM 370 / 390 / z series compiler starting with VS COBOL II V1R4, the code may well be inlined (moved out of sequence). I have verified this by reading the procedure division map produced by the compiler. There have been SHARE presentations given by Tom Ross of IBM COBOL development in Santa Teresa stating this and noting that a paragraph may be copied to more than one place. Based on my reading of the generated code back in the 1990s I changed my code to ONLY use PERFORM and NEVER PERFORM ... THRU on new programs. This change in how things worked also allowed me to simplify nested IF ... END-IF statements by moving appropriate nesting levels to a separate paragraph with no loss of efficiency because the compiler moved the statements back in line. Another optimization that came in at the same time was recognizing that an offset related to a subscript had been calculated and using that offset for subsequent subscripted references thus eliminating the value of moving entries to a work area. Any time you get a new version of a compiler in any language, read the manual to see what coding changes would be beneficial and what compiler options can work in your environment. Some techniques that were valuable with the COBOL VS (1974 standard) and saved time using the right OPTIMIZE options became counter productive with VS COBOL II V1R4. Clark Morris snip I wrote PERFORM READ-RECORD. PERFORM SOMETHING ELSE. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 4/26/2012 3:46 AM, Shmuel Metz (Seymour J.) wrote: 3. Rexx does not have a GOTO. Those who try to use SIGNAL as if it were GOTO often shoot themselves in the foot as a result Wow! Not only does Rexx not support GOTO, but if you try to use it you get an infinite loop! Consider the following test program: /* REXX */ trace i goto a say 'the goto failed' exit a: say 'the goto worked' exit If you execute under TSO on z/OS 1.13 you get: 3 *-* goto a L GOTO L A O GOTO A 3 *-* goto a L GOTO L A O GOTO A 3 *-* goto a L GOTO L A O GOTO A 3 *-* goto a L GOTO L A O GOTO A 3 *-* goto a L GOTO L A O GOTO A 3 *-* goto a L GOTO L A O GOTO A 3 *-* goto a L GOTO L A O GOTO A 3 *-* goto a L GOTO L A O GOTO A .. (never-ending loop...) -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 4/27/2012 3:18 PM, Edward Jaffe wrote: On 4/26/2012 3:46 AM, Shmuel Metz (Seymour J.) wrote: 3. Rexx does not have a GOTO. Those who try to use SIGNAL as if it were GOTO often shoot themselves in the foot as a result Wow! Not only does Rexx not support GOTO, but if you try to use it you get an infinite loop! Consider the following test program: /* REXX */ trace i goto a say 'the goto failed' exit a: say 'the goto worked' exit If you execute under TSO on z/OS 1.13 you get: 3 *-* goto a L GOTO L A O GOTO A 3 *-* goto a L GOTO L A O GOTO A 3 *-* goto a L GOTO L A O GOTO A 3 *-* goto a L GOTO L A O GOTO A 3 *-* goto a L GOTO L A O GOTO A 3 *-* goto a L GOTO L A O GOTO A 3 *-* goto a L GOTO L A O GOTO A 3 *-* goto a L GOTO L A O GOTO A .. (never-ending loop...) But, Ed, it does have DO FOREVER. I like to joke You gotta' love a language that does not have a GOTO but does have a DO FOREVER So somehow you've combined the two in one exec! Very strange behavior. Do you have a local TSO command called 'goto'? When REXX sees a command it does not know, it passes it to the underlying host as a host command. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 4/27/2012 2:40 PM, Steve Comstock wrote: But, Ed, it does have DO FOREVER. I like to joke You gotta' love a language that does not have a GOTO but does have a DO FOREVER LOL! Actually, DO FOREVER is _extremely_ useful. We have the same control structure in HLASM called DO INF (infinite). So somehow you've combined the two in one exec! Very strange behavior. Do you have a local TSO command called 'goto'? When REXX sees a command it does not know, it passes it to the underlying host as a host command. That's it, Steve! The name of my test EXEC is 'GOTO'. So, it was executing itself recursively! :-D -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 4/27/2012 3:18 PM, Edward Jaffe wrote: That's it, Steve! The name of my test EXEC is 'GOTO'. So, it was executing itself recursively! :-D Now that I've renamed it, I get the following expected behavior: 3 *-* goto a L GOTO L A O GOTO A IKJ56500I COMMAND GOTO NOT FOUND +++ RC(-3) +++ 4 *-* say 'the goto failed' L the goto failed the goto failed 5 *-* exit *** -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Back in my NOMAD days, those types of Nomad procedures were called NOBOL programs: Nomad COBOL. We had lots of people tryng to follow COBOL structure to write Nomad and many of them ended up with similar issues. Lloyd - Original Message From: Edward Jaffe edja...@phoenixsoftware.com To: IBM-MAIN@bama.ua.edu Sent: Fri, April 27, 2012 6:19:05 PM Subject: Re: GO TO cobol On 4/27/2012 2:40 PM, Steve Comstock wrote: But, Ed, it does have DO FOREVER. I like to joke You gotta' love a language that does not have a GOTO but does have a DO FOREVER LOL! Actually, DO FOREVER is _extremely_ useful. We have the same control structure in HLASM called DO INF (infinite). So somehow you've combined the two in one exec! Very strange behavior. Do you have a local TSO command called 'goto'? When REXX sees a command it does not know, it passes it to the underlying host as a host command. That's it, Steve! The name of my test EXEC is 'GOTO'. So, it was executing itself recursively! :-D -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On Fri, 27 Apr 2012 15:18:05 -0700, Edward Jaffe wrote: That's it, Steve! The name of my test EXEC is 'GOTO'. So, it was executing itself recursively! :-D At times when I want to write pure Rexx, insensitive to default command environment, I start my EXEC with address NOTHING and explicitly qualify each command, range of commands, or procedure. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
In 4f959964.2060...@phoenixsoftware.com, on 04/23/2012 at 11:03 AM, Edward Jaffe edja...@phoenixsoftware.com said: http://proceedings.share.org/client_files/SHARE_in_San_Jose/S8133EJ131525.pdf A few comments: 1. Most of the macro instructions the paper mentions come with the HLA toolkit. I'm not sure how they compare to the older Concept 101 macros, which I haven't used in decades. 2. The paper by Böhm and Jacopini makes much narrower claims than what is often attributed to it. 3. Rexx does not have a GOTO. Those who try to use SIGNAL as if it were GOTO often shoot themselves in the foot as a result. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
The finding that fewer explicit GOTOs are used and need be used in writing a routine in a statement-level language that makes the standard structured-programming figures available is at once trivial and important. As I noted in an earlier post I tend to use GOTOs chiefly in recursive processing, which the structured-programming theorists have largely ignored. If and when they formalize and implement recursive figures that meet my needs, I will of course use them. Until then I will continue to use GOTOs, implemented as cleanly as I know how in at least locally standard ways. What I have found at once odd and a distressing is all of this late-in-the-day zealotry. I feel no lively sense of guilt when I use a GOTO, and I doubt that programming students shoulkd be taught to do so. GOTOs are and will be infrequent in well written code., but anathema are dubious here and elsewhere. They belong to another, prescientific tradition. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 4/24/2012 4:33 AM, David Crayford wrote: snip http://proceedings.share.org/client_files/SHARE_in_San_Jose/S8133EJ131525.pdf That's a very interesting presentation. If I were coding in assembler I would follow! If IBM had made PL/X generally available would you have used that, or still used assembler? PL/X? Possibly. It would have required a firm support commitment from IBM. My fervent hope is that HLASM will eventually support these constructs (and my extensions to the language syntax provided by FLOWASM) natively, without requiring the use of macros or exits. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
In 4f972a24.4020...@phoenixsoftware.com, on 04/24/2012 at 03:33 PM, Edward Jaffe edja...@phoenixsoftware.com said: It finds that GOTO is most often used when the programmer is attempting to write more efficient code yet tends to have exactly the opposite effect. Attempts at micro-optimization often have the opposite effect to that which is intended. I'd be interested in a study of efficiency issues when GOTO is used only to implement control structures not natively available. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On Wed, 25 Apr 2012 22:58:17 +0200, Fritz Wuehler fr...@spamexpire-201204.rodent.frell.theremailer.net wrote: HeyBub hey...@nospamgmail.com wrote: Nomen Nescio wrote: If you've already done it, get someone to show you the miracle of cut-and-paste. I'd like to see the code. Sign the NDA! You should be thanking us for telling you how to save money but you just want to argue 5 billion instructions in one batch job are insignificant. So what's the point? Believe what you want. Better yet, try it yourself and learn. If you got the stuff, that is! So, I took your challenge and coded it up. Here's my code: MOVE 520 TO MAX. * 5 billion Can you show the PICTURE for MAX? CALL 'TIMEIT-BEGIN'. Don't have this routine obviously. I'll see what else I can use. Probably safest to write two separate programs but with this tiny example it's not going to be very useful. For best results take a big program and straight line it as the other poster suggested. We have seen the difference. Anybody who tries it will also. PERFORM MAX TIMES MOVE MAX TO DUMMY END-PERFORM. This is an inline PERFORM. It should compile like two GO TOs. We have been talking about old-style (non-inline) PERFORMs. If you have optimization on the compiler should move the MOVE outside the PERFORM and eliminate the loop entirely resulting in a nice piece of code one instruction long that doesn't loop. Of course this doesn't represent what we have been discussing which is hundreds of PERFORMS performing large blocks of code. The test case you wrote probably isn't worth anything. You have to test it with a real production program and you will find the same results me and the other poster reported. To change your inline PERFORM to the ones we have been fixing use the format PERFORM TIME-LOOP THRU TIME-LOOP-EXIT MAX TIMES. PERFORM TIME-LOOP THRU TIME-LOOP-EXIT may not optimize because of ambiguity of path to reach TIME-LOOP-EXIT. If Tom Ross reads this on IBM-MAIN he can clarify. If you code PERFORM TIME-LOOP and TIME-LOOP can NOT be reached by GO TO or fall through, The IBM z series compiler will either move the code in line or general fewer instructions for the PERFORM because it doesn't have to handle the fall through condition. This is based on coding programs for VS COBOL II V1R4 and COBOL for MVS and VM in the late 1990s and reading the generated code. If all the programs you deal with have PERFORM ... THRU or GO TO statements you may never see the new PERFORM optimizations. The COBOL VS PERFORM ... VARYING ... UNTIL was a pig. The VS COBOL II V1R4 and later compilers could generate some slick code. Techniques I used to take an hour off a compute bound program compiled with the COBOL VS compiler and which were detailed in an article by me in a 1991 or 1992 issue of Technical Support published by NaSPA would have to be revisited when moving to VS COBOL II V1R4 and later to reduce the CPU time further. Clark Morris .. TIME-LOOP. MOVE MAX TO DUMMY. TIME-LOOP-EXIT. EXIT. CALL 'TIMEIT-DURATION' USING DURATION. DISPLAY DURATION. MOVE 0 TO WSCOUNT. CALL 'TIMEIT-BEGIN'. LOOP. ADD 1 TO WSCOUNT MOVE MAX TO DUMMY IF WSCOUNT MAX GO TO LOOP-EXIT ELSE GO TO LOOP. LOOP-EXIT. This is pretty poor looping code. Unoptimized it probably generates twice as many tests as even an inline PERFORM. The first test is going to execute 5 billion times for nothing since it will never be true until the end. A simple way to do this would be MOVE ZERO TO WSCOUNT. LOOP. ADD 1 TO WSCOUNT. MOVE MAX TO DUMMY IF WSCOUNT MAX GO TO LOOP. I'll check if Enterprise COBOL is smart enough to unroll this loop with optimization. CALL 'TIMEIT-DURATION' USING DURATION. DISPLAY DURATION. The results were: PERFORM = 2.36seconds GO TO LOOP = 37.78 seconds Not sure why there should be so much difference. Your compiler may have (should have) optimized your inline PERFORM out of existence. Inline PERFORM is fine, it's the out of line PERFORMs we have been discussing (see previous posts). If you have optimization turned on also make sure it hasn't reordered the calls to TIMEIT-BEGIN or done anything else that could affect the timing between the two sections. As stated above this example isn't useful because it just shows the difference without paging effects. Actually it doesn't even show that at this point until we correct the things I mentioned. These trivial examples don't give an accurate performance measurement since you're running on a PC with nothing else going on and we have been talking about a busy mainframe shop with batch work. In a small example everything is on one page. Out of line PERFORM can affect the paging rate when spread out over a big program. The results are significant on busy systems. Another poster's confusion about nested PERFORMs also shows possible problems with PERFORM. For all their
Re: GO TO cobol
snip http://proceedings.share.org/client_files/SHARE_in_San_Jose/S8133EJ131525.pdf That's a very interesting presentation. If I were coding in assembler I would follow! If IBM had made PL/X generally available would you have used that, or still used assembler? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
In 4f931b2a.9020...@phoenixsoftware.com, on 04/21/2012 at 01:40 PM, Edward Jaffe edja...@phoenixsoftware.com said: This is good general programming advice -- not just for COBOL programmers, but for for anyone writing in any modern compiled language. As defined in Alan Sherman's song Good Advice. The behavior of well-defined coding structures like IF/THEN/ELSE, DO, SELECT, CASE, etc. are extremely well understood--both by programmers and by code optimizers no matter which language is being employed. This is one of the chief reasons why structured programs are so much more maintainable than unstructured ones. Use of those constructs does not make a program well structured, and use of goto does not make a program ill structured. You have to carve the bird at the joints. Every programmer understands a-priori how the control structures work Which is quite different from understanding how a particular program using the control structure works. without tedious inspection of the logic to understand the possible paths taken. Understanding how the *program* works can involve tedious inspection of the logic to understand the possible paths taken even if there is not a single goto. Good compiler optimization depends on the compiler understanding what your code is attempting to do and structured, GOTO-less, code is FAR easier to optimize than its GOTO-laden counterparts. That's an issue for ALTER and its equivalents in other languages, not for the GOTO itself. Most modern languages disallow GOTO. FSVO modern. IMHO it's usually better, even when programming in older languages, to avoid their use unless the language's control structures are truly insufficient to handle a specific, necessary case. In most endeavors it's best to not use a hammer as a screwdriver. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
In 4f9574f3.1080...@actionsoftware.com, on 04/23/2012 at 11:27 AM, Gord Tomlin gt.ibm.li...@actionsoftware.com said: Some languages allow the provision of a label for a block, and a LEAVE statement that takes a label as an argument. In such languages this construct performs the same function as your GOTO, but in a way that can be better understood by the optimizer. I'm not sure that there is a difference in code optimization, but the code will be more maintamable if you use leave and next in those languages that support them, rather than equivalent goto statements. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 4/23/2012 2:13 PM, Shmuel Metz (Seymour J.) wrote: In4f931b2a.9020...@phoenixsoftware.com, on 04/21/2012 at 01:40 PM, Edward Jaffeedja...@phoenixsoftware.com said: Good compiler optimization depends on the compiler understanding what your code is attempting to do and structured, GOTO-less, code is FAR easier to optimize than its GOTO-laden counterparts. That's an issue for ALTER and its equivalents in other languages, not for the GOTO itself. You might find the following of interest: Wolfgang Gellerich, Markus Kosiol and Erhard Plödereder, Where does GOTO Go to?, Reliable Software Technologies — Ada-Europe '96, Montreux, Switzerland, June 10–14, 1996 Proceedings, Lecture Notes in Computer Science, Volume 1088/1996, pp. 385-395 This paper documents the disastrous effects GOTO can have on compiler optimization for RISC, superscalar, out-of-order execution and other non-obvious, but important execution efficiencies of which optimizers are increasingly aware. It finds that GOTO is most often used when the programmer is attempting to write more efficient code yet tends to have exactly the opposite effect. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
The equivalent Marine rank (E-3) is Lance Corporal. The Marines do use the rank of Private First Class, but it is one grade lower, the equivalent of an Army Private (E-2). And, with a nod to Shmuel (Give me back my Air Force) , the Air Force equivalent is A1C (Airman First Class), which may be confusing to people diagnosed with diabetes. :-) Bob -- On Tuesday, April 17, 2012 05:10:36 AM you wrote: PFC = Private First Class. An Army rank. The Marines may also use it. Lloyd - Original Message From: Paul Gilmartin paulgboul...@aim.com To: IBM-MAIN@bama.ua.edu Sent: Mon, April 16, 2012 7:27:30 PM Subject: Re: GO TO cobol On Mon, 16 Apr 2012 16:45:21 -0500, Matthew Stitt wrote: You could have the exact same result by placing a period after the 2000-exit. Then the End-if is not needed. gd,r I sure am glad that COBOL attained its design objective of being intelligible (intuitively? unambiguously?) to a PFC-level programmer with only an understanding of vernacular English. (Is PFC a Navy rank?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On Sat, 2012-04-21 at 16:40 -0400, Edward Jaffe wrote: The behavior of well-defined coding structures like IF/THEN/ELSE, DO, SELECT, CASE, etc. are extremely well understood--both by programmers and by code optimizers no matter which language is being employed. Hmm. I wonder if the COBOL compiler generates equivalent code for: GO TO ... DEPENDING ON X (which I've always understood was a simple branch table) and: EVALUATE X WHEN 1 ... WHEN 2 ... Hey John, there's a research topic for you in your copious spare time! -- David Andrews A. Duda Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Edward Jaffe's already cited point, that begin extract The behavior of well-defined coding structures like IF/THEN/ELSE, DO, SELECT, CASE, etc. are extremely well understood--both by programmers and by code optimizers no matter which language is being employed. /end extract is fundamentally important. Optimizers distinguish many special cases of each of these figures, generating slightly but significantly different code for each of them. A routine that is comprised chiefly of instances of these figures is thus easy to optimize, and this is often the case even when these figures are used less felicitously than than they should be. An optimizer can mitigate the bad-performance effects of ugly code. It must, however, be remembered that the code generated for, say, a DO WHILE or a DO UNTIL contains and makes critical use of unconditional branches. They are indeed implicit in these two figures and, of course, in IF-THEN-ELSE too. The question when GOTOs, i.e., unconditional branches, should be used explicitly is thus the interesting one. I myself use them where 1) I judge that they confer a significant performance benefit and 2) they can be used in a regular/orderly way. IN looking through code that I have written recently for instances of them I discovered something that I had not really been aware of. I use them most often to unwind recursions and for catastrophic error-handling. If, say, in traversing a binary-search tree recursively in some key sequence I find what I want, I use a 'stack-cleaning long branch' to return to the point at which I began the traversal. This 'out-of-block GOTO' is not strictly necessary; but the alternative, a sequence of several stack-unwinding returns, is ugly and slow. To summarize now, there are, I think, situations in which explicit GOTOs are appropriate, in which their use can confer significant, readily measurable performance benefits. Unfortunately, these situations are also highly problematic. To use GOTOs effectively in them one needs to know more about run-time dynamics than most programmers now know or are, I fear, ever again likely to be taught. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Some languages allow the provision of a label for a block, and a LEAVE statement that takes a label as an argument. In such languages this construct performs the same function as your GOTO, but in a way that can be better understood by the optimizer. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2012-04-23 10:44, John Gilmore wrote: Edward Jaffe's already cited point, that begin extract The behavior of well-defined coding structures like IF/THEN/ELSE, DO, SELECT, CASE, etc. are extremely well understood--both by programmers and by code optimizers no matter which language is being employed. /end extract is fundamentally important. Optimizers distinguish many special cases of each of these figures, generating slightly but significantly different code for each of them. A routine that is comprised chiefly of instances of these figures is thus easy to optimize, and this is often the case even when these figures are used less felicitously than than they should be. An optimizer can mitigate the bad-performance effects of ugly code. It must, however, be remembered that the code generated for, say, a DO WHILE or a DO UNTIL contains and makes critical use of unconditional branches. They are indeed implicit in these two figures and, of course, in IF-THEN-ELSE too. The question when GOTOs, i.e., unconditional branches, should be used explicitly is thus the interesting one. I myself use them where 1) I judge that they confer a significant performance benefit and 2) they can be used in a regular/orderly way. IN looking through code that I have written recently for instances of them I discovered something that I had not really been aware of. I use them most often to unwind recursions and for catastrophic error-handling. If, say, in traversing a binary-search tree recursively in some key sequence I find what I want, I use a 'stack-cleaning long branch' to return to the point at which I began the traversal. This 'out-of-block GOTO' is not strictly necessary; but the alternative, a sequence of several stack-unwinding returns, is ugly and slow. To summarize now, there are, I think, situations in which explicit GOTOs are appropriate, in which their use can confer significant, readily measurable performance benefits. Unfortunately, these situations are also highly problematic. To use GOTOs effectively in them one needs to know more about run-time dynamics than most programmers now know or are, I fear, ever again likely to be taught. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Gord, Not quite. PL/I is the archetypical; language that makes these facilities available, and in it the label associated with a leave statement can only be that of a containing group, as in outer: do ; inner: do ; . . . leave outer : . . . end inner : end outer ; in which execution of the leave statement transfers control to the statement following the end outer ; statement. The GOTO I described transfers control to the statement following the instance of a label associated with the first invocation of a procedure from the invocation of that procedure in which it is executed. Note that PL/I can do this. If you supply a label constant, call it gubbins, to a procedure as an argument and then, within that invocation or a subsequent, recursive invocation of this procedure execute the statement goto gubbins ; control will be returned to the instance of the label gubbins active at the time of the first call,he DSA stack weill be purged appropriately, etc., etc.. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Nice trick. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2012-04-23 13:18, John Gilmore wrote: Gord, Not quite. PL/I is the archetypical; language that makes these facilities available, and in it the label associated with a leave statement can only be that of a containing group, as in outer: do ; inner: do ; . . . leave outer : . . . end inner : end outer ; in which execution of the leave statement transfers control to the statement following the end outer ; statement. The GOTO I described transfers control to the statement following the instance of a label associated with the first invocation of a procedure from the invocation of that procedure in which it is executed. Note that PL/I can do this. If you supply a label constant, call it gubbins, to a procedure as an argument and then, within that invocation or a subsequent, recursive invocation of this procedure execute the statement goto gubbins ; control will be returned to the instance of the label gubbins active at the time of the first call,he DSA stack weill be purged appropriately, etc., etc.. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 23 Apr 2012 10:21:03 -0700, in bit.listserv.ibm-main you wrote: Gord, Not quite. If IBM had implemented the EXIT enhancements in the 2002 standard we would have available EXIT PERFORM (for inline PERFORMs which are like DO loops) EXIT PERFORM CYCLE which allows iteration without having to do unnatural things in the code EXIT PARAGRAPH EXIT SECTION. I know I could have used them. Unfortunately many companies seem stuck on coding standards last updated for COBOL VS. Clark Morris PL/I is the archetypical; language that makes these facilities available, and in it the label associated with a leave statement can only be that of a containing group, as in outer: do ; inner: do ; . . . leave outer : . . . end inner : end outer ; in which execution of the leave statement transfers control to the statement following the end outer ; statement. The GOTO I described transfers control to the statement following the instance of a label associated with the first invocation of a procedure from the invocation of that procedure in which it is executed. Note that PL/I can do this. If you supply a label constant, call it gubbins, to a procedure as an argument and then, within that invocation or a subsequent, recursive invocation of this procedure execute the statement goto gubbins ; control will be returned to the instance of the label gubbins active at the time of the first call,he DSA stack weill be purged appropriately, etc., etc.. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 4/23/2012 10:48 AM, Clark Morris wrote: If IBM had implemented the EXIT enhancements in the 2002 standard we would have available EXIT PERFORM (for inline PERFORMs which are like DO loops) EXIT PERFORM CYCLE which allows iteration without having to do unnatural things in the code EXIT PARAGRAPH EXIT SECTION. I know I could have used them. Unfortunately many companies seem stuck on coding standards last updated for COBOL VS. Though not specific to COBOL, there are two excellent studies/papers worth reading on this subject: Wolfgang Gellerich, Markus Kosiol and Erhard Plödereder, Where does GOTO Go to?, Reliable Software Technologies — Ada-Europe '96, Montreux, Switzerland, June 10–14, 1996 Proceedings, Lecture Notes in Computer Science, Volume 1088/1996, pp. 385-395 This paper documents the disastrous effects GOTO can have on compiler optimization for RISC, superscalar, out-of-order execution and other non-obvious, but important execution efficiencies of which optimizers are increasingly aware. It finds that GOTO is most often used when the programmer is attempting to write more efficient code yet tends to have exactly the opposite effect. W.Gellerich and E.Plödereder, The Evolution of GOTO Usage and Its Effects on Software Quality, Informatik'99, K.Beiersdörfer, G.Engels, and W.Schäfer, Eds., Springer-Verlag, Berlin, 1999 This paper presents the results of a study in which the frequency and typical applications of GOTO in over 400 MB of C and Ada source code were analyzed. The analysis demonstrated that the availability of sufficiently powerful control structures in a language significantly reduces the frequency of GOTO. Relating these results to error rates reported for large software projects indicates that programs written with lower GOTO density are more reliable. Though tangential to the core discussion, the following article references the above studies and might be of interest to those involved with this platform: W.Gellerich, T.Hendel, R. Land, H.Lehmann, M. Mueller, P. H.Oden, H.Penner, The GNU 64-bit PL8 compiler: Toward an open standard environment for firmware development, IBM Journal of Research Development, 48, No. 3/4, May/July 2004, pp. 3-4. This paper compares GOTO density metrics for Fortran, C, Ada, and PL8 (the language in which System z firmware is written). I added HLASM to the chart for a SHARE presentation I gave back in 2008 in San Jose (link below). ___ | | Fortran | C | Ada | PL8 | HLASM | |Files without GOTO | none | 81.5% | 99.4% | 98.5% | none | |Lines/GOTO | ~10 | 386 |13614 | 1310 | 8 | '-' http://proceedings.share.org/client_files/SHARE_in_San_Jose/S8133EJ131525.pdf -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 4/23/2012 11:03 AM, Edward Jaffe wrote: ___ | | Fortran | C | Ada | PL8 | HLASM | |Files without GOTO | none | 81.5% | 99.4% | 98.5% | none | |Lines/GOTO | ~10 | 386 |13614 | 1310 | 8 | '-' Ugh. Hopefully this formats better: ___ | | Fortran | C| Ada | PL8 | HLASM | |Files without GOTO | none| 81.5% | 99.4% | 98.5% | none | |Lines/GOTO | ~10 | 386 | 13614 | 1310 | 8| '-' http://proceedings.share.org/client_files/SHARE_in_San_Jose/S8133EJ131525.pdf -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
___ | | Fortran | C| Ada | PL8 | HLASM | |Files without GOTO | none| 81.5% | 99.4% | 98.5% | none | |Lines/GOTO | ~10 | 386 | 13614 | 1310 | 8 | '-' Courier New(Fixed font)? In a message dated 4/23/2012 1:10:13 P.M. Central Daylight Time, edja...@phoenixsoftware.com writes: ___ | | Fortran | C| Ada | PL8 | HLASM | |Files without GOTO | none| 81.5% | 99.4% | 98.5% | none | |Lines/GOTO | ~10 | 386 | 13614 | 1310 | 8 | '-' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Oh well, looked great when I sent it. Guessed it got Mime munged In a message dated 4/23/2012 1:34:27 P.M. Central Daylight Time, efinnel...@aol.com writes: Courier New(Fixed font)? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On Sun, 22 Apr 2012 08:14:11 -0500, HeyBub hey...@nospamgmail.com wrote: Nomen Nescio wrote: These aren't microscopic optimizations but something easy to do that every programmer should be aware of. It doesn't take longer to do things right the first time. If you worked for me, I'd fire you for wasting my money. Don't flatter yourself. You couldn't find your ass with both hands much less fire anybody. Show me. Supply some sample code comparing a PERFORM to a GO TO. It will be easy enough to stick timers in the code for a million (or a billion) iterations. So, I say again, show me that the difference is significant, or even measurable. In a program with heavy use of PERFORM where the compiler has to assume that execution can fall through to the next instruction at the exit point rather than always return to the instruction following the PERFORM, it could make a modest difference. Nomen and Fritz both seem to be coding based on how the IBM 370 COBOL VS compiler worked. In most cases even with the 1974 compiler the difference was trivial because the CPU time was a small part of the overall run time. Also the instruction path length was and is far longer for I-O requests and implied or explicitly coded CALL statements, especially if the DYNAM (load the CALLED module at execution time or delayed binding) was chosen. Having said the above, I am confident that I can take any program optimized for the COBOL VS environment and restructure it eliminating GO TO statements and have the resulting program execute with the same or less CPU time. I am assuming that both the before and after versions are compiled with OPTIMIZE. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On Thu, 19 Apr 2012 04:42:55 +0200, Fritz Wuehler fr...@spamexpire-201204.rodent.frell.theremailer.net wrote: 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). and 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 so loops processing millions of records get very expensive fast and avoiding GO TO and being forced to use PERFORM causes you to create more loops than you would need with GO TO. Last time I looked, COBOL doesn't inline PERFORM so you pay the penalty hundreds or thousands of millions of times in a big program processing a big file. And paging is usually worse because of the unnatural long branches caused byPERFORM, when straight line coding with careful use of GO TOs would have reduced paging. 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. 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. I am writing this as some one who used ALTER ... GO TO to replace PERFORM statements in DOS 360 COBOL. I had an article published in an issue of Technical Support, the magazine of the National Systems Programmer Association (now Network and Systems Professionals Association) telling how I cut the execution time of a compute bound run by over an hour (it was running on a 3081). The program was COBOL VS and the 1974 standard COBOL running on MVS. This included replacing PERFORM ... VARYING with simple PERFORMs and looping within the PERFORMed paragraph by using IF statements within the paragraph that would GO TO the paragraph being performed. I am grateful that I had the caveat in the article that the new VS COBOL II might change some of the optimizations. As someone who has looked carefully at the code generated by PERFORM on IBM 360/370/390/z series systems, starting with VS COBOL II 1.4, the first Ansi 85 IBM compiler the ball game changed. On COBOL VS (74 standard) and prior there were statements like MVC save_exit_address,exit_address MVC exit_address,return_address L R15,perform_paragraph_start BR R15 return_point DS 0H MVC exit_address,save_exit_address. There would be a L R15,exit_address BR R15 at the end of the perform range. With COBOL 85, if the paragraph being performed is entered by a PERFORM statement, and there is never a fall through to the next paragraph and there are no GO TO statements in the paragraph, depending on various algorithms the performed paragraph may be moved inline with all perform code eliminated. PERFORM ... VARYING went from being a pig to having very efficient code. PERFORM x THRU x-exit in most if not all cases will still require the same 3 moves with even the latest COBOL because of the semantics of COBOL. Based on presentations by Tom Ross at SHARE (IBM COBOL representative) and my reading of the generated assembler code, I changed my coding practices to make sure all GO TO statements were eliminated because they mess up PERFORM optimization. Code optimization I did that saved substantial time on that compute bound run for COBOL VS would have to have be redone to take advantage of the PERFORM optimization in VS COBOL II release 1.4 and newer. There were other things done that were valuable when using the COBOL VS compiler that became counter-productive with the VS COBOL compiler. With any major compiler upgrade, you should review the language reference manual and the programmers guide to see if changes should be made in coding style to take advantage of different ways of optimization or newer constructs. The IBM COBOL compiler optimizations (when OPTIMIZE is chosen) are designed to support good coding
Re: GO TO cobol
On 4/21/2012 12:52 PM, Clark Morris wrote: On Thu, 19 Apr 2012 04:42:55 +0200, Fritz Wuehler | ... 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. Based on presentations by Tom Ross at SHARE (IBM COBOL representative) and my reading of the generated assembler code, I changed my coding practices to make sure all GO TO statements were eliminated because they mess up PERFORM optimization. This is good general programming advice -- not just for COBOL programmers, but for for anyone writing in any modern compiled language. The behavior of well-defined coding structures like IF/THEN/ELSE, DO, SELECT, CASE, etc. are extremely well understood--both by programmers and by code optimizers no matter which language is being employed. This is one of the chief reasons why structured programs are so much more maintainable than unstructured ones. Every programmer understands a-priori how the control structures work without tedious inspection of the logic to understand the possible paths taken. Good compiler optimization depends on the compiler understanding what your code is attempting to do and structured, GOTO-less, code is FAR easier to optimize than its GOTO-laden counterparts. A GOTO will often serve as a monkey wrench thrown into the works of the compiler optimization algorithms. GOTOs are unpredictable; compilers don't know in advance where they will appear in the code; they don't know in advance what the target of the GOTO will be. The optimization algorithms must adapt to a surprise situation they best they can. In some cases the GOTO will be highly disruptive; in other cases less so. Most modern languages disallow GOTO. IMHO it's usually better, even when programming in older languages, to avoid their use unless the language's control structures are truly insufficient to handle a specific, necessary case. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
My use was in 1969 and only at Fort Ben. From school, I went to Fort Monroe, VA and worked on a 360/40 running PCP version of OS/360. I remembered that the 1004 had a plugboard, but I thought that you could also run programs on it. We may have had to assembler the programs on the 1005. The 1005 that we were taught on was the single address machine version. I do not remember being told about a two-address version. Lloyd - Original Message From: Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net To: IBM-MAIN@bama.ua.edu Sent: Thu, April 19, 2012 5:23:52 PM Subject: Re: GO TO cobol In 1334839226.16701.yahoomai...@web180901.mail.ne1.yahoo.com, on 04/19/2012 at 05:40 AM, Lloyd Fuller leful...@sbcglobal.net said: Actually, the 1004 and the 1005 versions. The 1004 was programmed with a plugboard. The 1005 started life as a special plugboard for the 1004. There were two versions of the 1005; a single address machine and a two-address machine. SAAL was Single Address Assembly Language for the single address 1005. The only thing that I really remember about them is that you had to know which panel(s) to kick to get the machine to boot. I guess that I was lucky. The only one that I saw was at Ft. MacArthur, and it loaded without any issues. Of course, with my last use in 1968 it might not have worked so well by the time you came around. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 4/18/2012 11:06 PM, Dale Miller wrote: Years ago, I learned my first programming language (FORTRAN) from an excellent book by Daniel McCracken who was justly famous for his excellent programming books. He was also known, (but not quite as well) for a mid-life crisis which involved completing a degree from a seminary, but never getting ordained, if my memory serves me. His popularity peaked around the time of the big push for structured programming, and I attended a discussion by him of structured programming. He was positive about it, but with a few caveats. I do remember his saying (approximately):Pity the poor COBOL programmer working on the error recovery routines for Indexed-Sequential file handling, who finds himself 5 levels deep in nested PERFORMS, and is heard to shout as he sinks beneath the waves: 'Just one GO TO!'.. Looking at the situation where there are multiple conditions under which a procedure/block should terminate, if one is forced to follow the stricture of a single exit from a procedure, one is forced to choose between a convoluted set of nested if's or using goto's to the single exit point. The use of goto's could be considerably easier to follow, especially in the case of the original non-structured COBOL where PERFORM's would be necessary. Dale Miller Well that brings back memories! I worked with Dan, back in the late 70's I think it was. I wrote the script and accompanying handouts for is ASI video tape series on structured COBOL. Many of you probably remember ASI and Deltak (and a few others, but these were the big two) when large chunks of training were built around video libraries. When I left IBM to work for myself, I thought IBM would be my biggest competitor. In those days, however, it was ASI and Deltak. Over the years I ended up doing some work for both of them and speaking at their conferences. Even did some work in London for ASI. Good days. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Actually, the 1004 and the 1005 versions. I could not remember the names. The only place that I ever saw them was at the school. The only thing that I really remember about them is that you had to know which panel(s) to kick to get the machine to boot. The interlocks were very worn and did not seat properly. We were told that some of the ones in the field were even worse. Lloyd - Original Message From: Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net To: IBM-MAIN@bama.ua.edu Sent: Wed, April 18, 2012 7:32:08 PM Subject: Re: GO TO cobol In 1334691539.94814.yahoomai...@web180906.mail.ne1.yahoo.com, on 04/17/2012 at 12:38 PM, Lloyd Fuller leful...@sbcglobal.net said: Univac SAAL computers ITYM UNIVAC 1005[1]. I had successfully ripped the memory out by the roots; thank you for reminding me :-( [1] SAAL was the assembler. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
In 1334839226.16701.yahoomai...@web180901.mail.ne1.yahoo.com, on 04/19/2012 at 05:40 AM, Lloyd Fuller leful...@sbcglobal.net said: Actually, the 1004 and the 1005 versions. The 1004 was programmed with a plugboard. The 1005 started life as a special plugboard for the 1004. There were two versions of the 1005; a single address machine and a two-address machine. SAAL was Single Address Assembly Language for the single address 1005. The only thing that I really remember about them is that you had to know which panel(s) to kick to get the machine to boot. I guess that I was lucky. The only one that I saw was at Ft. MacArthur, and it loaded without any issues. Of course, with my last use in 1968 it might not have worked so well by the time you came around. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: SV: GO TO cobol
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Shmuel Metz (Seymour J.) Skickat: den 18 april 2012 01:26 Till: IBM-MAIN@bama.ua.edu Ämne: Re: SV: GO TO cobol In a90e503c23f97441b05ee302853b0e626402a60...@fspas01ev010.fspa.myntet.se , on 04/16/2012 at 03:42 PM, Thomas Berg thomas.b...@swedbank.se said: (BTW, How do You imagine the behavior if the Signal DID NOT trash the DO nesting? The Devil is in the details. Contrast Rexx with PL/I. In PL/I a SIGNAL invokes an ON-unit as a subroutine. The On=unit can return to the code following the SIGNAL, can SIGNAL another condition, or can include a GOTO, which will pop the stack as appropriate. Note that in PL/I you cannot do a GOTO into a DO loop from outside. This somewhat reminds me of how I use Signal in error situations. I do a CALL ERROR_AND_EXIT with propriate msg etc. and in that procedure, after some tidying and logging, do a Signal to the exit routine. But the idea with the interprocedure enhanced Leave is interesting. Regards, Thomas Berg __ Thomas Berg Specialist AM/DQS SWEDBANK AB (publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Fort Huachuca is in Arizona, and when I was in the Army was the training base for some of the communications stuff. The other communications training was Fort Monmouth, New Jersey. I believe that Fort Huachuca also had some intelligence schools there. That could have been programming classes taught there. Fort Ben was the administrative and financial training base. Lloyd - Original Message From: Ed Gould edgould1...@comcast.net To: IBM-MAIN@bama.ua.edu Sent: Wed, April 18, 2012 1:03:56 AM Subject: Re: GO TO cobol Loyd: Fort Wauchooka (sp??) rings a bell somewhere in my cob ridden memory. But I also now remember Ft Ben Harrison (now). I remember the guys talking about the desert and thats about all. Ed On Apr 17, 2012, at 7:17 AM, Lloyd Fuller wrote: In 1969, and until sometime in the 1970s or later, the Army programming school was at Fort Benjamin Harrison in Indiana. Graduated in March 1969 as a Staff Sergeant converted to a SP6. Programming since then. lLOYD - Original Message From: Ed Gould edgould1...@comcast.net To: IBM-MAIN@bama.ua.edu Sent: Tue, April 17, 2012 12:16:33 AM Subject: Re: GO TO cobol On Apr 16, 2012, at 8:34 AM, McKown, John wrote: SNIP- Also remember that COBOL, at least originally, was supposed to be very English-like and so usable by people at the Army PFC level of training. --John McKown Systems Engineer IV IT Hmmm... I was in the Army and we got PFC's from the programming school (AZ? its been 40 years so forgive me). We had two groups, one COBOL (batch processing) and one ASM group (essentially sysprogs). The ASM group was by far the best IMO. I was on call quite often and had to fix the cobol programs that went boom in the middle of the night. The COBOL people were semi useless in debugging and when I looked at the code they had produced (except for a few people) it was hopeless to understand. I spent more time trying to figure out the logic and compare what I was seeing in the dump. 1/3 the time I helped the programmer figure out where his problem was and supplying answers to his questions on what was in this field or that field. What was interesting was that as the guys (no female programmers so don't call me sexist blame the Army not me) as they became more experienced the code became easier to follow. As they became became better programmers there were less logic problems. Now having said that most of the programs were smallish and only a few were considered large so the smallish programs there was no excuse for logic issues or mangled code. My memory is foggy here as to goto's but I think the rule no standards if memory serves me that goto's were to be minimized as a result flow was easier to follow and frankly debugging was easier. Ed ps: We had one person who at the time he was drafted was working for IBM and he privately told me about some OS enhancements that when I first heard I couldn't wrap my head around as virtual (at least that I had never heard of) was a nightmare that I couldn't wrap my head around. After I got out of the Army (2 years) IBM announced Virtual and I was able to ask some semi intelligent questions as my preview and the questions helped jump start by job. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
And the Computer Systems Command was out of Ft. Belvoir, VA and had administrative offices out at the Melpar bldg. on Route 50 along with a drone development pgm out of DARPA. Classes were offered from DODCI at the Naval Yard for civilians and military. In a message dated 4/18/2012 6:46:58 A.M. Central Daylight Time, leful...@sbcglobal.net writes: could have been programming classes taught there. Fort Ben was the administrative and financial training base. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
In 1334691539.94814.yahoomai...@web180906.mail.ne1.yahoo.com, on 04/17/2012 at 12:38 PM, Lloyd Fuller leful...@sbcglobal.net said: Univac SAAL computers ITYM UNIVAC 1005[1]. I had successfully ripped the memory out by the roots; thank you for reminding me :-( [1] SAAL was the assembler. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
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
Re: GO TO cobol
On Wed, 18 Apr 2012 21:59:33 -0300, Clark Morris wrote: On Wed, 18 Apr 2012 23:04:51 +0200 (CEST), in bit.listserv.ibm-main Nomen Nescio wrote: Hoo dat!? 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 ... I'm just sitting here trying to imagine what significant fraction of the time required to process [a] record is 5 instructions. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Years ago, I learned my first programming language (FORTRAN) from an excellent book by Daniel McCracken who was justly famous for his excellent programming books. He was also known, (but not quite as well) for a mid-life crisis which involved completing a degree from a seminary, but never getting ordained, if my memory serves me. His popularity peaked around the time of the big push for structured programming, and I attended a discussion by him of structured programming. He was positive about it, but with a few caveats. I do remember his saying (approximately):Pity the poor COBOL programmer working on the error recovery routines for Indexed-Sequential file handling, who finds himself 5 levels deep in nested PERFORMS, and is heard to shout as he sinks beneath the waves: 'Just one GO TO!'.. Looking at the situation where there are multiple conditions under which a procedure/block should terminate, if one is forced to follow the stricture of a single exit from a procedure, one is forced to choose between a convoluted set of nested if's or using goto's to the single exit point. The use of goto's could be considerably easier to follow, especially in the case of the original non-structured COBOL where PERFORM's would be necessary. Dale Miller -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Only if you consider a Marine to be in the Navy (Technically, they are under the department of the Navy). But you'll do that only if you don't mind losing some teeth. grin -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, April 16, 2012 6:27 PM To: IBM-MAIN@bama.ua.edu Subject: Re: GO TO cobol On Mon, 16 Apr 2012 16:45:21 -0500, Matthew Stitt wrote: You could have the exact same result by placing a period after the 2000-exit. Then the End-if is not needed. gd,r I sure am glad that COBOL attained its design objective of being intelligible (intuitively? unambiguously?) to a PFC-level programmer with only an understanding of vernacular English. (Is PFC a Navy rank?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
PFC = Private First Class. An Army rank. The Marines may also use it. Lloyd - Original Message From: Paul Gilmartin paulgboul...@aim.com To: IBM-MAIN@bama.ua.edu Sent: Mon, April 16, 2012 7:27:30 PM Subject: Re: GO TO cobol On Mon, 16 Apr 2012 16:45:21 -0500, Matthew Stitt wrote: You could have the exact same result by placing a period after the 2000-exit. Then the End-if is not needed. gd,r I sure am glad that COBOL attained its design objective of being intelligible (intuitively? unambiguously?) to a PFC-level programmer with only an understanding of vernacular English. (Is PFC a Navy rank?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
In 1969, and until sometime in the 1970s or later, the Army programming school was at Fort Benjamin Harrison in Indiana. Graduated in March 1969 as a Staff Sergeant converted to a SP6. Programming since then. lLOYD - Original Message From: Ed Gould edgould1...@comcast.net To: IBM-MAIN@bama.ua.edu Sent: Tue, April 17, 2012 12:16:33 AM Subject: Re: GO TO cobol On Apr 16, 2012, at 8:34 AM, McKown, John wrote: SNIP- Also remember that COBOL, at least originally, was supposed to be very English-like and so usable by people at the Army PFC level of training. --John McKown Systems Engineer IV IT Hmmm... I was in the Army and we got PFC's from the programming school (AZ? its been 40 years so forgive me). We had two groups, one COBOL (batch processing) and one ASM group (essentially sysprogs). The ASM group was by far the best IMO. I was on call quite often and had to fix the cobol programs that went boom in the middle of the night. The COBOL people were semi useless in debugging and when I looked at the code they had produced (except for a few people) it was hopeless to understand. I spent more time trying to figure out the logic and compare what I was seeing in the dump. 1/3 the time I helped the programmer figure out where his problem was and supplying answers to his questions on what was in this field or that field. What was interesting was that as the guys (no female programmers so don't call me sexist blame the Army not me) as they became more experienced the code became easier to follow. As they became became better programmers there were less logic problems. Now having said that most of the programs were smallish and only a few were considered large so the smallish programs there was no excuse for logic issues or mangled code. My memory is foggy here as to goto's but I think the rule no standards if memory serves me that goto's were to be minimized as a result flow was easier to follow and frankly debugging was easier. Ed ps: We had one person who at the time he was drafted was working for IBM and he privately told me about some OS enhancements that when I first heard I couldn't wrap my head around as virtual (at least that I had never heard of) was a nightmare that I couldn't wrap my head around. After I got out of the Army (2 years) IBM announced Virtual and I was able to ask some semi intelligent questions as my preview and the questions helped jump start by job. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
This is true, but I prefer to use the end constructs because they are safer. The safety comes from the compiler complaining about IF and END-Ifs not matching. An errant period generates no such indicator and causes a bug. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Matthew Stitt Sent: Monday, April 16, 2012 5:45 PM To: IBM-MAIN@bama.ua.edu Subject: Re: GO TO cobol If some-test-here-failed Set indicator-switch to true Go to 2000-exit End-if. If some-other-test-fails Set indicator-different-switch to true Go to 2000-exit End-if. --- You could have the exact same result by placing a period after the 2000-exit. Then the End-if is not needed. gd,r -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Without the GO TO, Grace Hopper might have been forever stuck in Japan. Many years ago, I was at an ACM meeting where Grace Hopper was a speaker. One of the stories she told was of a visit to a data center in Japan. Somehow, she was left there without an interpretter. The folks at the data center spoke no English and she spoke no Japanese. Fortunately, the programmers knew COBOL. And while COBOL was designed so that the english commands could be easily translated into other languages (in most languages, the verb in a command is the first thing in the sentence), this is almost never done. Her solution was simple. She poiinted at herself, then said GO TO and the name of the hotel. This was enoungh so that the programmers were able to get her to the hotel. Jeff Holst -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Whatever happened to everyone talking about structured COBOL code. I usually perform paragraph- name thru paragraph- name exit. I but agree flow logic in COBOL need revision. Especially, when you in the middle of the perform. Using 'continue' to good, but sometimes deadlines force you to write not the way you want too Scott Ford Senior Systems Engineer www.identityforge.com On Apr 17, 2012, at 9:12 AM, Jeff Holst jeff.ho...@fiserv.com wrote: Without the GO TO, Grace Hopper might have been forever stuck in Japan. Many years ago, I was at an ACM meeting where Grace Hopper was a speaker. One of the stories she told was of a visit to a data center in Japan. Somehow, she was left there without an interpretter. The folks at the data center spoke no English and she spoke no Japanese. Fortunately, the programmers knew COBOL. And while COBOL was designed so that the english commands could be easily translated into other languages (in most languages, the verb in a command is the first thing in the sentence), this is almost never done. Her solution was simple. She poiinted at herself, then said GO TO and the name of the hotel. This was enoungh so that the programmers were able to get her to the hotel. Jeff Holst -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Lloyd, My father was a Unisys CE at the Fort for many years... Scott Ford Senior Systems Engineer www.identityforge.com On Apr 17, 2012, at 8:17 AM, Lloyd Fuller leful...@sbcglobal.net wrote: In 1969, and until sometime in the 1970s or later, the Army programming school was at Fort Benjamin Harrison in Indiana. Graduated in March 1969 as a Staff Sergeant converted to a SP6. Programming since then. lLOYD - Original Message From: Ed Gould edgould1...@comcast.net To: IBM-MAIN@bama.ua.edu Sent: Tue, April 17, 2012 12:16:33 AM Subject: Re: GO TO cobol On Apr 16, 2012, at 8:34 AM, McKown, John wrote: SNIP- Also remember that COBOL, at least originally, was supposed to be very English-like and so usable by people at the Army PFC level of training. --John McKown Systems Engineer IV IT Hmmm... I was in the Army and we got PFC's from the programming school (AZ? its been 40 years so forgive me). We had two groups, one COBOL (batch processing) and one ASM group (essentially sysprogs). The ASM group was by far the best IMO. I was on call quite often and had to fix the cobol programs that went boom in the middle of the night. The COBOL people were semi useless in debugging and when I looked at the code they had produced (except for a few people) it was hopeless to understand. I spent more time trying to figure out the logic and compare what I was seeing in the dump. 1/3 the time I helped the programmer figure out where his problem was and supplying answers to his questions on what was in this field or that field. What was interesting was that as the guys (no female programmers so don't call me sexist blame the Army not me) as they became more experienced the code became easier to follow. As they became became better programmers there were less logic problems. Now having said that most of the programs were smallish and only a few were considered large so the smallish programs there was no excuse for logic issues or mangled code. My memory is foggy here as to goto's but I think the rule no standards if memory serves me that goto's were to be minimized as a result flow was easier to follow and frankly debugging was easier. Ed ps: We had one person who at the time he was drafted was working for IBM and he privately told me about some OS enhancements that when I first heard I couldn't wrap my head around as virtual (at least that I had never heard of) was a nightmare that I couldn't wrap my head around. After I got out of the Army (2 years) IBM announced Virtual and I was able to ask some semi intelligent questions as my preview and the questions helped jump start by job. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Probably at the Army Finance Center there. I think that they used Unisys. Lloyd - Original Message From: Scott Ford scott_j_f...@yahoo.com To: IBM-MAIN@bama.ua.edu Sent: Tue, April 17, 2012 9:36:59 AM Subject: Re: GO TO cobol Lloyd, My father was a Unisys CE at the Fort for many years... Scott Ford Senior Systems Engineer www.identityforge.com On Apr 17, 2012, at 8:17 AM, Lloyd Fuller leful...@sbcglobal.net wrote: In 1969, and until sometime in the 1970s or later, the Army programming school was at Fort Benjamin Harrison in Indiana. Graduated in March 1969 as a Staff Sergeant converted to a SP6. Programming since then. lLOYD - Original Message From: Ed Gould edgould1...@comcast.net To: IBM-MAIN@bama.ua.edu Sent: Tue, April 17, 2012 12:16:33 AM Subject: Re: GO TO cobol On Apr 16, 2012, at 8:34 AM, McKown, John wrote: SNIP- Also remember that COBOL, at least originally, was supposed to be very English-like and so usable by people at the Army PFC level of training. --John McKown Systems Engineer IV IT Hmmm... I was in the Army and we got PFC's from the programming school (AZ? its been 40 years so forgive me). We had two groups, one COBOL (batch processing) and one ASM group (essentially sysprogs). The ASM group was by far the best IMO. I was on call quite often and had to fix the cobol programs that went boom in the middle of the night. The COBOL people were semi useless in debugging and when I looked at the code they had produced (except for a few people) it was hopeless to understand. I spent more time trying to figure out the logic and compare what I was seeing in the dump. 1/3 the time I helped the programmer figure out where his problem was and supplying answers to his questions on what was in this field or that field. What was interesting was that as the guys (no female programmers so don't call me sexist blame the Army not me) as they became more experienced the code became easier to follow. As they became became better programmers there were less logic problems. Now having said that most of the programs were smallish and only a few were considered large so the smallish programs there was no excuse for logic issues or mangled code. My memory is foggy here as to goto's but I think the rule no standards if memory serves me that goto's were to be minimized as a result flow was easier to follow and frankly debugging was easier. Ed ps: We had one person who at the time he was drafted was working for IBM and he privately told me about some OS enhancements that when I first heard I couldn't wrap my head around as virtual (at least that I had never heard of) was a nightmare that I couldn't wrap my head around. After I got out of the Army (2 years) IBM announced Virtual and I was able to ask some semi intelligent questions as my preview and the questions helped jump start by job. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Yes sir, for many years, large systems CE ... Scott Ford Senior Systems Engineer www.identityforge.com On Apr 17, 2012, at 10:07 AM, Lloyd Fuller leful...@sbcglobal.net wrote: Probably at the Army Finance Center there. I think that they used Unisys. Lloyd - Original Message From: Scott Ford scott_j_f...@yahoo.com To: IBM-MAIN@bama.ua.edu Sent: Tue, April 17, 2012 9:36:59 AM Subject: Re: GO TO cobol Lloyd, My father was a Unisys CE at the Fort for many years... Scott Ford Senior Systems Engineer www.identityforge.com On Apr 17, 2012, at 8:17 AM, Lloyd Fuller leful...@sbcglobal.net wrote: In 1969, and until sometime in the 1970s or later, the Army programming school was at Fort Benjamin Harrison in Indiana. Graduated in March 1969 as a Staff Sergeant converted to a SP6. Programming since then. lLOYD - Original Message From: Ed Gould edgould1...@comcast.net To: IBM-MAIN@bama.ua.edu Sent: Tue, April 17, 2012 12:16:33 AM Subject: Re: GO TO cobol On Apr 16, 2012, at 8:34 AM, McKown, John wrote: SNIP- Also remember that COBOL, at least originally, was supposed to be very English-like and so usable by people at the Army PFC level of training. --John McKown Systems Engineer IV IT Hmmm... I was in the Army and we got PFC's from the programming school (AZ? its been 40 years so forgive me). We had two groups, one COBOL (batch processing) and one ASM group (essentially sysprogs). The ASM group was by far the best IMO. I was on call quite often and had to fix the cobol programs that went boom in the middle of the night. The COBOL people were semi useless in debugging and when I looked at the code they had produced (except for a few people) it was hopeless to understand. I spent more time trying to figure out the logic and compare what I was seeing in the dump. 1/3 the time I helped the programmer figure out where his problem was and supplying answers to his questions on what was in this field or that field. What was interesting was that as the guys (no female programmers so don't call me sexist blame the Army not me) as they became more experienced the code became easier to follow. As they became became better programmers there were less logic problems. Now having said that most of the programs were smallish and only a few were considered large so the smallish programs there was no excuse for logic issues or mangled code. My memory is foggy here as to goto's but I think the rule no standards if memory serves me that goto's were to be minimized as a result flow was easier to follow and frankly debugging was easier. Ed ps: We had one person who at the time he was drafted was working for IBM and he privately told me about some OS enhancements that when I first heard I couldn't wrap my head around as virtual (at least that I had never heard of) was a nightmare that I couldn't wrap my head around. After I got out of the Army (2 years) IBM announced Virtual and I was able to ask some semi intelligent questions as my preview and the questions helped jump start by job. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
I didn't get there 'til '76. They had a CDC 3300 as the main record keeper with somebody's MassStor and several ancillary processors. I didn't notice the unit record equipment just the sound of a drum bouncing around in the bottom of the cage. The programming course was taught on DOS under VM(Lt. Farmer participated in SHARE). In a message dated 4/17/2012 9:27:22 A.M. Central Daylight Time, leful...@sbcglobal.net writes: Army Finance Center there. I think that they used Unisys. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
When I went in 1969, we used a 1401 with 4 tape drives. We were taught COBOL but could not compile: the COBOL compiler for the 1401 needed either disk or at least 6 tape drives. We also learned to program PCM and two Univac SAAL computers that were in use by the Army at the time. Lloyd - Original Message From: Ed Finnell efinnel...@aol.com To: IBM-MAIN@bama.ua.edu Sent: Tue, April 17, 2012 2:38:44 PM Subject: Re: GO TO cobol I didn't get there 'til '76. They had a CDC 3300 as the main record keeper with somebody's MassStor and several ancillary processors. I didn't notice the unit record equipment just the sound of a drum bouncing around in the bottom of the cage. The programming course was taught on DOS under VM(Lt. Farmer participated in SHARE). In a message dated 4/17/2012 9:27:22 A.M. Central Daylight Time, leful...@sbcglobal.net writes: Army Finance Center there. I think that they used Unisys. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
In a6b9336cdb62bb46b9f8708e686a7ea00e924b3...@nrhmms8p02.uicnrh.dom, on 04/16/2012 at 08:34 AM, McKown, John john.mck...@healthmarkets.com said: Also remember that COBOL, at least originally, was supposed to be very English-like Not to native Anglophones :-( -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: GO TO cobol
In a90e503c23f97441b05ee302853b0e626402a60...@fspas01ev010.fspa.myntet.se, on 04/16/2012 at 03:42 PM, Thomas Berg thomas.b...@swedbank.se said: (BTW, How do You imagine the behavior if the Signal DID NOT trash the DO nesting? The Devil is in the details. Contrast Rexx with PL/I. In PL/I a SIGNAL invokes an ON-unit as a subroutine. The On=unit can return to the code following the SIGNAL, can SIGNAL another condition, or can include a GOTO, which will pop the stack as appropriate. Note that in PL/I you cannot do a GOTO into a DO loop from outside. I mean, of what use would that be? Quite a bit if you do it the way PL/I does. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
In 1334665025.13456.yahoomai...@web180919.mail.ne1.yahoo.com, on 04/17/2012 at 05:17 AM, Lloyd Fuller leful...@sbcglobal.net said: In 1969, and until sometime in the 1970s or later, the Army programming school was at Fort Benjamin Harrison in Indiana. Uncle Bennie's Rest Home. Indianapolis has a reputation as unfriendly, but it was the only one of the three[2] training facilities I went through where the local civilians treated us decently. [2] The other two were Gordon and Jackson. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
In 4809508338399138.wa.paulgboulderaim@bama.ua.edu, on 04/16/2012 at 08:10 AM, Paul Gilmartin paulgboul...@aim.com said: Rexx is a nightmare here. No. The signal statement in Rexx is not a go to. What is a nightmare is using a hammer as a screwdriver. Not that Rexx doesn't have issues, but what language doesn't? Listen to Every OS Sucks by 3 Dead Trolls in a Baggie. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
In 45e5f2f45d7878458ee5ca679697335502e25...@usdaexch01.kbm1.loc, on 04/16/2012 at 12:01 PM, Staller, Allan allan.stal...@kbmg.com said: BTW, I agree w/Dykstra. Maintaining a structured program is far easier than spaghetti code. False dichotomy. You can have spaghetti code without goto and you can use goto judiciously without writing spaghetti code. You have to carve the bird at the joints. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
In gmcoo7556nqho5rueq0jugpaop83t96...@4ax.com, on 04/16/2012 at 05:57 PM, Binyamin Dissen bdis...@dissensoftware.com said: But with GOTOless programming the logic is easier to read. Except when it's harder. The real issue is structuring the code so that it's easier to read and maintain, not blindly following a theological dictum. If that requires more goto statements then I'll cheerfully use them. Read Structured Programming Using goto (I'm not sure of the spelling.) -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
In cajtoo5_idwr_3ryqqqfonyhewxdte5yssj0lwdjg0-svbka...@mail.gmail.com, on 04/16/2012 at 09:32 PM, Mike Schwab mike.a.sch...@gmail.com said: TLA for ARMY Private FIrst Class. Give me back my Air Force. I believe that the Marines also have the rank. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On Tue, Apr 17, 2012 at 5:21 PM, Shmuel Metz (Seymour J.) Listen to Every OS Sucks by 3 Dead Trolls in a Baggie. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Animated version. http://www.youtube.com/watch?v=hg0iRd4i0qk -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 16 Apr 2012 07:35:00 -0700, in bit.listserv.ibm-main you wrote: This topic I cannot resist... Uggg... Having learned COBOL in the mid 70's, the instructor taught that PERFORM was to be used only in situations where you wanted to do a certain routine at several locations in the program. The teaching was also about straight line programming. Flow Charts were also part of the curriculum. 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. What compiler were you working with? What other changes did you make? COBOL VS (the 1974 standard) had poor code generation for PERFORM and PERFORM ... UNTIL was especially poor. VS COBOL II V1R4 drastically changed that with simplified linkage where paragraphs could only be reached by PERFORM and in many cases PERFORMED paragraphs were moved inline to eliminate the branching. The compiler could detect where a one byte field was initialized and never changed so it could use immediate instructions (MVI, CLI) when the field was used in a MOVE or COMPARE. Making sure all sequential files had BLOCK 0 coded also did wonders. 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 16 Apr 2012 13:46:08 -0700, in bit.listserv.ibm-main you wrote: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 04/16/2012 10:57:47 AM: From: Binyamin Dissen bdis...@dissensoftware.com The elimination of GOTOs was to save people time at the cost of CPU time. ? Obviously, if a procedure was called from several points ALTER GOTO would generate fewer instructions than perform. The last time I looked at a PMAP, the Cobol compiler implements PERFORM exactly like an ALTERed GO TO, except that all addresses are stored in a table. Take a look at the optimized code where paragraphs can only be reached by PERFORM. In many cases the code for a PERFORM is actually the code for the paragraph being PERFORMED. Clark Morris But with GOTOless programming the logic is easier to read. There is no question about how you got somewhere. agreed - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 16 Apr 2012 11:02:51 -0700, in bit.listserv.ibm-main you wrote: A dirty myth about COBOL is the belief the THRU is required and that SECTIONs are a good idea. Unless specifically required by SORT or something, I never used either. It has been 20+ years since I did much COBOL. Haven't had the pleasure of the newer constructs. Nothing requires sections any more. My comments on GO TO are based on the compiler optimizations done for PERFORM and what GO TO does to those optimizations. Also the IF ... END-IF READ ... END-READ etc. statements greatly reduce complexity. If you don't believe that GO TO can have an effect try compiling a program generated by CSP release 4 with all its GO TO statements with OPTIMIZE. If the module is large enough it can give the compiler real fits and chew CPU time unbelievably. Clark Morris As to the OP's belief about performance, structured programming has never been about performance, it is about understandability. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Monday, April 16, 2012 5:28 AM To: IBM-MAIN@bama.ua.edu Subject: Re: GO TO cobol Our use of GO TO is generally restricted to usage such as: PERFORM I-P THRU I-P-EXIT UNTIL CONDITION. I-P. READ FILE AT END SET CONDITION TO TRUE GO TO I-P-EXIT END-READ ... I-P-EXIT. EXIT. Otherwise, to avoid the GO TO, we'd need to do: I-P. READ FILE AT END SET CONDITION TO TRUE END-READ IF NOT CONDITION THEN ... END-IF. I-P-EXIT. EXIT. Which I consider to be worse than the exit, so far as comprehension is concerned. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg Sent: Monday, April 16, 2012 5:40 AM To: IBM-MAIN@bama.ua.edu Subject: SV: GO TO cobol An alternative is to have e g an 88-type LEAVE item that is checked for every code-block including all iterations and selections. (You set leave to true when wanting to do a leave type jump.) Regards, Thomas Berg __ Thomas Berg Specialist AM/DQS SWEDBANK AB (publ) -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Edward Jaffe Skickat: den 16 april 2012 08:15 Till: IBM-MAIN@bama.ua.edu Ämne: Re: GO TO cobol On 4/15/2012 10:31 PM, Wayne Bickerdike wrote: For devotees of Jackson Structured programming, the GOTO is a must for POSIT and ADMIT processing. Otherwise it can be messy avoiding a GOTO. The problem with GOTO is that the suitability of the target branch location is not enforced by the compiler according to any structured discipline. Premature terminations (posit/quit/admit) can almost always be handled with LEAVE-type statements or immediate return from a subroutine. Some languages have SIGNAL, EXIT, etc. which can help provide structured premature termination for larger routines without resorting to the dreaded GOTO. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists
Re: GO TO cobol
On 16 Apr 2012 14:25:19 -0700, in bit.listserv.ibm-main you wrote: I have many years' experience writing COBOL code and have used GO TO and THRU only as a means of exiting a paragraph. I frequently code paragraph subroutines that perform a series of related edits, and would use them like this: Perform 2000-Validate-Input thru 2000-exit. *test resultant switch settings here... 2000-Validate-Input. If some-test-here-failed Set indicator-switch to true Go to 2000-exit End-if. If some-other-test-fails Set indicator-different-switch to true Go to 2000-exit End-if. * Blah, blah, blah * When you get here, all tests are good and action can be taken 2000-exit. Exit. The THRU clause is only to support an exit paragraph ability. Because I follow some rules with this technique, it has never caused me a problem. The rules? They are simple: - Only go to the exit point for the current paragraph. I never span. This means that the go to statements are always pointed downward - the same way my perform statements always point. - I verify that this rule is observed by F GO WORD in ISPF (with comments excluded). Each time I find a GO, I then look for P'-' 8 to ensure that the exit paragraph is the next paragraph. I, too, believe that thru and section is a preference that can't be persuaded in most people. I personally hate to use sections and view them as evil. When forced to use sections, such as when performing an internal sort, I just code unreferenced dummy sections around my input and output sections. It would be nice if an exit paragraph statement existed. When it does, I'll never need a THRU or GO TO again - and good riddance! It has existed in the COBOL standard since 2002, just not in any IBM compiler. Add it to the list of SHARE requirements for functions that exist in the 2002 standard. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 16 Apr 2012 14:32:30 -0700, in bit.listserv.ibm-main you wrote: Use of NEXT SENTENCE is as dangerous as GO TO. Try using CONTINUE. The former takes you to the next period; the latter takes you to the end of the current conditional. One missed period and -- I've seen many programs without a single period. How they work is beyond my comprehension. Of course, a paragraph name does imply a period. All paragraphs have to end with a period. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Loyd: Fort Wauchooka (sp??) rings a bell somewhere in my cob ridden memory. But I also now remember Ft Ben Harrison (now). I remember the guys talking about the desert and thats about all. Ed On Apr 17, 2012, at 7:17 AM, Lloyd Fuller wrote: In 1969, and until sometime in the 1970s or later, the Army programming school was at Fort Benjamin Harrison in Indiana. Graduated in March 1969 as a Staff Sergeant converted to a SP6. Programming since then. lLOYD - Original Message From: Ed Gould edgould1...@comcast.net To: IBM-MAIN@bama.ua.edu Sent: Tue, April 17, 2012 12:16:33 AM Subject: Re: GO TO cobol On Apr 16, 2012, at 8:34 AM, McKown, John wrote: SNIP- Also remember that COBOL, at least originally, was supposed to be very English-like and so usable by people at the Army PFC level of training. --John McKown Systems Engineer IV IT Hmmm... I was in the Army and we got PFC's from the programming school (AZ? its been 40 years so forgive me). We had two groups, one COBOL (batch processing) and one ASM group (essentially sysprogs). The ASM group was by far the best IMO. I was on call quite often and had to fix the cobol programs that went boom in the middle of the night. The COBOL people were semi useless in debugging and when I looked at the code they had produced (except for a few people) it was hopeless to understand. I spent more time trying to figure out the logic and compare what I was seeing in the dump. 1/3 the time I helped the programmer figure out where his problem was and supplying answers to his questions on what was in this field or that field. What was interesting was that as the guys (no female programmers so don't call me sexist blame the Army not me) as they became more experienced the code became easier to follow. As they became became better programmers there were less logic problems. Now having said that most of the programs were smallish and only a few were considered large so the smallish programs there was no excuse for logic issues or mangled code. My memory is foggy here as to goto's but I think the rule no standards if memory serves me that goto's were to be minimized as a result flow was easier to follow and frankly debugging was easier. Ed ps: We had one person who at the time he was drafted was working for IBM and he privately told me about some OS enhancements that when I first heard I couldn't wrap my head around as virtual (at least that I had never heard of) was a nightmare that I couldn't wrap my head around. After I got out of the Army (2 years) IBM announced Virtual and I was able to ask some semi intelligent questions as my preview and the questions helped jump start by job. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 4/15/2012 10:31 PM, Wayne Bickerdike wrote: For devotees of Jackson Structured programming, the GOTO is a must for POSIT and ADMIT processing. Otherwise it can be messy avoiding a GOTO. The problem with GOTO is that the suitability of the target branch location is not enforced by the compiler according to any structured discipline. Premature terminations (posit/quit/admit) can almost always be handled with LEAVE-type statements or immediate return from a subroutine. Some languages have SIGNAL, EXIT, etc. which can help provide structured premature termination for larger routines without resorting to the dreaded GOTO. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: GO TO cobol
An alternative is to have e g an 88-type LEAVE item that is checked for every code-block including all iterations and selections. (You set leave to true when wanting to do a leave type jump.) Regards, Thomas Berg __ Thomas Berg Specialist AM/DQS SWEDBANK AB (publ) -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Edward Jaffe Skickat: den 16 april 2012 08:15 Till: IBM-MAIN@bama.ua.edu Ämne: Re: GO TO cobol On 4/15/2012 10:31 PM, Wayne Bickerdike wrote: For devotees of Jackson Structured programming, the GOTO is a must for POSIT and ADMIT processing. Otherwise it can be messy avoiding a GOTO. The problem with GOTO is that the suitability of the target branch location is not enforced by the compiler according to any structured discipline. Premature terminations (posit/quit/admit) can almost always be handled with LEAVE-type statements or immediate return from a subroutine. Some languages have SIGNAL, EXIT, etc. which can help provide structured premature termination for larger routines without resorting to the dreaded GOTO. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Our use of GO TO is generally restricted to usage such as: PERFORM I-P THRU I-P-EXIT UNTIL CONDITION. I-P. READ FILE AT END SET CONDITION TO TRUE GO TO I-P-EXIT END-READ ... I-P-EXIT. EXIT. Otherwise, to avoid the GO TO, we'd need to do: I-P. READ FILE AT END SET CONDITION TO TRUE END-READ IF NOT CONDITION THEN ... END-IF. I-P-EXIT. EXIT. Which I consider to be worse than the exit, so far as comprehension is concerned. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg Sent: Monday, April 16, 2012 5:40 AM To: IBM-MAIN@bama.ua.edu Subject: SV: GO TO cobol An alternative is to have e g an 88-type LEAVE item that is checked for every code-block including all iterations and selections. (You set leave to true when wanting to do a leave type jump.) Regards, Thomas Berg __ Thomas Berg Specialist AM/DQS SWEDBANK AB (publ) -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Edward Jaffe Skickat: den 16 april 2012 08:15 Till: IBM-MAIN@bama.ua.edu Ämne: Re: GO TO cobol On 4/15/2012 10:31 PM, Wayne Bickerdike wrote: For devotees of Jackson Structured programming, the GOTO is a must for POSIT and ADMIT processing. Otherwise it can be messy avoiding a GOTO. The problem with GOTO is that the suitability of the target branch location is not enforced by the compiler according to any structured discipline. Premature terminations (posit/quit/admit) can almost always be handled with LEAVE-type statements or immediate return from a subroutine. Some languages have SIGNAL, EXIT, etc. which can help provide structured premature termination for larger routines without resorting to the dreaded GOTO. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
What??? monopolizes the CPU??? GO TO was made a pariah by an article by Edgar Dijkstra. http://en.wikipedia.org/wiki/Considered_harmful And, of course, management went stupid (again) and came up with you cannot use the GOTO in any code at all. Which actually makes some COBOL more complicated due to the requirement of nesting IF statements within IF statements. And before the END-IF, that could be very complicated. I've see old code like: IF ... THEN ... IF ... THEN ... ELSE NEXT SENTENCE ... IF ... THEN ... IF ... THEN ... ELSE NEXT SENTENCE ELSE ... . Each internal IF had to have a corresponding ELSE with only NEXT SENTENCE in it. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jake anderson Sent: Sunday, April 15, 2012 10:49 PM To: IBM-MAIN@bama.ua.edu Subject: GO TO cobol 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. Are there any documentation explaining about the GO TO statements which clearly describes how it effects the System CPU and performances ? Apology again if the question is not really sensible or else it requires more information. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On Sun, 15 Apr 2012 23:15:19 -0700, Edward Jaffe wrote: The problem with GOTO is that the suitability of the target branch location is not enforced by the compiler according to any structured discipline. C commits this offense. Shame on C. Premature terminations (posit/quit/admit) can almost always be handled with LEAVE-type statements or immediate return from a subroutine. Some languages have SIGNAL, EXIT, etc. which can help provide structured premature termination for larger routines without resorting to the dreaded GOTO. Rexx is a nightmare here. The LEAVE statement, even with a specified target, won't exit a (nest of) procedure(s). The SIGNAL statement trashes the DO nesting at the target level. Shame on Rexx. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On Mon, 16 Apr 2012 07:28:10 -0500, McKown, John wrote: Our use of GO TO is generally restricted to usage such as: PERFORM I-P THRU I-P-EXIT UNTIL CONDITION. I-P. READ FILE AT END SET CONDITION TO TRUE GO TO I-P-EXIT END-READ ... I-P-EXIT. EXIT. Otherwise, to avoid the GO TO, ... I don't know COBOL. However any properly designed language should allow incorporating such a test in the loop control expression: while read( ... ); do ... done -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Remember when COBOL was originally designed. We've learned a LOT since then. The only real looping verb is PERFORM. It has an WHILE condition test and an UNTIL condition test. And, in modern COBOLs, the phrases WITH TEST BEFORE or WITH TEST AFTER, to perform the test at the start of the loop (0 or more iterations, like while in C) or at the end of the loop (1 or more iteration, like do while in C). WITH TEST AFTER is the default. But the UNTIL is a condition test and cannot execute something which returns a TRUE/FALSE type value. Also remember that COBOL, at least originally, was supposed to be very English-like and so usable by people at the Army PFC level of training. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, April 16, 2012 8:12 AM To: IBM-MAIN@bama.ua.edu Subject: Re: GO TO cobol On Mon, 16 Apr 2012 07:28:10 -0500, McKown, John wrote: Our use of GO TO is generally restricted to usage such as: PERFORM I-P THRU I-P-EXIT UNTIL CONDITION. I-P. READ FILE AT END SET CONDITION TO TRUE GO TO I-P-EXIT END-READ ... I-P-EXIT. EXIT. Otherwise, to avoid the GO TO, ... I don't know COBOL. However any properly designed language should allow incorporating such a test in the loop control expression: while read( ... ); do ... done -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
John, the READ construct now is much easier with READ FILE AT END Do stuff NOT AT END Do normal processing END-READ This makes it really easy to keep the code tight and all together. By using program switches, I have handled program start and end, abend, and processed 6 or 7 files with no (or very few) paragraphs, and only a couple statements ending with periods. It actually was fun to put together and was easy to maintain. However, it would not always be this streamlined for some large programs with lots of things going on. Billy On Mon, Apr 16, 2012 at 8:28 AM, McKown, John john.mck...@healthmarkets.com wrote: Our use of GO TO is generally restricted to usage such as: PERFORM I-P THRU I-P-EXIT UNTIL CONDITION. I-P. READ FILE AT END SET CONDITION TO TRUE GO TO I-P-EXIT END-READ ... I-P-EXIT. EXIT. Otherwise, to avoid the GO TO, we'd need to do: I-P. READ FILE AT END SET CONDITION TO TRUE END-READ IF NOT CONDITION THEN ... END-IF. I-P-EXIT. EXIT. Which I consider to be worse than the exit, so far as comprehension is concerned. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.comhttp://www.healthmarkets.com/ Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg Sent: Monday, April 16, 2012 5:40 AM To: IBM-MAIN@bama.ua.edu Subject: SV: GO TO cobol An alternative is to have e g an 88-type LEAVE item that is checked for every code-block including all iterations and selections. (You set leave to true when wanting to do a leave type jump.) Regards, Thomas Berg __ Thomas Berg Specialist AM/DQS SWEDBANK AB (publ) -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Edward Jaffe Skickat: den 16 april 2012 08:15 Till: IBM-MAIN@bama.ua.edu Ämne: Re: GO TO cobol On 4/15/2012 10:31 PM, Wayne Bickerdike wrote: For devotees of Jackson Structured programming, the GOTO is a must for POSIT and ADMIT processing. Otherwise it can be messy avoiding a GOTO. The problem with GOTO is that the suitability of the target branch location is not enforced by the compiler according to any structured discipline. Premature terminations (posit/quit/admit) can almost always be handled with LEAVE-type statements or immediate return from a subroutine. Some languages have SIGNAL, EXIT, etc. which can help provide structured premature termination for larger routines without resorting to the dreaded GOTO. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- Thank you and best regards, *Billy Ashton* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Yes, modern COBOL is much better. I don't use COBOL much, and other than the new END-verb constructs, don't do much. But you still need a PERFORM to loop. I.e. you cannot loop in the READ verb itself. Might be nice. I guess you could: PERFORM UNTIL EOF READ ... AT END SET EOF TO TRUE NOT AT END ... END-READ END-PERFORM I haven't looked recently, but we have a lot of old code. So we don't have much with the newer constructs. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Bill Ashton Sent: Monday, April 16, 2012 8:36 AM To: IBM-MAIN@bama.ua.edu Subject: Re: GO TO cobol John, the READ construct now is much easier with READ FILE AT END Do stuff NOT AT END Do normal processing END-READ This makes it really easy to keep the code tight and all together. By using program switches, I have handled program start and end, abend, and processed 6 or 7 files with no (or very few) paragraphs, and only a couple statements ending with periods. It actually was fun to put together and was easy to maintain. However, it would not always be this streamlined for some large programs with lots of things going on. Billy On Mon, Apr 16, 2012 at 8:28 AM, McKown, John john.mck...@healthmarkets.com wrote: Our use of GO TO is generally restricted to usage such as: PERFORM I-P THRU I-P-EXIT UNTIL CONDITION. I-P. READ FILE AT END SET CONDITION TO TRUE GO TO I-P-EXIT END-READ ... I-P-EXIT. EXIT. Otherwise, to avoid the GO TO, we'd need to do: I-P. READ FILE AT END SET CONDITION TO TRUE END-READ IF NOT CONDITION THEN ... END-IF. I-P-EXIT. EXIT. Which I consider to be worse than the exit, so far as comprehension is concerned. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.comhttp://www.healthmarkets.com/ Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg Sent: Monday, April 16, 2012 5:40 AM To: IBM-MAIN@bama.ua.edu Subject: SV: GO TO cobol An alternative is to have e g an 88-type LEAVE item that is checked for every code-block including all iterations and selections. (You set leave to true when wanting to do a leave type jump.) Regards, Thomas Berg __ Thomas Berg Specialist AM/DQS SWEDBANK AB (publ) -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Edward Jaffe Skickat: den 16 april 2012 08:15 Till: IBM-MAIN@bama.ua.edu Ämne: Re: GO TO cobol On 4/15/2012 10:31 PM, Wayne Bickerdike wrote: For devotees of Jackson Structured programming, the GOTO is a must for POSIT and ADMIT processing. Otherwise it can be messy avoiding a GOTO. The problem with GOTO is that the suitability of the target branch location is not enforced by the compiler according to any structured discipline. Premature terminations (posit/quit/admit) can almost always be handled with LEAVE-type statements or immediate return from a subroutine. Some languages have SIGNAL, EXIT, etc. which can help provide structured premature termination for larger routines without resorting to the dreaded GOTO. -- Edward E Jaffe Phoenix Software
SV: GO TO cobol
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Paul Gilmartin Skickat: den 16 april 2012 15:11 Till: IBM-MAIN@bama.ua.edu Ämne: Re: GO TO cobol On Sun, 15 Apr 2012 23:15:19 -0700, Edward Jaffe wrote: The problem with GOTO is that the suitability of the target branch location is not enforced by the compiler according to any structured discipline. C commits this offense. Shame on C. Premature terminations (posit/quit/admit) can almost always be handled with LEAVE-type statements or immediate return from a subroutine. Some languages have SIGNAL, EXIT, etc. which can help provide structured premature termination for larger routines without resorting to the dreaded GOTO. Rexx is a nightmare here. The LEAVE statement, even with a specified target, won't exit a (nest of) procedure(s). The SIGNAL statement trashes the DO nesting at the target level. Shame on Rexx. I can see that as a feature. ;) That prohibits some obfuscate like coding. (BTW, How do You imagine the behavior if the Signal DID NOT trash the DO nesting? I mean, of what use would that be? As You have the CALL stmt.) Regards, Thomas Berg __ Thomas Berg Specialist AM/DQS SWEDBANK AB (publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
And of course there were languages of the time like FORTRAN, which encouraged unconstrained use of GO TO and the creation of spaghetti code. FORTRAN at that point had very limited support for structured programming: one very restrictive loop construct and a conditional branch which was essentially a three-way GO TO. There were even cases where the conventions being followed might require a GO TO to reach corrective additions which would then use a GO TO to resume the original statement stream, either to preserve statement number sequencing conventions, or to avoid resequencing the entire program deck when all cards had sequence numbers. I think more people interpreted Dijkstra's remarks as a complaint against the unstructured use of GO TO and the lack of language support for structured programming constructs that forced frequent GO TO use, rather than an arbitrary total ban. The complaint was primarily one about use of the GO TO degrading comprehension of the program structure, not about program performance. Ultimately, all code is reduced to the Assembler or machine language level, where the machine-level equivalent of the GO TO is essential and unavoidable. ACM SIGPLAN (Special Interest Group on Programming Languages) Notices tended to publish humor, especially near April 1. One proposal many years ago to totally eliminate the FORTRAN GO TO was to replace it with a COME FROM statement. This totally eliminated the confusion over whether any FORTRAN statement with a statement number might be the target of some unseen remote branch -- and replaced it with the even more confusing concept that every statement with a statement number might actually be a disguised branch to some remote COME FROM statement. JC Ewing On 04/16/2012 07:42 AM, McKown, John wrote: What??? monopolizes the CPU??? GO TO was made a pariah by an article by Edgar Dijkstra. http://en.wikipedia.org/wiki/Considered_harmful And, of course, management went stupid (again) and came up with you cannot use the GOTO in any code at all. Which actually makes some COBOL more complicated due to the requirement of nesting IF statements within IF statements. And before the END-IF, that could be very complicated. I've see old code like: IF ... THEN ... IF ... THEN ... ELSE NEXT SENTENCE ... IF ... THEN ... IF ... THEN ... ELSE NEXT SENTENCE ELSE ... . Each internal IF had to have a corresponding ELSE with only NEXT SENTENCE in it. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
This topic I cannot resist... Uggg... Having learned COBOL in the mid 70's, the instructor taught that PERFORM was to be used only in situations where you wanted to do a certain routine at several locations in the program. The teaching was also about straight line programming. Flow Charts were also part of the curriculum. 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. 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On Mon, 2012-04-16 at 09:52 -0400, Joel C. Ewing wrote: One proposal many years ago to totally eliminate the FORTRAN GO TO was to replace it with a COME FROM statement. Ah yes, an old chestnut: http://www.fortran.com/come_from.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: GO TO cobol
On Mon, 16 Apr 2012 15:42:12 +0200, Thomas Berg wrote: Premature terminations (posit/quit/admit) can almost always be handled with LEAVE-type statements or immediate return from a subroutine. Some languages have SIGNAL, EXIT, etc. which can help provide structured premature termination for larger routines without resorting to the dreaded GOTO. Rexx is a nightmare here. The LEAVE statement, even with a specified target, won't exit a (nest of) procedure(s). The SIGNAL statement trashes the DO nesting at the target level. Shame on Rexx. I can see that as a feature. ;) That prohibits some obfuscate like coding. As it stands, the only way to exit a nest of procedures is to set a flag and RETURN, and test that flag and RETURN after each intervening cal; hardly unobfuscated. I'd be delighted to be able to code, instead DO I =1 DO J = 1 DO K= 1 CALL P1 ... END K END J END I P1: CALL P2 P2: PROCEDURE EXPOSE J LEAVE J I forgot to mention that SIGNAL trashes the DO nesting but does not exit _any_ procedures. I was once called on to advise a novice colleague who had used SIGNAL, he thought, to leave a procedure nest. Necessarily, he had coded all his loops with GOTO instead of DO. It worked fine on small data sets; he came to me for help when it overflowed the stack on a large data set. (BTW, How do You imagine the behavior if the Signal DID NOT trash the DO nesting? I mean, of what use would that be? As You have the CALL stmt.) It could be used as a local GOTO. But that would still be of no use to me, because I never use SIGNAL as a GOTO, only in SIGNAL ON NOVALUE/ERROR. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: SV: GO TO cobol
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Paul Gilmartin Skickat: den 16 april 2012 16:33 Till: IBM-MAIN@bama.ua.edu Ämne: Re: SV: GO TO cobol On Mon, 16 Apr 2012 15:42:12 +0200, Thomas Berg wrote: Rexx is a nightmare here. The LEAVE statement, even with a specified target, won't exit a (nest of) procedure(s). The SIGNAL statement trashes the DO nesting at the target level. Shame on Rexx. I can see that as a feature. ;) That prohibits some obfuscate like coding. As it stands, the only way to exit a nest of procedures is to set a flag and RETURN, and test that flag and RETURN after each intervening cal; hardly unobfuscated. I'd be delighted to be able to code, instead DO I =1 DO J = 1 DO K= 1 CALL P1 ... END K END J END I P1: CALL P2 P2: PROCEDURE EXPOSE J LEAVE J Ok, I can see logic in this. Although it makes the code somewhat harder to understand as You have to check the called procedures for those leave's if You want to understand the loops. An existing alternative would perhaps be RETURNing LEAVE J and: DO I =1 DO J = 1 DO K= 1 CALL P1 IF RESULT = 'LEAVE J' THEN LEAVE J ... END K END J END I Regards, Thomas Berg __ Thomas Berg Specialist AM/DQS SWEDBANK AB (publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On Mon, 16 Apr 2012 09:30:47 -0500 Matthew Stitt mathwst...@bellsouth.net wrote: :This topic I cannot resist... Uggg... :Having learned COBOL in the mid 70's, the instructor taught that PERFORM was to be used only in situations where you wanted :to do a certain routine at several locations in the program. The teaching was also about straight line programming. Flow :Charts were also part of the curriculum. :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. The elimination of GOTOs was to save people time at the cost of CPU time. Obviously, if a procedure was called from several points ALTER GOTO would generate fewer instructions than perform. But with GOTOless programming the logic is easier to read. There is no question about how you got somewhere. :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. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: SV: GO TO cobol
On Mon, 16 Apr 2012 16:51:27 +0200, Thomas Berg wrote: DO I =1 DO J = 1 DO K= 1 CALL P1 ... END K END J END I P1: CALL P2 P2: PROCEDURE EXPOSE J LEAVE J Ok, I can see logic in this. Although it makes the code somewhat harder to understand as You have to check the called procedures for those leave's if You want to understand the loops. An existing alternative would perhaps be RETURNing LEAVE J and: DO I =1 DO J = 1 DO K= 1 CALL P1 IF RESULT = 'LEAVE J' THEN LEAVE J ... END K END J END I Again, if P1 were to do any processing after the call to P2 P1 would need to make the same test. This is just a form or set-a-flag-and-test-after-each-call. It's a trivial exercise to convert any tangle of GOTOs to a DO containing a SELECT with no gain in legibility or in reliability. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Embrace functional programming and eschew the historic procedural paradigm! You have nothing to lose but your chains! And maybe your mind. There is no GOTO in any pure functional language that I've read up on (basically Haskell and Erlang). Ah, imagine the joys of writing CICS code in LISP (Lots of Insipid, Silly Parentheses). John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On Mon, 2012-04-16 at 11:08 -0400, McKown, John wrote: Ah, imagine the joys of writing CICS code in LISP (Lots of Insipid, Silly Parentheses). There are more parentheses in Java code than equivalent Clojure. Just sayin'. -- David Andrews A. Duda Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
GO TO cobol
Suppose that I wish to do something to each of the elements of an assembly-time array in turn. In the macro language of the HLASM I must write something like |ne seta n'array |i seta 0 |.traverse_loop anop |i seta i+1 |elements_exhausted setb (i gt ne) | aif (elements_exhausted).traverse_lend | . . . process array(i) | ago.traverse_loop |.traverse_lend anop In other languages I can write functional equivalents more compactly. In all of them I can do this of anything else well or very badly indeed. Positive, chiefly one-on-one, mentoring focused on how to code well can be very helpful. Prohibitions cannot. They are always and everywhere unwise. They never ensure that code written using some notionally virtuous subset of a language will have any positive merit. It used to be thought that all would be well with the world when the last king had been strangled. We know better now, but we continue to seek authoritarian, Orwellian solutions to the problem of programming quality. Our world will not be an improved one when the last explicit GOTO has been excised from the last routine still in use somewhere. Bad code and good code reflect the qualities of mind, training, and experience of the programmers who write them; there are no shortcuts available for producing the good kind. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
The branch execution logic in modern (s/360 or newer. YES s/360 circa 1963) are among the most efficient in the processor. That still has not changed. Forget anyone ever told you that GO TO increases CPU overhead. snip .. GO TO was made a pariah by an article by Edgar Dijkstra. http://en.wikipedia.org/wiki/Considered_harmful And, of course, management went stupid (again) and came up with you cannot use the GOTO in any code at all. Which actually makes some COBOL more complicated due to the requirement of nesting IF statements within IF statements. /snip Just as in many other things, a good idea can be taken to an illogical extreme or out of context. In addition to avoiding GO TO's, Dykstra also proposed limiting each module to 1 page or less of code, that being the upper limit of what could be proven to be correct code. ( I'll bet management forgot about that one!). BTW, I agree w/Dykstra. Maintaining a structured program is far easier than spaghetti code. However, one page of code is a very small routine and will result in excessive overhead due to all of the module calls. (BTDTGTTS). I haven't re-read Dykstra in many years, but I believe that he may have left some loopholes. All of that being said, sometimes a plain old GO TO is far easier to decipher that if/then/else nested ad nauseum. As with most things in this business, it depends! Just my $0.02 (USD) worth. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 4/16/2012 12:26 PM, John Gilmore wrote: Suppose that I wish to do something to each of the elements of an assembly-time array in turn. In the macro language of the HLASM I must write something like |ne seta n'array |i seta 0 |.traverse_loop anop |i setai+1 |elements_exhausted setb (i gtne) | aif (elements_exhausted).traverse_lend | . . .processarray(i) | ago.traverse_loop |.traverse_lend anop Must you? g In this case I would prefer: .* i seta0 *default* .trvloop aif(i ge n'array).trvend i setai+1 . . .processarray(i) ago .trvloop .trvend anop, That's six statements instead of nine. I was raised in the era of six (ForTran) and eight character variables, and find those easier to read. I'd use ne only for larger array sizes; for small ones the savings are not noticeable. Whether or not code is aesthetically pleasing is very much a matter of nurture. With effective comments, the structure of code isn't all that critical, and discussions of GOTO versus GOTO-less programming are about as useful as religious arguments. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
If we're going to talk about these issues it will be useful to avoid carelessness. There may well be or have been an Edgar Dijkstra, but if so he has been silent about GOTOs. The Dijkstra of interest here was Edsger W. Dijkstra (1930-2002). John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
I agree that there is more than one good way to do everything. Gerhard's code is fine. For a loop where it is invariant, I should prefer to save and reuse n'array; and I prefer the boolean assignment statement and AIF |elements_exhausted setb (i gt ne) | aif (elements_exhausted).traversal_lend to his single statement. I even object, but not much, to |.trvend anop , I supply the missing-operand comma for anop, mexit, etc., only when I want to place a comment after it. These, however, are details that are important only as they contribute to coherence. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
A dirty myth about COBOL is the belief the THRU is required and that SECTIONs are a good idea. Unless specifically required by SORT or something, I never used either. It has been 20+ years since I did much COBOL. Haven't had the pleasure of the newer constructs. As to the OP's belief about performance, structured programming has never been about performance, it is about understandability. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Monday, April 16, 2012 5:28 AM To: IBM-MAIN@bama.ua.edu Subject: Re: GO TO cobol Our use of GO TO is generally restricted to usage such as: PERFORM I-P THRU I-P-EXIT UNTIL CONDITION. I-P. READ FILE AT END SET CONDITION TO TRUE GO TO I-P-EXIT END-READ ... I-P-EXIT. EXIT. Otherwise, to avoid the GO TO, we'd need to do: I-P. READ FILE AT END SET CONDITION TO TRUE END-READ IF NOT CONDITION THEN ... END-IF. I-P-EXIT. EXIT. Which I consider to be worse than the exit, so far as comprehension is concerned. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg Sent: Monday, April 16, 2012 5:40 AM To: IBM-MAIN@bama.ua.edu Subject: SV: GO TO cobol An alternative is to have e g an 88-type LEAVE item that is checked for every code-block including all iterations and selections. (You set leave to true when wanting to do a leave type jump.) Regards, Thomas Berg __ Thomas Berg Specialist AM/DQS SWEDBANK AB (publ) -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Edward Jaffe Skickat: den 16 april 2012 08:15 Till: IBM-MAIN@bama.ua.edu Ämne: Re: GO TO cobol On 4/15/2012 10:31 PM, Wayne Bickerdike wrote: For devotees of Jackson Structured programming, the GOTO is a must for POSIT and ADMIT processing. Otherwise it can be messy avoiding a GOTO. The problem with GOTO is that the suitability of the target branch location is not enforced by the compiler according to any structured discipline. Premature terminations (posit/quit/admit) can almost always be handled with LEAVE-type statements or immediate return from a subroutine. Some languages have SIGNAL, EXIT, etc. which can help provide structured premature termination for larger routines without resorting to the dreaded GOTO. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 4/16/2012 1:35 PM, John Gilmore wrote: I even object, but not much, to |.trvend anop , I supply the missing-operand comma for anop, mexit, etc., only when I want to place a comment after it. These, however, are details that are important only as they contribute to coherence. The comma is a result of a personal(?) idiosyncrasy. Since the late sixties, I have used columns 65-71 to indicate code changes (author,date); this practice permits detailed identification of modifications that may not be as obvious when provided as paragraph or program comments. Omitting the comma results in assembly errors. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 16 April 2012 13:35, John Gilmore johnwgilmore0...@gmail.com wrote: [...] I even object, but not much, to |.trvend anop , I supply the missing-operand comma for anop, mexit, etc., only when I want to place a comment after it. I've found that the risk of later copying (by me or someone else) of such a code segment, and then putting in update markers toward the right of the input field - typically in the mid to high 60s column positions - makes it worth while to always put in the comma. There are a very few IBM macros, but to my knowledge no assembler statements, that have trouble with this, and they must be handled individually. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
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: justmainfra...@gmail.com (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
Re: GO TO cobol
On 16 Apr 2012 05:45:21 -0700, in bit.listserv.ibm-main you wrote: What??? monopolizes the CPU??? GO TO was made a pariah by an article by Edgar Dijkstra. http://en.wikipedia.org/wiki/Considered_harmful And, of course, management went stupid (again) and came up with you cannot use the GOTO in any code at all. Which actually makes some COBOL more complicated due to the requirement of nesting IF statements within IF statements. And before the END-IF, that could be very complicated. I've see old code like: IF ... THEN ... IF ... THEN ... ELSE NEXT SENTENCE ... IF ... THEN ... IF ... THEN ... ELSE NEXT SENTENCE ELSE ... . Each internal IF had to have a corresponding ELSE with only NEXT SENTENCE in it. You are thinking of the 1974 standard which doesn't have IF ... END-IF. Nesting becomes easier with the 1985 standard and when the IF statement nesting becomes too complex you can move an IF ... END-IF pair into a separate paragraph with little or no performance penalty due to code movement and the simplified PERFORM code if you eliminate GO TO statements. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
IBM Cobol provides the structure format: I-P. READ FILE AT END * the at end stuff NOT AT END * the not at end stuff END-READ IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 04/16/2012 08:28:10 AM: From: McKown, John john.mck...@healthmarkets.com PERFORM I-P THRU I-P-EXIT UNTIL CONDITION. I-P. READ FILE AT END SET CONDITION TO TRUE GO TO I-P-EXIT END-READ ... I-P-EXIT. EXIT. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Use of NEXT SENTENCE is as dangerous as GO TO. Try using CONTINUE. The former takes you to the next period; the latter takes you to the end of the current conditional. One missed period and To replace nested IFs, try using EVALUATE - the most powerful case statement in any language (except structured assembler) according to a friend who does distributed apps. IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 04/16/2012 08:42:05 AM: From: McKown, John john.mck...@healthmarkets.com To: IBM-MAIN@bama.ua.edu, Date: 04/16/2012 08:46 AM Subject: Re: GO TO cobol Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu What??? monopolizes the CPU??? GO TO was made a pariah by an article by Edgar Dijkstra. http://en.wikipedia.org/wiki/Considered_harmful And, of course, management went stupid (again) and came up with you cannot use the GOTO in any code at all. Which actually makes some COBOL more complicated due to the requirement of nesting IF statements within IF statements. And before the END-IF, that could be very complicated. I've see old code like: IF ... THEN ... IF ... THEN ... ELSE NEXT SENTENCE ... IF ... THEN ... IF ... THEN ... ELSE NEXT SENTENCE ELSE ... . Each internal IF had to have a corresponding ELSE with only NEXT SENTENCE in it. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid- West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jake anderson Sent: Sunday, April 15, 2012 10:49 PM To: IBM-MAIN@bama.ua.edu Subject: GO TO cobol 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. Are there any documentation explaining about the GO TO statements which clearly describes how it effects the System CPU and performances ? Apology again if the question is not really sensible or else it requires more information. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Well said IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 04/16/2012 12:00:13 AM: From: Sam Siegel s...@pscsi.net Typically GO TO statements can be avoided by having a good design. A local GO TO here and there is not so bad. The non-local GO TO statements can make long-term maintenance of a program problematic and expensive. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 04/16/2012 10:57:47 AM: From: Binyamin Dissen bdis...@dissensoftware.com The elimination of GOTOs was to save people time at the cost of CPU time. ? Obviously, if a procedure was called from several points ALTER GOTO would generate fewer instructions than perform. The last time I looked at a PMAP, the Cobol compiler implements PERFORM exactly like an ALTERed GO TO, except that all addresses are stored in a table. But with GOTOless programming the logic is easier to read. There is no question about how you got somewhere. agreed - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 04/16/2012 01:59:26 PM: From: Gibney, Dave gib...@wsu.edu A dirty myth about COBOL is the belief the THRU is required and that SECTIONs are a good idea. Unless specifically required by SORT or something, I never used either. It has been 20+ years since I did much COBOL. Haven't had the pleasure of the newer constructs. THROUGH is just stupid. But I have used sections. I think of it as a religious preference. As to the OP's belief about performance, structured programming has never been about performance, it is about understandability. yes and maintainability - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
