|
View previous topic :: View next topic
|
| Author |
Message |
anettis
New User
Joined: 25 Mar 2009
Posts: 5
Location: United States
|
|
|
|
Hi - I recently looked at a CICS transaction abend of a COBOL program running under CICS. I am looking at this from a machine instruction point of view and trying to understand what is happening. I don’t see how this could be causing an overflow based on the field sizes involved. Here is some of the information provided by Fault Analyzer:
------------------------------------------------------------------------------
A program-interruption code 000A (Decimal-Overflow Exception) is associated
with this abend and indicates that:
One or more nonzero digits were lost due to the destination field being too
short to contain the result of a decimal operation.
The abend was caused by machine instruction FA4421DE2D4B (ADD DECIMAL).
Recently referenced data items:
Data Item . . . . . . . . : BLL=0008+1DE
At Address. . . . . . . : 111A66CC
Length. . . . . . . . . : X'5'
Data Item Storage . . . : 05763985 7C *...e@*
Data Item . . . . . . . . : BLL=0008+D4B
At Address. . . . . . . : 111A7239
Length. . . . . . . . . : X'5'
Data Item Storage . . . : 06058245 6C *..b.%*
------------------------------------------------------------------------------
OK the machine instruction is: FA4421DE2D4B
The assembler equivalent is AP 478(5,R2),3403(5,R2)
Now a little packed decimal arithmetic:
05 76 39 85 7C
06 05 82 45 6C
---------------------
11 82 22 31 3C
I checked the TACB in the transaction dump and R2 = 111A64EE
111A64EE + 1DE = 111A66CC data item 1
111A64EE + D4B = 111A7239 data item 2
Adding the above values together should not cause a decimal overflow for 5 byte Packed Decimal field. I am scratching my head. Any thoughts? |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
| What do the variables look like in the original source language (PL/I or Assembler)? |
|
| Back to top |
|
|
anettis
New User
Joined: 25 Mar 2009
Posts: 5
Location: United States
|
|
|
|
Hi - they are COBOL:
W87-VNDR-DOLLAR-PURCH-PTD-C
PIC S9(7)V9(2) COMP-3.
M03-VNDR-DOLLAR-PURCH-PTD-N
PIC S9(7)V9(2) COMP-3.
They seem to correspond to two packed decimal 5 byte fields referenced by the AP instruction. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
You posted a COBOL program issue in the PL/I & Assembler area?
The COBOL Programming Guide has an entire Appendix devoted to intermediate results and how they work. But fortunately in this case the entire Appendix is not needed.
You add PIC S9(7)V99 to PIC S9(7)V99 and get 8 digits before the decimal in your result. This is called "decimal overflow" and it is the programmer's responsibility to ensure the field is large enough to contain the result, use ON SIZE ERROR to trap the problem, or expect the overflow condition whenever the two values add up to more digits than the PICTURE clause. From the Programming Guide:
| Quote: |
1.13.3 Handling errors in arithmetic operations
The results of arithmetic operations might be larger than the fixed-point field that is to hold them, or you might have tried dividing by zero. In either case, the ON SIZE ERROR clause after the ADD, SUBTRACT, MULTIPLY, DIVIDE, or COMPUTE statement can handle the situation.
For ON SIZE ERROR to work correctly for fixed-point overflow and decimal overflow, you must specify the TRAP(ON) runtime option.
The imperative statement of the ON SIZE ERROR clause will be performed and the result field will not change in these cases:
* Fixed-point overflow
* Division by zero
* Zero raised to the zero power
* Zero raised to a negative number
* Negative number raised to a fractional power |
You break the rules, you gotta expect the results you get. |
|
| Back to top |
|
|
anettis
New User
Joined: 25 Mar 2009
Posts: 5
Location: United States
|
|
|
|
Hi Robert. I appreciate the response. However the reason I put this in the assembler section is that I was looking at this from the perspective of the failing machine instruction:
FA4421DE2D4B
or the assembler equivalent of:
AP 478(5,R2),3403(5,R2)
In this respect I still believe my post was correctly positioned in the most appropriate forum i.e. assembly language. I fully realize you can use an ON SIZE ERROR in COBOL to trap this sort of thing. But my outstanding question remains why an Add Packed machine instruction appears to fail with a SOCA when it does not appear that an overflow condition was raised. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| But my outstanding question remains why an Add Packed machine instruction appears to fail with a SOCA when it does not appear that an overflow condition was raised. |
Because COBOL generates the decimal overflow, not assembler. COBOL checks for overflows during arithmetic operations, so if the code was running under Assembler, there would be no decimal overflow. Running under COBOL there will be because 8 digits before the decimal won't fit into PIC S9(7)V99. And that's why you should have raised the question in the COBOL forum, not PL/I & Assembler. COBOL generates pseudo-assembler, not true assembler. |
|
| Back to top |
|
|
|
|
