Re: CRTRPGMOD: CPYSRCF: From-file EVFEVENT in KS01TS0O not allowed.

On 15-Jan-2014 11:44 -0800, Buck Calabro wrote:

On 1/15/2014 2:17 PM, CRPence wrote:

<<SNIP>>

Or is the EVFEVENT file historical, i.e. existing from prior and
was not deleted and created anew for that recent compile activity?
<<SNIP>>

EVFEVENT is historical. It is a multi-member SRC-PF that contains
compiler feedback intended for RDi. I like your train of thought;
the next stop is understanding that this file is created in the
*CURLIB in effect during the compilation. It is possible that
different RDi connections have different *CURLIBs, and therefore
there may be a chance of creating a new EVFEVENT file in a library
that one hasn't looked at yet...

FWiW: I have one of those files, but created from options on a green-screen compile, and my file is PF-DTA [i.e. File type FILETYPE(*DATA)] rather than a PF-SRC [aka FILETYPE(*SRC)]. Does RDi require exclusively that the file it uses be a SRC-PF, perhaps even deleting an existing file that is not?

Given a certain anomaly with the file, the error may be both correct and incorrect at the same time; depends on whence the information for determining the is-src vs is-dta is extracted. Knowing if that is an issue pends learning the answers to my questions, or the problem may be able to be resolved by a DLTF of the file with such an anomaly, *but* the joblog must be reviewed for any underlying errors logged... because the Delete File is "tolerant" of errors, to the extent that the noted anomaly can be a side effect; such that creating a new version of the PF is not helpful, as the condition will resurface until the file by that name has been deleted without any errors logged. However as I had also alluded, that anomaly as origin would seem unlikely, if the issue is not solid\consistent... though the origin of the temporary-name could also play a role in how consistent the failure when that anomaly exists.