|
View previous topic :: View next topic
|
| Author |
Message |
ymfdev
New User
Joined: 17 May 2010
Posts: 10
Location: India
|
|
|
|
Hey all,
Newbie here. Here is my query.
My program retrieves fields from DB2 and converts them into UTF8 to put into a file.
However if i convert the data back from UTF8's CCSID 1208 to EBCDIC CCSID 500 i am losing some spaces.
Here is an example:
Before To UTF8 conversion:
| Code: |
Französisch location 100
|
After UTF8 to EBCDIC conversion:
| Code: |
| Französisch location100 |
Note that "Französisch location" is from a single field in the DB and 100 is from another field from the DB.
As you can see, i am losing the extra space which is supposed to be in the file after location but upon reconverting back from UTF8, the space is not there. This happens only when the german characters are encountered in the record.
Please let me know what can be done to resolve this.
Any other CCSID other that 500 that would be helpful in this case?
Thanks
Y. |
|
| Back to top |
|
 |
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
how was
| Code: |
Französisch location 100
|
displayed for this cut&paste?
And how was
| Code: |
| Französisch location100 |
displayed for this cut&paste? |
|
| Back to top |
|
|
ymfdev
New User
Joined: 17 May 2010
Posts: 10
Location: India
|
|
|
|
CICS Guy,
It was displayed as such.
Actually the 100 ought to start after a space but it doesn't. When the conversion from UTF8 to EBCDIC is done, the space is lost due to the double byte character ö in the first field, i guess.. |
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| ymfdev wrote: |
| When the conversion from UTF8 to EBCDIC is done, the space is lost due to the double byte character ö in the first field, i guess.. |
I think not....
Please post the display commands or explain the methods that the displays were generated.
Please use something more than "It was displayed as such". |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| Quote: |
| double byte character ö in the first field |
is not ALL UTF8 double byte character???
I would bet you will find that the problem does not lay with the conversion.
since the source of the data is actually two fields,
of which occaisionally
(from your observation, every time an umlat'ed letter is involved)
the space is lost from the first field/column,
I would double check the integrity of the data,
maybe the source of umlat'ed data is different from un-umlat'ed data
is this stuff coming out of varchar columns?
at this point I don't know what it is,
but what I know is
that it isn't based on the umlat. |
|
| Back to top |
|
|
ymfdev
New User
Joined: 17 May 2010
Posts: 10
Location: India
|
|
|
|
Okay,
Here goes..
For converting to UTF8 the following COBOL line was used:
| Code: |
| MOVE DISPLAY-OF(WS-VARIABLE, 1208) TO VARIABLE-X |
this VARIABLE-X was written to the output file.
For reconverting from UTF8 to EBCDIC, the following COBOL line was used:
| Code: |
| MOVE FUNCTION DISPLAY-OF(WS-VAR1, 500) TO VAR2-X |
this VAR2-X was written to another file.
So when "Französisch location 100" is converted to UTF8(1208), everything seems good..
But back from UTF8 to EBCDIC(500) - it is written as "Französisch location100"
This is my issue..
Is there any other CCSID other than 500 that i can use to get it back in the required one or i have to make some code changes when i convert it to UTF8 initially?
Thanks,
Y. |
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| dbzTHEdinosauer wrote: |
| I would bet you will find that the problem does not lay with the conversion. |
I'd bet the problem might lay in the difference between displaying the DB2 columns and the flat file.... |
|
| Back to top |
|
|
ymfdev
New User
Joined: 17 May 2010
Posts: 10
Location: India
|
|
|
|
dbzTHEdinosauer,
Any probable solutions that i can try here ???
CICS Guy,
Any best way to display DB2 DBCS values in flat files? |
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| ymfdev wrote: |
| Any best way to display DB2 DBCS values in flat files? |
How are you currently displaying the DB2 DBCS values and the values in the flat file? |
|
| Back to top |
|
|
ymfdev
New User
Joined: 17 May 2010
Posts: 10
Location: India
|
|
|
|
| CICS Guy wrote: |
| How are you currently displaying the DB2 DBCS values and the values in the flat file? |
I am not writing the retrieved fields as such in a flat file.
Converting the fields to UTF8 before writing into a file to be transmitted.
This file is input to another program to convert into EBCDIC, just for a cross check if the data is fine. But this issue crops up..... |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| ymfdev wrote: |
| Any probable solutions that i can try here ??? |
| dbz wrote: |
I would double check the integrity of the data,
maybe the source of umlat'ed data is different from un-umlat'ed data
is this stuff coming out of varchar columns? |
is the source of this data, actually first column, a varchar db2 column? |
|
| Back to top |
|
|
ymfdev
New User
Joined: 17 May 2010
Posts: 10
Location: India
|
|
|
|
Yes it is from a Varchar column.
Sorry i missed out your previous question on this.. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
I'll bet,
that the process of generating the varchar columns for the data that contained umlats,
was different that that of those columns which have no umlats.
but first, you have to verify your observance of the data,
and determine what the problem is.
I say that the length of the varchar column containing umlats,
is 1 less that you are expecting.
it is not long enough to include a trailing space.
whereas the columns that have values that do not contain an umlat,
have a length that includes a trailing space. |
|
| Back to top |
|
|
ymfdev
New User
Joined: 17 May 2010
Posts: 10
Location: India
|
|
|
|
I guess i cant go and modify the table in anyway.
Any workarounds to acheive a solution? |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
not sure how you are 'building' your data.
STRING or using the varchar length in a reference modification or index bump?
after every select, you have the varchar length,
check the last char (
if host-var-varchar-column-text(host-var-varchar-column-length:1) = space
then
continue
else
add 1 to host-var-varchar-column-length.
fixing the db2 table is a real problem.
depending upon howmany 'umlated' rows that you have vs total rows,
you either update the 'umlated' by adding 1
or update the rest by subtracting one.
if you add, figure you bumping data around, looking for more space.
but, fixing the db2 table is only half the problem.
the input process needs to be repaired,
but don't hold your breath.
you are going to have to determine in your module if the space is there or not. |
|
| Back to top |
|
|
ymfdev
New User
Joined: 17 May 2010
Posts: 10
Location: India
|
|
|
|
Yeah, i guess the building is done using STRING. The data has been built sometime ago.
I am not going to touch the DB2 table as its quite a tedious task i believe..
(and i am not supposed to touch it either, here  )
Let me try this in the cobol side... But something asks me "wat will happen when there are two or more DBCS characters???" |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
they are all dbcs in utf8 |
|
| Back to top |
|
|
|
|
