Re: cpytoimpf issue - v6r1

Comments inline.

Regards, Chuck

donna lester wrote:

It looks like CPYTOIMPF in V6R1 is now treating the parms
exactly as documentedâthe FROMCCSID in the below CPYTOIMPF
defaults to *FILE and the temporary flat file RSPQSPRCCV is
65535. So according to the help <ed: for FROMCCSID parameter>
below, CPYTOIMPF will not convert the flat file data.

*FILE
The data is converted from the from-file field CCSID.
If the CCSID of the from-file field is 65535, the field
is not converted and it is treated as binary data.

The FROMCCSID parameter was added to provide support similar to that found prior to V5R3; i.e. where data tagged with 65535 [aka *HEX] was implicitly converted similar to how CPYTOSTMF does. That the export feature used CPYTOSTMF, was the origin for that improper conversion; a side effect, for which the circumvention was as simple as inserting the missing CPYTOSTMF [which was a redundant copy of the data removed from the CPYTOIMPF feature] prior to the CPYTOIMPF request. The V5R3 correction had the feature start leaving unchanged, the data tagged with *HEX, just as that CCSID specification implies should occur.

I did not recall that feature exists. That feature indeed allows "overriding the columns\fields of the database file" so such fields are treated as though tagged with the specified CCSID.

Unless the FromCCSID = 37 or the FromFile is
a database file (could use gmiddsc dds(#5000) to create
the file with one field).

Although a program-described file is a database *FILE, such a "flat file" is to be described by the program. Since the CPYTOIMPF is a system utility\program, there is no ability to describe the layout of the file beyond the inputs to [i.e. parameters of] the command. If the data is one long string of character data, then there should be a [varying] character column with the appropriate CCSID designating the code page and character set of the code points. As a database export feature, there should have been little expectation [and no support] such that a program described file would be export capable.

I'm really surprised that this issue did not come up before.
I remember this issue back in the V5R3 to V5R4 upgrades.

The issue actually originated in v5r3 as noted above. However on those releases, there was a data area [*DTAARA] implementation which could override the code path of each of the export & import features to perform the v5r2 algorithm; i.e. downgrade the support, to the version which was not enhanced. The data area(s) may no longer exist on the system being used, the character value may have changed, may no longer be unaccessible, or may no longer be supported in v6r1.

CPYTOIMPF FROMFILE(QTEMP/RSPQSPRCCV) fromccsid(*FILE --> 37) TOSTMF('home\RSPData\srocdran.csv') MBROPT(*REPLACE)
STMFCODPAG(*PCASCII) RCDDLM(*CRLF) DTAFMT(*FIXED)
STRDLM(*NONE)
The issue I am having is that the data within certain fields is not converting properly (below RCODE and RDESCR fields). Changing
CCSID(37) fixed it. The problem is we have nearly 500 programs
where we need to change CCSID to 37, which is tough task, I am
trying to find if there is any easy solution (perhaps any PTF???)
rather than going through all 500 programs and changing them to
37.

RABCID|RCODE|RDESCR|RDD| T|Ã|ÃÃÃÃ@ÃÃÃ`ÃÃÃÃ|57| T|Ã|ÃÃÃÃ@ÃÃÃ`ÃÃÃÃ|57|
RCODE is defined as 1 CHAR and RDESCR is defined as 30 CHAR.

So it seems that RSPQSPRCCV in QTEMP is an externally described file, but some character fields [i.e. RCODE & RDESCR] are not properly tagged with a non-hex CCSID.

Since the FROMCCSID() is presumably not actually specified on the command string, then CHGCMDDFT CPYTOIMPF 'FROMCCSID(37)' would seem to be just as poor [and similarly blind to actuality] implementation as was the CPYTOSTMF effected in v5r2 and prior [and on v5r3 & v5r4 using the "use v5r2 algorithm" feature].

CRPence wrote:

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 noted "temporary file" 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.

<<SNIP>>