There is an LE run time option that controls whether messages are produced for errors, or not ... your installation option has chosen no message. You can set runtime options at system, job or individual program level. Your cobol program can even call CEEHDLR to set its own condition handler. None of this is related to compiler options, it is Language Environment. Having a potential storage overlay turned into correct result automagically is pretty impressive, imho, but I agree that changing compiler options for optimization can often expose latent programming bugs. Hopefully that program isn't still running unmodified in 2100 when the leap year calculation will be wrong :)
On Thu, Sep 10, 2020 at 8:32 AM Savor, Thomas < 00000330b7631be3-dmarc-requ...@listserv.ua.edu> wrote: > >Enterprise PL/I 5.2 supports ARCH(12) so has your desired vector > instruction support. For completeness, so do Cobol 6.2, XL/C 2.3 and Java > 8.5. >Again no source code change in PL/I is needed, just recompile with > >ARCH(12) option. Really sad that IBM doesn't publicize these features > better.... vector usage can cut cpu and elapsed time dramatically (I've > >seen 80% reduction for intensive programs). Great reason to upgrade the > hardware and compilers :) > > The vector instructions are faster ...we saw about 15% between ARCH(11) to > ARCH(12). > BUT..... > Before we got to that point, we have the rug yanked out from under us as > evidently these vector instructions are VERY sensitive to field sizes. > Example: The application that I was supporting, some of this code is from > VSE (late 70's), on every transaction, the transaction date is calculated > to insure if Leap Year or not. This calculation has been there for 30+ > years, it could care less what the answer is, just the remainder. If > remainder, not a leap year in simple terms....anyway answer field was to > small to do calculation...previous versions of Cobol or ARCH levels > truncated the answer and we moved on and were happy. ARCH(12), caused a > major job that processed 1.5 million transactions to go from 10-15 minutes > to 1.5 to 2 hours. Why ?? Jobs ran to successful completion, but every > transaction abended, went into abend recovery, recovered...said > nothing...and continued onward. Strobe said that we were spending 95% of > our time in abend recovery...which upon further investigation pointed to > Leap Year calculation error. My opinion, Cobol should tell you when going > into abend recovery, but it didn’t. > > Thanks, > > Tom > > The information contained in this message is proprietary and/or > confidential. If you are not the intended recipient, please: (i) delete the > message and all copies; (ii) do not disclose, distribute or use the message > in any manner; and (iii) notify the sender immediately. In addition, please > be aware that any message addressed to our domain is subject to archiving > and review by persons other than the intended recipient. Thank you. > > ---------------------------------------------------------------------- > 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
