Am 26.08.2017 um 19:31 schrieb Peter Hunkeler:
Note that we're a COBOL shop, and COBOL allows operations that loose
significant digits in numbers. This causes troubles when the decimal
overflow program mask is set, which it is if C code is also part of
the application (implicit or explicit).
- If you run with TRAP(ON,NOSPIE), then your own ESTAE must recognize that an
S0CA ABEND from a COBOL statement is *not* a problem, and your code must resume
the COBOL code. Not easy, believe me.
In addition, this may become a total performance killer. Assume, (and we have
seen sucht jobs) that a COBOL program has some code that causes decimal
overflow (loosing significant digits). This is intentional, and proper COBOL
coding. Assume such an overflow happens thousands of times during the batch
run. Further, C code is also involved, so the decimal overflow program mask bit
is set.
The result: COBOL code causes thousands of decimal overflows (00A program
checks). There is no ESPIE, which can handle this with a short path length. ...
We had similar problems in the 1990s.
Our insurance applications, written mostly in PL/1, used the 0CA and 0C8
program
masks, so that decimal and binary overflows didn't go undetected.
This worked fine, even with C modules called.
But suddenly, in the 1990s, a C compiler version arrived, where certain
operations
(like modulo) were implemented using arithmetic left shifts, which led
to 0C8 abends,
if the 0c8 mask bit is set. Of course, the 0C8 mask bit was never set in
a pure C environment,
but in our environment involving PL/1 FIXEDOVERFLOW, it was.
Instead of repairing the C code generation (which would have been
natural from my point
of view, given the fact that the previous C compiler did it right), IBM
did two things:
- first they discussed with us, that it is not OK to set the
FIXEDOVERFLOW condition, when
calling C from PL/1
- and then they changed LE, so that the 0C8s are handled by the LE error
handler,
which is a performance nightmare.
Because we have interface modules, that get control between each
(external) call between
two modules, and the interfaces know about the programming languages of
caller and callee,
we decided to switch off the 0C8 mask bit there, and to restore it, when
returning to PL/1.
Kind regards
Bernd
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
