|
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
--
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
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.