RE: CPYFRMIMPF V5R3 error?

Here is a snip for v5r3 changes to CPYFRMIMPF command in memo to users.
Perhaps one of the three changes applies to the error you're seeing.

<snip>

3.37.3 CPYFRMIMPF command changes

3.37.3.1 No conversion performed if TOFILE field has no CCSID or a 65535

        CCSID

In prior releases, the CPYFRMIMPF command 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 command copies 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 command changes
in V5R3, please refer to Informational APAR II13784.

3.37.3.2 Record delimiter (RCDDLM) parameter change

RCDDLM(*ALL) will find the first occurrence of a single or double
character combination of carriage-return and line-feed and use that
value as the record delimiter.

3.37.3.3 Character strings containing a null character (X'00') allowed
        only in binary fields

In previous releases, the CPYFRMIMPF command treated character strings
containing a null character (X'00') as acceptable values for any field.
In V5R3, character strings containing a null character (X'00') are
allowed only for binary type fields. Binary type fields are BINARY,
VARBINARY, BLOB, CHAR FOR BIT DATA, or CHAR CCSID(65535). A null
character (X'00') encountered in a non-binary field will produce a data
mapping error.

<end snip>

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
ron_adams@xxxxxxxxxxxxxx
Sent: Tuesday, September 14, 2004 8:04 AM
To: 'Midrange Systems Technical Discussion'
Subject: CPYFRMIMPF V5R3 error?

We just upgraded to a new 520 running V5R3 (from V4R5) and are 
experiencing trouble with CPYFRMIMPF in a process that worked flawlessly 
prior to the conversion.

Nothing has changed (that I know of), it still works on the old machine/OS 
version. The From and To files and the FDF are all the same.

I'm getting error CPF2845 - The copy did not complete for reason code 7.
   7 - The FROMFILE numeric field *N contain blank characters, or other 
 characters that are not valid for a numeric field. 

This is my Command,

CPYFRMIMPF FROMFILE(SVFDTA/CPOFILE) 
           TOFILE(SVFDTA/MAN010P) 
           MBROPT(*ADD) 
           DTAFMT(*FIXED) 
           RMVBLANK(*NONE) 
           FLDDFNFILE(SVFSRC/QDDSSRC MAN010PFDP)
           FROMRCD(1 5) 

So, what changed from V4R5 to V5R3 to muck this up? I read some stuff in 
the KB about CCSID differences, do I need to take that into heavy 
consideration? The CCSID on the Fromfile is 500, the CCSID of the Tofile 
is 37.

Ron Adams
Information Technology Group
Crane Valves
9200 New Trails Dr. Suite 200
The Woodlands, TX 77385
--
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.