>And if calling C/C++ from COBOL programs, be aware of the 00A/S0CA issue. >Since COBOL truncates high-order by nature, the "don't bother with exception >for this" bit is set for COBOL programs. However, for COBOL calling C/C++ (or >using a DLL) the bit is "on".
>If unhandled overflow occurs in the COBOL program thereafter, LE will spend >some (noticeable) time ignoring it, because it comes from COBOL. >If you add C/C++ function-usage to a COBOL program and get an otherwise >unexplained increase in CPU usage, look to overflow from calculations. >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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
