RE: New system CCSID recommendation -- MIDRANGE-L

Why is CRTPF rcdlen(xxx) an issue, versus creating a file with DDS or with 
SQL?

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





Bruce Vining <bvining@xxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
02/12/2004 02:10 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Fax to

Subject
RE: New system CCSID recommendation







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.





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