Viewing CCSID 1208 fields in ACS Run SQL Scripts.

[RDKells]

I have a field defined as char 32000 CCSID 1208; when viewing on the iSeries (STRSQL) it's fine, when viewing in run sql scripts it's gibberish.

I've tried casting it, changing the QZDASOINIT job CCSID and all that crap - can't get it legible.

I came across this thread here albeit the "resolutions" are for embedded sql rather than runsql scripts however I tried declaring a global variable as 1208, setting it to the field I want to see then viewing it and I get the same issue - which makes sense since as it's the same as just viewing a the 1208 field from the file.

My job is running as CCSID 37 - any insight greatly appreciated.

[RDKells]

As it was a temp file to just view the data set I changed the output file field to 285 and this fixed it.

[B.Hauser]

Are you really sure, your job is running with CCSID 37 and not CCSID 65535?
Did you try to explicitly set your ACS job to CCSID 37?

CL:CHGJOB LANGID(ENU) CNTRYID(US) CCSID(37);

Also double check whether the in your ACS connection the Translate CCSID 65535 option (Edit your Connection --> Translate --> Translate CCSID 65535

Birgitta

[RDKells]

When I did "change query attributes" I noted the job details and did a CHGJOB command on the QZDASOINIT job.

The "translate" option is not checked - are you saying it should be?

[RDKells]

Here's some screen grabaroonies (this is with "translate 65355" now on);

[Vectorspace]

It should not matter what CCSID the table column is in, iACS should be able to translate it - if the data in the column is actually in the CCSID the column says it is. Greenscreen does not translate (I think), which suggests that the text is actually in whatever CCSID your greenscreen job is in (probably CCSID 37)

field1208 is CCSID 1208
output1208 is CCSID 1208
therefore line field1208 = output1208 should copy the data without translating it

xml is CCSID *UTF8, which is the same as CCSID 1208.
So the output1208 = substring of xml_data should copy the data without translating it

So my question is, are you sure the data in xml is in CCSID 1208? Simply putting CCSID 1208 on the end of a definition does not guarantee that the data in it is formatted with the CCSID, only that it will be assumed to be CCSID 1208. If for instance you are reading an IFS file that has CCSID attribute 1208 then the program will assume it is 1208. But the data inside it is actually CCSID 37, it will still be interpreted as 1208 and so will be scrambled.

To confirm -if this is the case, query the data in greenscreen, both using "select field1208 from..." and "select hex(field1208) from...". Look at the first 5 or so characters, and compare them to their hex values, and confirm if the data is actually CCSID 1208 or not.
For example, the character A is hex C1 in CCSID 1208, but is hex 41 in CCSID 37.

If this is the case, then look at where the data in xml is coming from, because I suspect even though the definition has CCSID *UTF8/1208, it's actually not *UTF8/1208.

You can run your program in debug and look at the hex values of each variable to confirm at what point the data becomes wrong.