|
View previous topic :: View next topic
|
| Author |
Message |
ScottUrban
New User
Joined: 23 Apr 2007
Posts: 50
Location: Jefferson City, Mo
|
|
|
|
A date in USA format mm/dd/ccyy being selected off of a DB2 Table and then moved as is to an S9(8) comp-3 field did not cause an Abend. It shows up in the S9(8) comp-3 field as the example shows below;
Moving this value 08/31/2007 and it shows as +13112007
I know the field has to be converted to take out the slashes prior to moving it but after I found this problem in ther program it got me curious. Any explanations would be a great help? |
|
| Back to top |
|
 |
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1042
Location: Richmond, Virginia
|
|
|
|
| Seeing exact code and hex value of a DISPLAY would certainly help. |
|
| Back to top |
|
|
ScottUrban
New User
Joined: 23 Apr 2007
Posts: 50
Location: Jefferson City, Mo
|
|
|
|
END-STMT-DA PIC x(10) From DB2 table USA format 08/31/2007
WS-COMPARE-SETTLE-DA PIC S9(8) COMP-3
MOVE END-STMT-DA TO WS-COMPARE-SETTLE-DA
Results in HEX it appears to be converting X'61' to the number 1
| Code: |
02 END-STMT-DA
08/31/2007
FF6FF6FFFF
0813112007 |
| Code: |
02 WS-COMPARE-SETTLE-DA
....@
03107
1120C |
|
|
| Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1042
Location: Richmond, Virginia
|
|
|
|
It's not so much converting x'61' to 1 as just taking the rightmost nibble '1' and ignoring whatever is in the leftmost nibble. Since it is moving char to numeric, it "knows" that the digit value must be in the rightmost nibble: F0, F1, F2, .... One would sort of hope that this move would fail, as it contains junk, but COBOL just does the best it can.
My test LPAR is having upgrades today, so I cannot test in COBOL till Monday. |
|
| Back to top |
|
|
ScottUrban
New User
Joined: 23 Apr 2007
Posts: 50
Location: Jefferson City, Mo
|
|
|
|
| Thanks, Makes sense.... I would think it would have received a S0C7 but I guess Cobol is attempting it's best guess at what the move was suppose to accomplish.. (which is kind of scary.....) |
|
| Back to top |
|
|
ScottUrban
New User
Joined: 23 Apr 2007
Posts: 50
Location: Jefferson City, Mo
|
|
|
|
let me know what you find out on Monday....
Thanks again, |
|
| Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1042
Location: Richmond, Virginia
|
|
|
|
No S0C7 because you are not doing arithmetic. Try moving any string of chars to a packed dec field and see what happens. Might as well try moving also to a COMP (binary) field.
Note that COBOL also fails to notify if it drops the left end of a longer source field - that's happening here, too. |
|
| Back to top |
|
|
mmwife
Super Moderator
Joined: 30 May 2003
Posts: 1592
|
|
|
|
Hi Phil,
As I recall, moving to a COMP-3 field does do arith. A ZAP (Zero and Add Packed) assembler instr really does the "move" into the receiving field.
In Scott's case here, the conversion produces a valid packed field (in spite of the "/"s) and therefore no 0C7 occurs. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
To add to Jack's Excellent info, I believe different assembler may be generated depending on the fields.
In the case from this post, i'm fairly sure it will generate a ZAP instruction.
If the 2 fields were both the same length comp-3, i suspect an MVC would be generated as a "move" executes faster than the ZAP. |
|
| Back to top |
|
|
mmwife
Super Moderator
Joined: 30 May 2003
Posts: 1592
|
|
|
|
| Quote: |
| To add to Jack's Excellent info... |
You're a quick study dick.... heh heh heh.
PS. In my prev post I changed
| Quote: |
| moving a COMP-3 field does do arith |
to the following:
| Quote: |
| moving to a COMP-3 field does do arith |
|
|
| Back to top |
|
|
|
|
