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 <[email protected]> On Behalf Of Tom Ross Sent: Friday, March 12, 2021 11:45 AM To: [email protected] 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 [email protected] 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 [email protected] with the message: INFO IBM-MAIN
