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 <
[email protected]> 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 <[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
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
