ALTER preceded structured programming and hostile to it was Re: Goto Statements AND COBOL OPTIMIZATION
[Default] On 11 Jun 2020 16:17:47 -0700, in bit.listserv.ibm-main rreyno...@cix.co.uk (Rupert Reynolds) wrote: >I lost faith COBOL and finallly became a PL/1 biggot when I was told that >ALTER GOTO was introduced to help support structured programmng :-) As someone who made extensive use ALTER x-exit TO y, GO TO x because of PERFORM code generation on DOS360 and small partitions, I guarantee you the construct preceded structured programming and was less than friendly to maintenance programmers. I rewrote more than one of my programs when partitions grew to be structured and eliminate ALTER statements. Clark Morris > >Rupert > >On Thu, Jun 11, 2020, 01:07 Tom Ross wrote: > >> >The addition of EXIT PARAGRAPH >> >and EXIT SECTION have eliminated most of the reasons for use of GO TO >> >in COBOL. I would be interested in any corrections to my >> >understanding by those responsible for the COBOL compiler. =20 >> >> I partially agree, Clark, but what really made it easy to get rid of GOTOs >> in COBOL (if you wanted to) was EXIT PERFORM and especially EXIT PERFORM >> CYCLE! >> These were added to the Standard with COBOL 2014 and implemented by IBM in >> Enterprise >> COBOL for z/OS V5.2 >> >> Cheers, >> TomR >> COBOL is the Language of the Future! << >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goto Statements AND COBOL OPTIMIZATION
Confession: before I was a PL/1 bigot, I was an Assembler H bigot (now I'm both) :-) Rupert On Fri, Jun 12, 2020, 05:10 Bob Bridges wrote: > Heck, I was a PL/1 bigot from the start. There are other languages I > like, but I remember PL/1 with a kind of rosy glow - possibly because I > never use it any more. > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > /* I think everyone who chooses to stay out of politics (which is your > right) should make a mental note of where they would draw the line and feel > it necessary to get involved. Then ask yourself: Is it possible that point > already arrived, but it happened too slowly to notice? -Chris Evans */ > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Rupert Reynolds > Sent: Thursday, June 11, 2020 19:17 > > I lost faith COBOL and finallly became a PL/1 biggot when I was told that > ALTER GOTO was introduced to help support structured programmng :-) > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goto Statements AND COBOL OPTIMIZATION
>Those were added w/ COBOL 2002, not 2014. Don't give yourself too much cre= >dit! I noticed that too, and thought I had corrected my post, but I guess I failed! Cheers, TomR >> COBOL is the Language of the Future! << -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goto Statements AND COBOL OPTIMIZATION
Heck, I was a PL/1 bigot from the start. There are other languages I like, but I remember PL/1 with a kind of rosy glow - possibly because I never use it any more. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* I think everyone who chooses to stay out of politics (which is your right) should make a mental note of where they would draw the line and feel it necessary to get involved. Then ask yourself: Is it possible that point already arrived, but it happened too slowly to notice? -Chris Evans */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rupert Reynolds Sent: Thursday, June 11, 2020 19:17 I lost faith COBOL and finallly became a PL/1 biggot when I was told that ALTER GOTO was introduced to help support structured programmng :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goto Statements AND COBOL OPTIMIZATION
I lost faith COBOL and finallly became a PL/1 biggot when I was told that ALTER GOTO was introduced to help support structured programmng :-) Rupert On Thu, Jun 11, 2020, 01:07 Tom Ross wrote: > >The addition of EXIT PARAGRAPH > >and EXIT SECTION have eliminated most of the reasons for use of GO TO > >in COBOL. I would be interested in any corrections to my > >understanding by those responsible for the COBOL compiler. =20 > > I partially agree, Clark, but what really made it easy to get rid of GOTOs > in COBOL (if you wanted to) was EXIT PERFORM and especially EXIT PERFORM > CYCLE! > These were added to the Standard with COBOL 2014 and implemented by IBM in > Enterprise > COBOL for z/OS V5.2 > > Cheers, > TomR >> COBOL is the Language of the Future! << > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goto Statements AND COBOL OPTIMIZATION
[Default] On 10 Jun 2020 17:14:25 -0700, in bit.listserv.ibm-main tmr...@stlvm20.vnet.ibm.com (Tom Ross) wrote: >>The addition of EXIT PARAGRAPH >>and EXIT SECTION have eliminated most of the reasons for use of GO TO >>in COBOL. I would be interested in any corrections to my >>understanding by those responsible for the COBOL compiler. =20 > >I partially agree, Clark, but what really made it easy to get rid of GOTOs >in COBOL (if you wanted to) was EXIT PERFORM and especially EXIT PERFORM CYCLE! >These were added to the Standard with COBOL 2014 and implemented by IBM in >Enterprise >COBOL for z/OS V5.2 I agree but the main question I was raising is whether if I have GO TO blow-up-paragraph where blow-up-paragraph is the last paragraph which has a CALL "ILBOABN0" or its LE equivalent followed by GOBACK as the last two statements will that disrupt PERFORM optimization? Starting with VS COBOL II release 4 I have PERFORMed blow-up-paragrraph to make sure that my program is fully optimized. Clark Morris > >Cheers, >TomR >> COBOL is the Language of the Future! << > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goto Statements AND COBOL OPTIMIZATION
Those were added w/ COBOL 2002, not 2014. Don't give yourself too much credit! From: IBM Mainframe Discussion List on behalf of Tom Ross Sent: Wednesday, June 10, 2020 6:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Goto Statements AND COBOL OPTIMIZATION >The addition of EXIT PARAGRAPH >and EXIT SECTION have eliminated most of the reasons for use of GO TO >in COBOL. I would be interested in any corrections to my >understanding by those responsible for the COBOL compiler. =20 I partially agree, Clark, but what really made it easy to get rid of GOTOs in COBOL (if you wanted to) was EXIT PERFORM and especially EXIT PERFORM CYCLE! These were added to the Standard with COBOL 2014 and implemented by IBM in Enterprise COBOL for z/OS V5.2 Cheers, TomR >> COBOL is the Language of the Future! << -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goto Statements AND COBOL OPTIMIZATION
>The addition of EXIT PARAGRAPH >and EXIT SECTION have eliminated most of the reasons for use of GO TO >in COBOL. I would be interested in any corrections to my >understanding by those responsible for the COBOL compiler. =20 I partially agree, Clark, but what really made it easy to get rid of GOTOs in COBOL (if you wanted to) was EXIT PERFORM and especially EXIT PERFORM CYCLE! These were added to the Standard with COBOL 2014 and implemented by IBM in Enterprise COBOL for z/OS V5.2 Cheers, TomR >> COBOL is the Language of the Future! << -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goto Statements AND COBOL OPTIMIZATION (was: COBOL Question)
[Default] On 8 Jun 2020 01:55:52 -0700, in bit.listserv.ibm-main dcrayf...@gmail.com (David Crayford) wrote: >I learned JSP back in the early 90's. It was popular in the UK (Jackson >was British) and most large mainframe companies adopted it. It was good. >There was even tooling that >could create code from charts. > >Dijkstra's paper is one of the most controversial CS papers ever >written. It was written before structured programming took off and >programming languages >like FORTRAN and COBOL were not well structured at the time. >Unfortunately, people drank the kool-aid and a whole generation of >programmers were brain-washed by dogma >that goto is inherently evil. I see code all the time that eschews goto >for error handling and the alternative is never better. In fact, it's >always crap! It's either deeply nested if-logic or extra status >flag checks. For languages that support try/finally, use groups, RAII >etc the problem doesn't exist but that's certainly not the case from >almost all mainstream languages that run on z/OS >other than Java and C++. > My avoidance of GO TO in COBOL is based on my understanding of IBM COBOL compiler optimization and not a computer theology that says all GO TO is bad. In the case of error clean up and blow up paragraphs, from a clarity point of view I would prefer to GO TO them but I believe this could adversely affect optimization. While I can't speak for other languages, VS COBOL 2.4 and later optimizations Enterprise COBOL 5.2 do PERFORM optimization where Paragraphs that can only be PERFORMed will cause a simplified generation of code for the related PERFORMs. In some cases the Paragraph is moved inline to replace the PERFORM statement which can bee a performance advantage for caching. I don't believe that PERFORM ... THRU statements are eligible for this optimization. I have avoided GO TO statements and even used PERFORM to execute the error abort Paragraphs accepting the warning message to make certain the optimization could take place. This is because in COBOL the same paragraph could be reached by PERFORM x, PERFORM x THRU exit-x1, PERFORM x THRU exit-x2 and GO TO x. The addition of EXIT PARAGRAPH and EXIT SECTION have eliminated most of the reasons for use of GO TO in COBOL. I would be interested in any corrections to my understanding by those responsible for the COBOL compiler. Clark Morris > >On 2020-06-08 4:28 PM, Wayne Bickerdike wrote: >> Dijkstra wrote his missive around 1968. Knuth made a meal of it and after >> reading his paper which was published 5 years later, it was too hard a read. >> >> Around the same time Michael Jackson was distilling this information and >> produced his structured programming book "Principles of Program Design". I >> still have a copy and generally will approach program design using the same >> tried and tested techniques. At IBM in 1978 we had an advocate for the same >> methods, Tony Droar. Unfortunately, a lot of this good work seemed to miss >> a lot of organisations. Some places I worked in the 80's wouldn't allow a >> sort to make a program easier to write. >> >> Jackson explained go to was essential, particularly when performing >> validationposit.admitquit. I've seen a Jackson structure design >> turned into a flowchart and the structure is lost. Flowcharts encouraged >> the use of GO TO. >> >> On Mon, Jun 8, 2020 at 4:45 PM David Crayford wrote: >> >>> On 2020-06-07 10:48 PM, Paul Gilmartin wrote: > I consider the out of line PERFORM to be far more dangerous. I have a >>> similar issue with REXX; it does not have lexical scope, and you can fall >>> into a procedure. A noteworthy 1976 paper (behind a paywall): Software malpractice a distasteful experience https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380060303 ... describes the pitfall set by a (too) clever programmer's relying on optimization by falling into procedures. In the day, I read it free in the University library. >>> I'm sure that paper is an interesting read from a historical >>> perspective. It's referenced in Code Complete along with another >>> reference to Frank Rubin's letter to the ACM (March 1987) >>> in which he asserts that goto-less programming has cost business >>> "hundreds of millions of dollars". >>> >>> The original context of the "goto considered harmful" is lost on the >>> younger generation, as at the time there were large swaths of developers >>> who were trained before structured programming took off. >>> There are a handful of use cases where "goto" makes the code simpler, >>> cleaner and more readable. In these cases, you /should/ use goto >>> statements. A good programmer can recognize these cases and use goto >>> appropriately. >>> >>> >>> >>> >>> >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu
