Mr Monk, I agree with you 100%....and I wish everyone was on the same page....but that’s fantasy world talking. The reality is that each data center believes that they are doing things properly...even within the same company. And each site has totally different schedules as to when software upgrades occurs, maintenance occurs or who gets upgraded box. Some sites lease their boxes and equipment, some own it...so when a contract is up comes into play or might even be a site that IBM runs compared to a site that we run...then you have Endeavor at some sites, others PDSMAN or just god old PDS's. Just keeping everyone or trying to insure everyone is using the same compiler options is a chore.
But still each box generates different code from compiler...and it stinks when you get the stink eye when your change blows up and you keep claiming that you tested it....unfortunately sometimes you get some bosses that aren’t mainframe savvy and things suffer. Thanks, Tom -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Joe Monk Sent: Saturday, March 13, 2021 6:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: EXTERNAL: COBOL V6.2 possible change in behavior with recent patch level I used to write code for and maintain the code base of a Pension and 401k accounting system written in COBOL ... we ran at the top 6% of the banks in the USA. The way you fix your problem is you have support levels. Yes there are tons of customer with different compiler levels. BUT your company, as an organization, can have a minimum support level... Z13? OK cobol 6.2 patch level such-and-such is required to run our software. Z14? OK cobol 6.2 patch level such-and-such is required to run our software. 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 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
