On Tue, 4 Apr 2017 07:43:05 +0200, Peter Hunkeler <p...@gmx.ch> wrote:
[...] > >>If unintended truncation, fix. If intended, do it in such a way as to not >>cause the overflow. > > >The last point is not always easy to achieve. The each compilers version or >release may generate different code using different instructions. > > >The following statements are valid Cobol code to extract the fraction part of >a decimal number: >... >77 Fraction PIC V9(18). >77 Decimal-Number PIC S9(9)V9(6). >... >MOVE Decimal-Number to Fraction. > > >Enterprise Cobol V4.2 generates code that will never cause a decimal overflow, >V5.2 will use SRP instruction, which will cause an overflow if >"Decimal-Number" is greater or equal to 1. > > >And worse, we just stublmed over IZGFCPC which is called as part of the code >generated for a non-trivial COMPUTE with the ON SIZE ERROR clause. IGZCFPC >does use SRP instruciton and may cause a decimal overflow. How would you avoid >this easily? > >-- >Peter Hunkeler > Firstly, Peter, I know you didn't write the code or come up with the idea of the definition of Fraction. Secondly, looks like you have some progress with your related topics from over the last few months. "If [truncation is] intended, do it in such a way as to not cause the overflow." The implication is to think about it, and achieve the truncation without overflow. I was making the point about calculations: I'm surprised a MOVE can cause overflow. The idea of the definition of Fraction is "hey, if we define it to the maximum number of possible digits, then we never need to think what we MOVE to it to get the decimal part of a number". My first point would be that having a "don't need to think" rule means what I suggest, which requires thinking, can't be done. Second point. V9(18). 18. Eighteen. If there is a commercial requirement for 18 decimal places, it will be a rare one. 18 digits happens to be horrible if much of anything is to be done with it. (If much of anything is to be done, changing it to 17 digits may reduce the code generated,hanging it to 15 digits may reduce it further. By "may" I mean "I'd be surprised if it didn't"). Third point. 9(9)V9(6) is pretty good for business purposes. Why, to get the fractional part, use anything other than six decimal places? (15 digits is nice, and even plenty for commercial treasury purposes in major currencies - and even the US GDP fits in with some to spare). (Even though 9(9)V9(6) is pretty good, I still far prefer specific sizes for specific cases). 01 Fraction PIC V9(6). 01 Decimal-Number PIC S9(9)V9(6). MOVE Decimal-Number to Fraction With that, I'd be hard put to imagine much more than whatever the compiler chooses for a six-byte MOVE - depending on compile options. What does V5.2 produce? I've no idea what IZGFCPC is. Search-engineing reveals your post and nothing else, except this one, some time later. Can you show the COMPUTE and the definitions of the fields it uses? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
