Re: The complete CCSID Q&A

Rob,

Changing QCCSID is not my main concern anymore... I do understand the implications of that (I guess).

The questions came from digging deeper into CCSID stuff... and got in doubt about QCHRIDCTL and CHRID on CRTDSPF.

Playing with these as well as the emulator and job CCSID I get varying results in what I see on my screen.

For example...
DSPF (CHRID *DEVD)
QCCSID 1148, Database 1148, Emulator 1148, Job 1148… data looks correct.
QCCSID 1148, Database 1148, Emulator 1148, Job 37… data looks NOT correct.
QCCSID 1148, Database 1148, Emulator 37, Job 1148… data looks NOT correct.
QCCSID 1148, Database 1148, Emulator 37, Job 37… data looks correct.

DSPF (CHRID *JOBCCSID)
QCCSID 1148, Database 1148, Emulator 1148, Job 1148… data looks correct.
QCCSID 1148, Database 1148, Emulator 1148, Job 37… data looks correct.
QCCSID 1148, Database 1148, Emulator 37, Job 37… data looks correct.
QCCSID 1148, Database 1148, Emulator 37, Job 1148… data looks correct.

With the first set of test, constants on the screen only show up correctly with emulator and job set at 1148 (using SDA they however look correct in other combinations as well)... in the second set of tests constants show up correctly always !

So why is *JOBCCSID not the default, is there any risk and why can't find any recommendation on it ?

Kind regards,
Paul
________________________________________
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> on behalf of Rob Berendt <rob@xxxxxxxxx>
Sent: Monday, January 21, 2019 16:32
To: Midrange Systems Technical Discussion
Subject: RE: The complete CCSID Q&A

Many of us have changed the system value QCCSID during the middle of the day with no ill repercussions.
Chuck Pence once published a concern with that but the list's archive searches are just not what they used to be and I cannot find that discussion.

Search this for QCCSID
https://www.ibm.com/developerworks/community/wikis/home?lang=en-gb#!/wiki/IBM%20i%20Technology%20Updates/page/CGI%20frequently%20asked%20questions

http://www-01.ibm.com/support/docview.wss?uid=nas8N1021732

https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/ddp/rbal1apendixqccsid.htm
<snip>
The default CCSID value in a user profile is *SYSVAL. This references the QCCSID system value. You can change the QCCSID system value that is used by all user profiles with the Change System Value (CHGSYSVAL) command. If you do this, you would want to select a CCSID that represents most (if not all) of the users on your system
</snip>

https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/nls/rbagsccsidgenrecom.htm


-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Paul Nicolay
Sent: Monday, January 21, 2019 10:04 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: The complete CCSID Q&A

Hi,


While the title maybe a bit misleading, I hope the final result will be more or less like that.


The facts, currently I see various systems at customer locations that still have QCCSID set to 65535 of which I know it is a bad thing so I'm trying to find out what the implication of changing this to a normal value is. In my investigation I found already a few things;


The database currently does have a (correct or at least a non-65535) CCSID so having QCCSID set to 65535 or not doesn't seem to make any difference as far as FTP and ODBC is concerned. This means the main issue is how screens handle the data (which indirectly impacts FTP/ODBC however by themselves they aren't the issue).


Setting the emulator codepage and/or job CCSID does have an impact on what I see, but this is again is impacted by whether the DSPF is compiled with CHRID(*DEVD or *JOBCCSID). While the last one is not the default, it however provides the best results, not only for database fields, but as well for constants on the screen (all my tests are based on just both the square brackets, ie. [] ) So the question is, should I change the compile option on CRTDSPF ?


This brings me to the next system value... QCHRIDCTL which is also set by default to *DEVD ? Would I need to change this one to *JOBCCSID (and change my CRTDSPF to CHRID(*CHRIDCTL) ?), or can this cause other issues. I already read some conflicting things about *JOBCCSID... some IBM documents say that panel-groups don't support it, others explicitely mention panel-groups ?


Whats facinates me is that when using CHRID(*JOBCCSID) on the display file it doesn't matter how my emulator is set, nor how the job is set... so I tested with 37 and 1148 but all four combinations show the data correctly for the database and the constants ? Using CHRID(*DEVD) there's only one combination, being emulator AND job set at 1148 to have everything correct ?


For people that use the default of *DEVD, I wonder how you make sure that every emulator in the company is set correctly as the smallest mistake results in corrupting your data. Would you check if the device codepage is different from the QCCSID value... and terminate the logon ?


Digging deeper and deeper in all this makes me only more confused... the question remains, what is the ideal setting of all this and why (or why shouldn't I use certain settings) ?


Thanks in advance,

Paul


PS. The 621 pages IBM i Globalization manual didn't help me !

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com