The following is an email that I sent to our iSeries programmers...
I am sure you have noticed the parameter referring to CCSID on many
commands that we have used. I don't know about you, but I have
conveniently ignored it - 'cuz it didn't have anything to do with
ENGLISH...Right? Well, WRONG.
This is now coming back to bite us. At this point it seems to be
associated with two commands: CPYTOIMPF and CPYFRMIMPF. IBM has "let us
get by" up until now, and now the time has come that they are tightening
up the thumbscrews.
The CCSID that we have been using as default is 65535. Unfortunately,
this has no meaning in the current method of doing things. The number
that seems to be the "standard" for English is 37. I have changed the
default CCSID to 37 on all ORNT AS/400s.
The CCSID is applied at the FIELD level, and appears to relate primarily
to character fields. I created a listing of fields that have 65535 as
their CCSID. Got 39 pages of field names. That works out to about 2145
field names.
In order for the two commands to work, these field names IN THE FILES WE
ARE EVER GOING TO USE in this way, need to be changed to have a CCSID of
37. This can be done either by changing the DDS...which requires a
recompile of the physical, which involves saving and restoring data...
Or can be done in place using the ALTER TABLE SQL command. Brenda has
had to do this, and the following is the command as she used it, with
her note:
Alter table mtilib/apu084w Alter Column dvname set data type character
(25) CCSID 37
Alter table mtilib/apu084w Alter Column dcocode set data type character
(4) CCSID 37
You have to say character length even though it is already defined or
you get a character field of 1.
Brenda has only changed the files on MT470. So, keep this information in
mind for the future.
Dave
612-371-1163
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Lim Hock-Chai
Sent: Wednesday, April 04, 2007 4:35 PM
To: Midrange Systems Technical Discussion
Subject: V5R2 --> V5R3 CPYFRMIMPF and CPYTOIMPF
We have quite a few programs that use these 2 commands. Does anybody
know what I need to do to make sure those programs will still work
correctly after upgrade from V5R2 to V5R3?
CPYFRMIMPF and CPYTOIMPF command changes No conversion performed if
TOFILE field has no CCSID or a 65535 CCSID In prior releases, the
CPYFRMIMPF and CPYTOIMPF commands would create a temporary database file
when copying a stream file to a database file. The temporary file was
created with CCSID(*JOB). The temporary file was used as an intermediate
file that the stream file was copied to before the import file text was
processed and copied to the target database file. Any input stream file
text was converted to the job's CCSID when the stream file was copied to
the temporary database file. If the target database file (TOFILE
parameter) field did not have an explicit CCSID or had a CCSID of 65535,
the copied import file text would remain in the job's CCSID because it
was already converted when the import file was copied to the
intermediate, temporary database file. In V5R3, when the CPYFRMIMPF and
CPYTOIMPF commands copy an import file from a stream file to a target
database file, an intermediate database file is not used. If the TOFILE
field does not have an explicit CCSID or has a CCSID of 65535, no text
conversion will occur and the database file will contain the same
hexadecimal code points that existed in the original stream file. If you
need the text in the import file to be converted from the original
CCSID, make sure that the TOFILE field CCSIDs are specified and are not
65535. For additional information on ways to handle CPYFRMIMPF and
CPYTOIMPF command changes in V5R3, please refer to Informational APAR
II13784.
--
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.
midrange.com
