We have this "technique" as well. Interestingly, at least the last time I
checked, it still works (causes the S0C7) if the packed decimal field is signed
(PIC S9), but not if its unsigned (PIC 9).
What is the fix? When was it released?
-Original Message-
From: IBM Mainframe Assembler
Interesting side effect:
A previous employer's programmers used to force a dump by adding 1 to a
character field (redefined as packed).
Comes Cobol 5, and no more S0C7 abends, and MANY transactions that did half
their updates, and did NOT get rolled back.
They nagged IBM into providing a fix (maybe
>Only the back-end optimization routine can tell you that for sure, and it
>isn't talking. Remember though, that back end is reportedly shared with the
>Java JIT back end, and is supposed to be "very knowledgeable" about the
>fastest way to run code on a given architecture level.
I'm not doub
Let's think about the old way and the new way:
Old Way:
L Rx,BinaryVariable
CVD Rx,WorkDblWd
UNPKZoned_Decimal_Target,WorkDblWd
* And then fix the sign nibble for unsigned target with (perhaps) OI
target+length-1,X'F0'
New Way:
L Rx,BinaryVari
Out of curiosity.
I see that Cobol V5.2 (and up) is making use of decimal floating point
instructions instead of traditional instruction a lot. For example, a MOVE from
a binary number field to a character field is done with CZXT decimal floating
point instruction.
Is the performance of floa
