you could also simply use the CLOSE opcode on the file prior to the
CPYTOIMPF...
Thanks,
Tommy Holden
From: "Stan Brisotti" <Sbrisotti@xxxxxxxxxxxxxx>
To: <midrange-l@xxxxxxxxxxxx>
Date: 06/10/2010 03:30 PM
Subject: Re: lost records
Sent by: midrange-l-bounces@xxxxxxxxxxxx
The Program that created the file also executed the CPYTOIMPF procedure
(I user QCMDEXC)
I found that executing the command after the program ends works
correctly. Thanks to all for your help.
Stan Brisotti
Information Technology Director
LAUNDRYLUX
461 Doughty Blvd.
Inwood, NY 11096
tel: (516)371-4400 x158
fax: (516)239-3670
www.laundrylux.com
Distributors of Wascomat® & Electrolux®
Professional Laundry equipment
CRPence <CRPbottle@xxxxxxxxx> 6/10/2010 4:13 PM >>>
On 10-Jun-2010 14:33, Stan Brisotti wrote:
While using CPYTOIMPF I am trying to copy a file with 557
records to a folder on my IFS. For some reason the IFS folder
has a file with 552 records. The last 5 physical records
are not copied.
What were the specified parameters, including for any defaulted
parameters what were the values for any customized defaults, on the
CPYTOIMPF CL command request? What was the Version Release
Modification on which the CL request was performed? Are there any
objects presented in the following request?:
DSPOBJD *LIBL/QCP* *DTAARA
What was the final error or completion message, and what were the
messages logged between that message and the request [message] itself?
How were the database rows counted, and how were the stream file
records counted? Since a database file being copied using SQL is an
uncollated /set/ of rows, how was it verified that the "last 5
physical records" were not copied versus some other five rows? If
the full record\row count of the FROMFILE was determined from its
member description, then there could for example be five deleted
records, and thus since deleted rows are not exported there would
correctly be five fewer records in the STMF than in the DBF member.
Regards, Chuck
midrange.com
