Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!news.iecc.com!nerds-end From: Robert AH Prins Newsgroups: comp.compilers Subject: Re: Decades of compiler technology and what do we get? Date: Sun, 22 Apr 2012 22:14:12 +0000 Organization: Compilers Central Lines: 24 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <12-04-072@comp.compilers> References: <12-04-070@comp.compilers> Reply-To: robert@prino.org NNTP-Posting-Host: news.iecc.com X-Trace: leila.iecc.com 1335145196 34271 64.57.183.58 (23 Apr 2012 01:39:56 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Mon, 23 Apr 2012 01:39:56 +0000 (UTC) Keywords: Cobol, performance Posted-Date: 22 Apr 2012 21:39:56 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:615 On 2012-04-22 18:57, Robert AH Prins wrote: > On Apr 22, 12:58 pm, "HeyBub" wrote in > bit.listserv.ibm-main: > > [The conventional wisdom is that COBOL programs are all I/O bound, so > the speed of the object code is not a big deal. There are plenty of > other compilers that can optimize this kind of stuff. -John] As it turns out our test compiles add an OPT(0) after all programmer supplied options "because that takes less CPU..." My comment that this means that production programs are never the same as the ones that have been tested was dismissed with a "We have done this for years without anyone ever having a problem with it." Submitting from SDSF with altered JCL does produce rather better code, so I stand corrected (again, I'm losing it, rapidly...) Apologies to all, at least for the z/OS part! However, I'm not going to retract my remarks about the PL/I for Windows compiler. Robert -- Robert AH Prins robert(a)prino(d)org