On 30 Jul 2013 15:48, carlo Lunghi wrote:
I'm encountering troubles in connecting with interactive SQL on V5R4
to a DB2 9.7 running on a linux box.
Can "troubles" be defined with error messages, or is the issue only
with what data is presented by the report writer? If the latter, is
there a specific example of the DDL and data [in hex code points] on the
DB2 LUW and what is the /trouble/ manifest in the DB2 for i SQL session?
Such a db has been defined as an external db.
The problem arises probably caused by the different CCSID on the two
machines, fixed at 65535 (?) on system i and set UTF-8 - 1208 at the
creation time of the db on the external db server.
I am unsure what should be the effect for a DRDA requester, for the
"default job CCSID", but be sure the User Profile has the correct
Language Identifier established so a desirable default job CCSID is
established if the user profile has CCSID(*HEX) [aka 65535; or either
value is resolved from the QCCSID system value per *SYSVAL].
I would like to understand how to change CCSID on system i not as
general configuration change but just for the current db2 session
only.
CHGJOB CCSID(desired_EBCDIC_CCSID_value) /* job level, not just SQL */
The best thing to do however, is to change each user profile to have
the appropriate CCSID. And then after investigating the actual and
potential ramifications, to change the system value to an appropriate
value to reflect the appropriate CCSID for any users not explicitly set;
CHGSYSVAL QCCSID to a value that likely should correspond to the chosen
QLANGID.
Could you please indicate to me any suggestion about the
criteria I have to follow ? Please note that the CHGJOB command does
not show the 1208 value in the list of allowed CCSID. Therefore it
seems that my customer has a system configuration problem. Any idea
how to fix it ?
The choice of CCSID 1208 for the other database, is probably a good
and versatile choice. However an IBM i DB2 [interactive] server-based
query access against that other server could be difficult, if the data
obtained from the other database is not compatible with the EBCDIC CCSID
of the job. IIRC, the /international/ EBCDIC CCSID 500 was typically
chosen to maximize support for [data of] European countries.
Ideally, irrespective of the system value QCCSID, each user profile
will have their CCSID set appropriate to their language [or reflective
of their cultural locale; e.g. reflecting the language of the country in
which the system and the user both reside]. There should be no reason
for a request to CHGJOB to set the CCSID, because it would be
established when the user signs-on to the system, and is used in the
non-interactive jobs established under that user.
A client-based 'job', such as a web browser or client application
accessing the DB2 for i database via ODBC or JDBC via a server job, for
which its [interactive] report\display feature is enabled for UTF8 would
not have the same limitation as a requester local to the EBCDIC server.
Of course then a natural question is, why would the connection be
directed to the DB2 for i to redirect to the DB2 LUW, if it might just
as easily go directly against the latter.
The complete data [i.e. if any outside of support in the chosen
EBCDIC CCSID] can be retrieved instead as UTF8 or UTF16 if CAST as such,
for use in a manner other than displayed\printed reports via the report
writers; i.e. the applications local to the EBCDIC server can deal with
the data properly, but the local EBCDIC report writer is going to have
to translate the data to EBCDIC for presentation.
midrange.com
