|
midrange.com
It is indeed a matter of evolution. Before CCSID support was introduced
the system basically worked as if everything was 65535 -- that is, all
character data was treated as unchanging hex values. With the introduction
of CCSID support the system could now automatically convert a given hex
value in one CCSID to an appropriate hex value in another CCSID (to retain
character integrity) but would we want the system to do that by default?
Probably not. Anyone who was already doing their own character conversions
would be "broken". Anyone using constants ('a' = active, 'd' = deleted,
'#' = number for comparision within an application program to a constant,
etc.) would be "broken" (lower case 'a' is not fixed, '#' as many people
know moves all over the place, and so on). And of course the system would
have to "guess" as to what CCSID the data is encoded in as we have no way
of knowing what terminal (and related CHRID) put the data in the file to
begin with. Changing the system value to a non-65535 value would basically
cause these types of conversions to start taking place and people who
"changed nothing" other than putting on a new release would find their
applications no longer working. Not good. So the default QCCSID system
value is 65535 (pretty much everywhere).
This however causes problems with working with other systems as 65535 gives
no clue as to the encoding of the data. So the system introduced the
concept of a job default CCSID back around V3R1. Basically a way for the
system to make an educated guess as to the encoding of data, based on the
job language id, when the job CCSID was 65535. This job default CCSID is
what does change around the world based on the language ID in effect
(either at the system level with QLANGID which is set based on the National
Language Version installed or the job level). But this really doesn't fix
up everything either. It does do a good job when you have externally
described files and so the system "knows" which record data is character;
but for program described file there's no good way for the system to know
what's packed, binary, hex, character, etc. and so this is still treated as
65535 (as you sure don't want CCSID conversions to take place on
non-character based data). And program described includes things like S/36
files, spooled reports copied to a database file created with crtpf
rcdlen(xxx), etc. It is these types of program described files that tend
to be the problem areas these days...
I guess the net, from my point of view anyway, is that changing the default
of QCCSID from 65535 can be a very dangerous thing for the system to do as
it is one very big switch (or it can be a no brainer if you have one
system, all users have the same terminals, languages, etc.). But is
something that a user needing to support multiple languages will want to do
once they realize what supporting multiple languages means. And something
a user needing multilingual support can slide into by setting CCSIDs/CHRIDs
appropriately in jobs, display files, panel groups, databases, etc.
If you indeed have a new system, I would certainly consider setting QCCSID
to a non-65535 value. But I would also check with all of my software
providers to make sure that they can tolerate CCSID conversions by the
system (see my first paragraph).
Bruce
"Urbanek, Marty"
<Marty_Urbanek@sterc To:
"'midrange-l@xxxxxxxxxxxx'" <midrange-l@xxxxxxxxxxxx>
omm.com> cc:
Sent by: Subject: RE: New system
CCSID recommendation
midrange-l-bounces@m
idrange.com
02/12/2004 12:18 PM
Please respond to
Midrange Systems
Technical Discussion
Chuck,
I didn't really press for an answer to why it is the default. I really
don't
fault IBM for that. I think it is just a matter of evolution. If you look
at
the many years that OS/400 has been defaulting to 65535 (for US machines
anyway) compared to the time that these kinds of things (java, unicode,
JDBC/ODBC) have been an issue in the OS/400 application world, I just
figure
it's either:
1 - they haven't got around to it yet and/or not enough customer pain
2 - it would hurt more people than it would help
3 - they figure the people working on those kinds of things would figure it
out
Heck, for all I know there may be a whole section in the planning doc that
tells you to consider this, but I've not read it (at least recently). As I
understand it, the rest of the world (isn't there something outside the
US?)
doesn't default to 65535, so to those that have always had to face
character
conversion issues this is nothing new.
Plus, there are other places you can change the CCSID (other than QCCSID)
so
maybe they figure it is up to us dumb users to determine the best approach
for whatever we are trying to do.
-Marty
------------------------------
date: Thu, 12 Feb 2004 12:22:39 -0500
from: "Chuck Lewis" <clewis@xxxxxxxxxx>
subject: RE: New system CCSID recommendation
Marty,
That is INCREDIBLE ! So WHY THE HECK are they defaulting it to that ? They
didn't have an answer ?
Our new 810 (installed in September 2003) is set to 65535.
And so is the old 620...
Chuck
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
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.
