Thank you very much for the reply...

Comments below.

On 25 Dec 2014 at 16:52, CRPence (CRPence <midrange-l@xxxxxxxxxxxx>) commented
about Re: CPYFRMIMPF Error CPF2973:

On 25-Dec-2014 12:18 -0600, Gary Kuznitz wrote:
I'm trying to copy a file from the IFS to a DB file. I'm getting
errors on every record. The error is CPF2973

The from-program and to-program were not included in the information
below. The partial symptom string is msgCPF2973 F/QCPIMPRT FM/QCPIMPRT
FP/Send_type_msg stmt/15 ... TM/QDBCTHTWRK

I am only working with one program that doesn't call any other programs. I don't know
why the from-program and to-program were not included in the information.

From module . . . . . . . . : QCPIMPRT
From procedure . . . . . . : Send_type_msg
Statement . . . . . . . . . : 15
To module . . . . . . . . . : QDBCTHTWRK
To procedure . . . . . . . : start__17qdbcth_ThreadWorkFP17...
Statement . . . . . . . . . : 10
Message . . . . : Data from
file in truncated to 20 characters.
Cause . . . . . : The maximum record length for
member in from-file in
library is longer than the
maximum record length for to-file MBRPAYATU in library GARY2.
Technical description. . . : If the from-file is a tape file
with variable length records or if multiple record formats are copied
from a logical file, only the records that are longer than 20
characters are truncated. <<SNIP>>

An APAR for v5r2 described a similar issue; at least having noted the
missing replacement text for that message.

In the CLP I have:
Message . . . . : 5700 - CPYFRMIMPF

I am getting no records in the error file.
I don't have any double quotes in the file past the first record.
This is one record of the input file from the IFS:
372|7/12/2013|000027857|Last Name, Brian

The above is all on one line. = One record.

Does anyone have any idea why I would be getting the error?

PS: V5R3

Is the Copy From Import File (CPYFRMIMPF) running using the v5r2
support; i.e. is there a Data Area (DTAARA) named QCPFRMIMPF in QSYS
with the string value 'CPV5R2'? If so, then allowing the feature to use
the actual V5R3 support might assist; i.e. delete the data area, or
modify the value of the string data, because the v5r2 code path had an
almost identical symptom.
I don't have that DTAARA on the system.

Note that the date data values are in *USA format, but the default
for the command tells the import feature that the date data values
should be *ISO.

Thank you for catching that. I'm not sure the date values are going to work anyway.
The dates in the input file may have different formats.
One may be:
Another may be
I have changed the date data values to *USA.
In the DDS I didn't specify the Date fields as dates.
A TRANSDATE 10 TEXT('Transaction Date')

The command suggests the strings are delimited with the
double quote, but the items in the given record clearly are not.

I wasn't sure what that meant. Does that mean I should use *None?

Performing the request from the command-line in a new job rather than
via the CLP and in a job that has performed other work might exhibit a
different effect; may be worth a test attempt.

That same request made with the given record on the PUB1.DE public
v5r3 system functioned without any errors.

If none of that is helpful, then ...

That was very helpful. It's fine running now.

Thank you tremendously. You are a life saver.



The means to create the target of the import and the error record
file were not included, but those could be helpful to identify the
issue. Also helpful would be the first few stream records of the STMF,
regardless the /first/ record was asked to be skipped; much more
relevant, given "every record" gets the error. A sample of just a few
redacted records that still exhibit the errors would be ideal, along
with the hexadecimal code points of the data; plus the CCSID of the STMF
and the CCSID of the fields of the DBF.

Regards, 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,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives

This thread ...


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

This mailing list archive is Copyright 1997-2019 by 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].