The first FTP attempt got this error:
Message . . . . : 3700 - FTP
RMTSYS('10.51.1.99')
CPF4128 Escape 40 11/16/09 21:49:05.808072
QDBSIGEX QSYS 0529 QODCLOSE QSYS 0D10
Message . . . . : Not able to
allocate objects needed for file QAOSSI12 in
library QUSRSYS member or program
device QAOSSI12.
Cause . . . . . : One of the
following occurred: -- The file, library,
member, or device is in use by
another job. For printer devices, this may
be a print writer job. -- The
device is not varied on, or has been deleted
or renamed. -- No sessions are
available for an advanced program-to-program
communications (APPC) device.
Recovery . . . : Do one of the following
and try the request again: --
Vary the configuration on (VRYCFG command) if
necessary. -- End the print
writer that has the printer device allocated. --
Use the Work with Configuration
Status (WRKCFGSTS *DEV) command to verify
that the device is varied on and
to determine what job is using the device.
From that point on, any FTP command got this:
Message . . . . : 3700 - FTP
RMTSYS('10.51.2.99')
CPF5129 Escape 50 11/16/09 21:53:07.116021
QDMIFERR QSYS 01DB QODCLOSE QSYS
Message . . . . : I/O is not
allowed because the program device or member
QAOSSI12 file QAOSSI12 in
library QUSRSYS is in error.
Cause . . . . . : An
input/output (I/O) operation was requested for a file
that is in error. Recovery . .
. : See messages in the job log or program
message queue. Correct the
errors, and then try the request again.
The file was no longer in use but yet we still got the QAOSSI12 file is
in error. How do we close out the error when we retry the FTP
commands?
-----Original Message-----
From: CRPence [mailto:CRPbottle@xxxxxxxxx]
Sent: Tuesday, November 17, 2009 1:20 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: FTP unable to close file. Error Code CPE3006
FWiW. The generic I/O error [3006] for the FTP GET was a side
effect of the QODCLOSE error; i.e. the error referred to as the
/previous message/ in the /Recovery/ text for the CPE3006. The
QODCLOSE error is a side effect of yet another previous error
message, the CPF5129 "interface error" condition. That interface
error arose from yet another prior error [albeit not visible in the
joblog] in processing the document details for the DLO that was
having its data replaced by the GET (REPLACE request. So...
A RCLSTG would probably be excessive. To be sure, that function
is not listed in\as the /Recovery/ of the logged messages; the
reclaim storage feature should be required almost exclusively for
conditions diagnosed by error messages, where stated specifically as
recovery action. Also for apparently being in /QDLS, there is the
less excessive RCLDLO reclaim feature. However neither is that
command listed in any of the messages as recommended recovery
actions. That is because the original database I/O error for the
QAOS* files [as implementation objects], would generally not be
recoverable by the RCLDLO feature, since the database of document
details must be functional in order to be properly updated by the
reclaim DLO request.
Regards, Chuck
Scott Klement wrote:
This seems to imply a disk error of some sort. Possibly a
corrupt file on disk? (Presumably, the file on the client's side
of the connection.) Have you tried RCLSTG?
brad_bird wrote:
During our nightly polling, we starting getting a "Unable to
close file. Error code CPE3006" on upload but yet all download
files were sent successfully. This is a portion of the FTP
output log and program log for the error. Anyone have any idea
on the cause?
As an Amazon Associate we earn from qualifying purchases.