|
View previous topic :: View next topic
|
| Author |
Message |
rikdeb
New User
Joined: 19 Jan 2009
Posts: 63
Location: hyderabad
|
|
|
|
Hi All,
Came across a piece of code in one program, where the program is taking user input from online screen and inserting the same in db2 table.
Now,the input field corresponding to the online map is defined as alphanumeric in cobol; say
| Code: |
| IPFLD-FID pic x(03). |
The corresponding column in db2, where this value will be inserted is defined as SMALLINT.
When numeric input is keyed thru online, the insertion is good as expected; but if character input is given(for testing purpose,which ideally should not be the case), i am seeing the value is getting changed to numeric and getting inserted. Ex: abc is getting converted to 123 and getting inserted.
Could you throw some light on this. |
|
| Back to top |
|
 |
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL
|
|
|
|
| Likely DB2 is stripping off the zones and interpreting the result as binary coded decimal. Do you really mean "abc", or did you mean "ABC"? |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3051
Location: NYC,USA
|
|
|
|
Its because of the collating sequence that has the values 0 through 9 .
| Quote: |
| but if character input is given(for testing purpose, which ideally should not be the case), i am seeing the value is getting changed to numeric and getting inserted. Ex: abc is getting converted to 123 and getting inserted. |
Raise a defect and ask to validate before inserting. |
|
| Back to top |
|
|
rikdeb
New User
Joined: 19 Jan 2009
Posts: 63
Location: hyderabad
|
|
|
|
Hi Rohit and Akatsukami,
Thanks for your help.Today i tried with both ábc' and 'ABC' .Both the cases it took the value 123. I was trying with random characters like xyz, and it took 789. I think as rohit said ,it is for the collating sequence 0 thru 9.
However i want to know more, how this actually works.I am looking for it in google, but if you have any more information, please pass on the same. |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL
|
|
|
|
You of course know that the characters (as well as everything else) are represented in memory and on mass storage as binary patterns. If you were to edit a data set using the ISPF editor, and set HEX ON, you might see something like this:
| Code: |
123 abc ABC xyz
---------------
FFF48884CCC4AAA
123012301230789
|
(Note that space is a character, and occupies one byte.)
The first line is glyphs (displayed or printed characters), one per byte. The third line is the high nybble of each byte, and the fourth is the low nybble.
The high nybble is called, for historical reasons, a "zone"; the three leftmost bytes is the example are "zoned decimal" (COBOL DISPLAY, PL/I CHAR or PIC). When converting to binary (COBOL COMP-5, PL/I FIXED BIN}, the code doing the conversion ignores the zones and interprets the low nybbles as decimal digits.
Knowing this (and EBCDIC mapping of glyphs to binary patterns), you can see why, if each of those three-character fields is moved to a binary field,
the value of the field will be 123, 123, 123, and 789, respectively. |
|
| Back to top |
|
|
rikdeb
New User
Joined: 19 Jan 2009
Posts: 63
Location: hyderabad
|
|
|
|
| Thanks a lot Akatsukami !. Indeed a vry nice & useful explanation. |
|
| Back to top |
|
|
|
|
