|
Hi Eric, I didn't pay enough attention to your end goal. My first response should work in the sense of changing the job and so on, but I agree with Franco that you may end up with unexpected results and generate a lot of future work for yourself. If your goal is to be able to handle any character set, the best ( depending on your definition of "best" ) is to use Unicode in the file/table. As of V5R3, UTF-8 is supported, which gets rid of most space concerns. There are other possible options like getBytes() and binary streams, but Unicode is the cleanest and you can even use one table for everything if that fits your project. I was confused by this: > My problem is that I will need one application to write to different files > with different CCSIDs. What should be happening is that the DBMS ahould handle the conversion to and from the table CCSID and job CCSID. Of course, I don't know what your code is doing or how you have your tables set up. Joe Sam Joe Sam Shirah - http://www.conceptgo.com conceptGO - Consulting/Development/Outsourcing Java Filter Forum: http://www.ibm.com/developerworks/java/ Just the JDBC FAQs: http://www.jguru.com/faq/JDBC Going International? http://www.jguru.com/faq/I18N Que Java400? http://www.jguru.com/faq/Java400 ----- Original Message ----- From: "Eric Lee" <Eric.Lee@xxxxxxxxxxxx> To: "Java Programming on and around the iSeries / AS400" <java400-l@xxxxxxxxxxxx> Cc: "Java Programming on and around the iSeries / AS400" <java400-l@xxxxxxxxxxxx>; <java400-l-bounces@xxxxxxxxxxxx> Sent: Monday, February 28, 2005 12:44 PM Subject: Re: setting CCSID of QZDASONIT jobs > Hi Franco, > > I don't think I can use a particular LANGID because I need to be able to > write to the file with no conversion > taking place as I do not necessarily know what language the user is going > to be using. (It's a web app) > > My problem is that I will need one application to write to different files > with different CCSIDs. > > When I try to use a CCSID other than 65535, some characters may not be > found > in the CCSID table and these seem to get written out as hex 3F which > consequently > causes other problems. > > I did try changing the LANGID of the user profile but I think this was > overriden by the CCSID of the user > profile UNLESS it was 65535, in which case the QZDASOINIT job did seem to > get the CCSID for that > particular LANGID. eg. if LANGID was set to SVE then it would set the job > to 278 + Swedish. > > Best regards, > Eric Lee > DCS Transport & Logistics Solutions > > > > > Franco Biaggi <fbiaggi@xxxxxxxxxx> > Sent by: java400-l-bounces@xxxxxxxxxxxx > 28/02/2005 16:51 > Please respond to > Java Programming on and around the iSeries / AS400 > <java400-l@xxxxxxxxxxxx> > > > To > Java Programming on and around the iSeries / AS400 > <java400-l@xxxxxxxxxxxx> > cc > > Subject > Re: setting CCSID of QZDASONIT jobs > > > > Hi, > basically its wrong that you use this CCSID, the system cannot translate > to a client application, you may see other related problems. > Java on AS/400 "seem" to use the LANGID variable to make the conversion. > > Hope this helps- > > Eric Lee wrote: > > >Hi All, > > > >I need to set the ccsid of the QZDASONIT job started by a JDBC connection > > >to 65535. > > > >I've tried changing the ccsid of the iSeries user profile that the JDBC > >connection uses - but that does not work > >with 65535 - it takes the sysval if you try to use 65535. (The ccsid of > >the qzdasonit job is set correctly if you use another value that forces > >conversion) > > > >Does anyone know of another way I can achieve this (without changing the > >sysval)? > > > >My problem is to do with the jobs writing a hex '3F' for certain accented > > >characters which is causing problems when the character is read in. > > > >When the job is 65535 - (when I change the job's ccsid manually) the > >characters are written with a valid hex code. > > > >Best regards, > >Eric Lee > >DCS Transport & Logistics Solutions > >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.