Re: cpytoimpf issue - v6r1

AFaIK the job CCSID is used by the CPYTOIMPF only for treating the literals on the command, not for [overriding] the columns\fields of the database file. Thus the problem is presumably with how the file was created. That is, I expect that the "temporary file" noted was created as a program-described file [e.g. CRTPF RCDLEN(specified) or BLDFILE], which has no support for a CCSID of its [effectively] one column\field. Remove the temporary file from processing, or use a temporary file which has its text field(s) assigned with a CCSID which properly describes the data.

As to QCCSID and job CCSID [the question "What is ..." seems incomplete], the user profile is IMO the best place to define the CCSID appropriate to the user for their default\expected language environment. Thus CHGPRF CCSID(desired), and the job CCSID will automatically be set from that value.

Regards, Chuck

donna lester wrote:

Since the V6R1 upgrade we are having issue with CPYTOIMPF
conversion issue, the implicit data conversion is using the job
CCSID (which is using the system value QCCSID) which defaults to
65535. 65535 means that data conversion will not implicitly
convert the data. So when I build a temporary file, it will
default to the job ccsid 65535. And when I run the CPYTOIMPF to
an ASCII stmf file, the data conversion is ignored and the ASCII
file looks like garbage.

What is the IBM solution other than changing QCCSID system value
to 37 or something thats not 65535 / using CHGJOB CCSID