× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



RCDLEN(xxx) basically creates a program described file where the system has
no clue as to what type of data is contained in the record.  As the help
text indicates "The high-level language program that processes the file
must describe the fields in the record in the program".  With DDS and/or
SQL the system is told what fields/columns are character, what are binary,
what are packed, what are hex, what are float, etc. and so proper
conversion of character data can be performed.  Fortunately one can usually
use an externally described file in place of a program described (rcdlen)
file (so long as you do the descriptive work up front).

Bruce



                                                                                
                                                      
                      rob@xxxxxxxxx                                             
                                                      
                      Sent by:                    To:       Midrange Systems 
Technical Discussion <midrange-l@xxxxxxxxxxxx>           
                      midrange-l-bounces@m        cc:                           
                                                      
                      idrange.com                 Subject:  RE: New system 
CCSID recommendation                                       
                                                                                
                                                      
                                                                                
                                                      
                      02/12/2004 01:59 PM                                       
                                                      
                      Please respond to                                         
                                                      
                      Midrange Systems                                          
                                                      
                      Technical Discussion                                      
                                                      
                                                                                
                                                      
                                                                                
                                                      




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.


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


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.