CODEWITHSUNDEEP
ibm-midrange
Susmitha
Susmitha

Reputation: 93

'@' displays differently in two different ibm servers(AS400)

I am trying to generate xml in two different iseries servers. Both the servers has same CCSID. But when xml gets framed, '@' character is getting converted to some other character. In the other server, it is displaying correctly. Both the servers are in same PTF level and even the java version is same for both servers. What might be the difference between the servers? How can i check the difference? Why '@' is getting converted to some other character, that too in only one server?

Upvotes: 0

Views: 241

Answers (1)

jmarkmurphy
jmarkmurphy

Reputation: 11473

This sounds like a CCSID problem.

tl;dr
CCSID is stored in more than one place on IBM i, and depending on where the data is coming from, you could have a number of places to check.

System Value - QCCSID is the system default CCSID, but it only comes into play in certain circumstances, so yes they should be the same, but it is not the whole story. Note that many systems that have been around a long time have QCCSID set to 65535.

Job CCSID - Each job has it's own CCSID which defaults to the system CCSID, but can be modified by the user profile or the SBMJOB command. But that is not the entire story for CCSID in a job. If the Job CCSID is 65535, then the job default CCSID is set based on LANGID. For my system LANGID is ENU, and the Job default CCSID is 37.

Database - Each database table has a CCSID specified. For DDS, that is specified in the CRTPF command, for SQL, the Job default CCSID is used. In addition each character data column can specify it's own CCSID.

Device files - Like the database file, device files can specify their own CCSID, both at the file level and at the field level.

The problem is that the @ character is not part of the invariant character set so it can be displayed differently in different CCSID's particularly if you have CCSID 65535 in the mix. 65535 means no conversion. You need to make sure that CCSID are the same across the board, and if 65535 is in there, that they are all consistent with each other.

Final note on CCSID 65535. It is a holdover from the days when there was only a single language on the system. At that time there wan no problem associated with non-conversion of character sets because everyone using the system spoke the same language. These days with systems connected every which way, and data being shared with PC's and the web, CCSID becomes a big deal because even if everyone on the system speaks the same language, you can still encounter multiple CCSID's due to PC's, the IFS, XML, Unicode, etc. It is probably best that your system CCSID be set to something other than 65535.

Upvotes: 3

Related Questions