Re: Cobol and decimal overflow overhead (was: Data/hiperspaces)

[Bill Woodger]

On Wed, 5 Apr 2017 13:09:53 +0200, Peter Hunkeler  wrote:

>>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.
>
>
>Yes, we have made good progress. I think I had posted something about the 
>outcome earlier. Anyway, here is a short summary: Smart/Restart is using ESPIE 
>and ESTAE to gain control in error situations. This is not compatible with 
>LE's usage of ESPIE and ESTAE. For the non-problem 00A program check 
>interruptions from Cobol code, LE was not gaining control first, so LE could 
>not let the program continue. Smart/Restart did not recognize the 00A from 
>Cobol *not* to be a problem, but was acting as if a real problem had occurred. 
>The vendor has supplied a intermediate fix, and are in the process redesigning 
>Smart/Restart Error handling so it no longer interferes with LE.
>
>
>
>
>> 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.
>
>
>I was surprised, too, when I found out.
>
>
>>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".
>
>
>
>You don't have to think as long as this is valid Cobol. The compiler and 
>runtime should handle this behind the scene. The bad thing about the 00As is 
>that firstly, the newer compiler seem to generate code that may cause a 00A 
>more often. Secondly, the decimal overflow mask in the PSW seems to become set 
>ON more often than before due to changes in the LE runtime. Finally, it may 
>have a severe performance impact if the overflows occur often due to the 
>program logic.

Well, there is valid COBOL, which it is, and there is the thinking. At times, 
many times, mostly, one-size-fits-all means extra processing for 99.99% of 
usage.

Things always (did I really say always?) work "better" if sizes are the same, 
and where the "source" size is the best fit for the business requirement (so 
the advice is not to make all the data have 18 decimal places just so the MOVE 
works better...).

With up to V4, it was possible to be accurate with expectations of what code 
would be generated, with knowledge of compile options, and to a greater or 
lesser extent, depending on skill and interest.

With V5+, multiple ARCH possibilities, several new compiler options which 
affect generated code, three levels of optimisation (only one with up to V4, 
and even OPT(0) with V5+ does some optimisations), potential use of an 
additions 600+ instructions and the possibility that the same code can be 
optimised in different ways in the same program, it is... less easy... to know 
what will be generated, but will (should) still be the case that thinking about 
data-definitions and code will give benefits.

Yes, I agree, an increase in the number of things which can get 00A, coupled 
with an increase in the likelihood that the overflow mask bit is on, is 
something for concern due to LE chewing up cycles to decide nothing needs to be 
done.

You could raise this on IBM's Compiler Cafe: COBOL Cafe Forum. There's a couple 
of developers from Markham who keep an eye open there. Or just raise it with 
IBM.

>
>
>
>> 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").
>
>
>
>I agree, but I do not know why the programmer chose to define it that way in 
>this case.
>

Can't be sure, but I suspect it was a "no brainer", in the wrong sense.

>
>
>> 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?
>
>
>
>You made me curious, so I tried with V9(6), V9(8), V9(9), and V9(10). 
>Interesting. Different instruction sequence is generated for each case. The 
>SRP is found for the last one, but not for the first three.
>Anyway, we cannot ask the programmer to look at the pseudo assemble listing to 
>decide it the Cobol code is reasonable, can we :-)
>

Well... it needs "management support" at times, but if a particular way of 
doing things is "local standard", and that has... issues... then those standard 
methods should be reviewed by someone who can look at and make use of the 
listing of the generated code. And even inspire others to have an interest...

>
>> I've no idea what IZGFCPC 

Re: Cobol and decimal overflow overhead (was: Data/hiperspaces)

[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.


Yes, we have made good progress. I think I had posted something about the 
outcome earlier. Anyway, here is a short summary: Smart/Restart is using ESPIE 
and ESTAE to gain control in error situations. This is not compatible with LE's 
usage of ESPIE and ESTAE. For the non-problem 00A program check interruptions 
from Cobol code, LE was not gaining control first, so LE could not let the 
program continue. Smart/Restart did not recognize the 00A from Cobol *not* to 
be a problem, but was acting as if a real problem had occurred. The vendor has 
supplied a intermediate fix, and are in the process redesigning Smart/Restart 
Error handling so it no longer interferes with LE.




> 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.


I was surprised, too, when I found out.


>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".



You don't have to think as long as this is valid Cobol. The compiler and 
runtime should handle this behind the scene. The bad thing about the 00As is 
that firstly, the newer compiler seem to generate code that may cause a 00A 
more often. Secondly, the decimal overflow mask in the PSW seems to become set 
ON more often than before due to changes in the LE runtime. Finally, it may 
have a severe performance impact if the overflows occur often due to the 
program logic.



> 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").



I agree, but I do not know why the programmer chose to define it that way in 
this case.



> 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?



You made me curious, so I tried with V9(6), V9(8), V9(9), and V9(10). 
Interesting. Different instruction sequence is generated for each case. The SRP 
is found for the last one, but not for the first three.
Anyway, we cannot ask the programmer to look at the pseudo assemble listing to 
decide it the Cobol code is reasonable, can we :-)


> 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?



IGZFCPC seems to be the runtime library routine used to do calculations for 
which the compiler cannot generate inline instructions. The COMPUTE is 
something like this:


COMPUTE A = ( ( B - C -D ) / D * 100 ) + E


where the variables are COMP-3 and CONP-2 fields.
--
Peter Hunkeler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Cobol and decimal overflow overhead (was: Data/hiperspaces)

[Bill Woodger]

On Tue, 4 Apr 2017 07:43:05 +0200, Peter Hunkeler  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