Yes. The code was buggy. I was just interested to know how the bug had gone undetected. All is good now. The bug has been fixed.
________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Joe Monk <joemon...@gmail.com> Sent: Saturday, March 13, 2021 4:31 AM To: IBM-MAIN@LISTSERV.UA.EDU <IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: EXTERNAL: COBOL V6.2 possible change in behavior with recent patch level What I find really interesting is that this whole problem could have been resolved by simply adding an "IF" condition... 01 ipt. 05 as-char pic xx. 88 as-char-10 value '10'. 05 as-nums redefines as-char pic 99. 88 as-num-10 value 10. IF as-char numeric IF as-num-10 Joe On Sat, Mar 13, 2021 at 1:52 AM Savor, Thomas < 00000330b7631be3-dmarc-requ...@listserv.ua.edu> wrote: > Mr Ross, > > I'm not sure that you guys at IBM have realized that you have created a > nightmare out there in the field for a lot of customers and especially > vendors of COBOL applications. I'm a part of many that support/write > Assembler/Cobol code for a giant Credit Software system. We have 5+ > million lines of code. > > Now as a vendor, we also have "many" processing centers around the World > running our software. Some sites we run, some sites IBM runs. Do you > think that each and every site has the same box, same Z/os level, same > compiler , same maintenance level , same ARCH level or use same OPT setting > ?? All the application folks can do is recommend. But Management and > Systems Programmers tend to do what they want. > > If I'm directed that my Test box is a Z13 (and is), but my Production box > is a Z15 (it's a Z14 at this very moment). Then I'm NEVER testing code > that goes into Production.... EVER. And this has caused problems....some > in the form of abends, some in the form of added run times. Its very > unrealistic to think that I have to regression test 5+ million lines of > code every time maintenance to the compiler is applied, let alone go from > 6.2 to the next Cobol release...who the hell is going to pay for this ?? > The application folks NEVER know when maintenance is going in or when the > next compiler release goes in.....until after the fact. > > IBM and even System Programmers need to stop hiding behind "fix your crap > code", how about "stop changing the behavior of our programs on a whim". > > Last year we had a little very small program cause much grief after 30+ > years of NO PROBLEMS. Our release goes out to a good customer and run time > goes from 10 minutes to 1.5 hours on a transaction edit process of 1+ > million records....terrible. We found out from our customer thru STROBE > that 95% of the time was spent in Abend Recovery because a Leap Year date > calculation routine that couldn't care less about the result of a division > compute statement...only the remainder. But because the result was too > small, program blew up, went into Abend Recovery and continued on. Testing > and UAT had no idea. This was because of the sensitivity of the Vector > Packed Decimal instructions that were on a Z14 box. We were able to > reproduce error on a Z13 with OPT(2)....but had no idea of the > ramifications. > > Personally, I wish we could just stay on COBOL 4.2...but no such luck. > > Thanks, > > Tom > > > > > > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf > Of Tom Ross > Sent: Friday, March 12, 2021 11:45 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: EXTERNAL: COBOL V6.2 possible change in behavior with recent > patch level > > CAUTION: This email originated from outside of the company. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > > >We recently applied patches up through September 2020 to our Enterprise > >COB= OL V6.2 compiler. Prior to this we had patches through September > >2019. Th= is appears to have changed how some code is generate, even > >though the compi= ler options have not changed. > > Frank, this is unfortunate, but I have to say, we do not recommend running > COBOL programs with invalid data, and we do not recommend using ZONEDATA > with other than (PFD) as the sub option. We keep finding new ways that > older COBOL behaved differently than new COBOL with invalid data, and in > the case you mention we had a customer complaining that the example you > posted ABENDed with COBOL V4 but not COBOL V6 with ZONEDATA(MIG), so we > changed the code. The intention of ZONEDATA(other than PFD) is to mimic > COBOL V4, and this is a little bit of an ongoing process. We, of course, > NEVER used to test with invalid data (data that does not match the PICTURE > and USAGE) so this is a challenging job! > > The best way to go is to correct your programs and data to follow the > rules. > For example, we had a customer recompile all programs in an application > with COBOL V6.1, but they did NOT folow our 2-compile 2-test migration > process to find and clean up invalid data. The results o their regression > tests were OK, so they went into production! All was well until they moved > to COBOL V6.2 to compile with ARCH(12) and exploit z14. At that point they > discovered they had some invalid data processing that started causing new > ABENDs with Vector Packed Decimal instructions. > > I recommend cleaning things up before declaring migration to COBOL V6 > complete! > > 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 > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN