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

On 15-Jan-2014 05:37 -0800, thomas.raddatz@xxxxxx wrote:

Ocassionally I get the following error message when I compile a RPG
modules from the RSE:

<errorMessage>
Member /QSYS.LIB/LIBHTTP.LIB/EVFEVENT.FILE/BASE64R4 could not be
saved successfully because an attempt to copy temporary member
/QSYS.LIB/LIBHTTP.LIB/EVFEVENT.FILE/RSE8791045 to source member
/QSYS.LIB/LIBHTTP.LIB/EVFEVENT.FILE/BASE64R4 failed. Check the
allow-write or allow-update flags for source file
/QSYS.LIB/LIBHTTP.LIB/EVFEVENT.FILE are set to *YES. Also make sure
file member /QSYS.LIB/LIBHTTP.LIB/EVFEVENT.FILE/BASE64R4 is not
locked by another job. During a save, the Remote Systems LPEX Editor
first creates a temporary member, uploads the changes to the
temporary member and then copies the temporary member over the
original member if the upload was successful. The temporary member is
then deleted. If this problem persists you can change the member save
behavior on the Remote Systems -> IBM i -> Objects Subsystem
preference page and then try saving again. Below is the message
returned from the server when attempting to run the CPYSRCF command:

From-file EVFEVENT in LIBHTTP not allowed.

Hardly accurate to claim that is "the message returned from the server". That's merely the _text_, and besides that, only the first-level message text. Damned subversives... refusing to reveal the message identifier, exposing only the text! ;-) Seriously though... Why must they force themselves and everyone else to search? Are they unaware that not everything will be presented in their own language? Anyhow, after both that rant and having looked up the USEng message text, I found that was apparently CPF2801 "From-file &1 in &2 not allowed."

</errorMessage>

I can safely bet on that message when I compile a bunch of modules
from the RSE.

The "Commands Log" does not show anything special:

<commandsLog>
<<SNIP>>

Module BASE64R4 placed in library LIBHTTP. 00 highest severity.
Created on 15.01.14 at 14:15:43.
<<SNIP>>

Module CCSIDR4 placed in library LIBHTTP. 00 highest severity.
Created on 15.01.14 at 14:15:43.
<<SNIP>>

Module COMMSSLR4 placed in library LIBHTTP. 00 highest severity.
Created on 15.01.14 at 14:15:44.
<<SNIP>>

Module COMMTCPR4 placed in library LIBHTTP. 00 highest severity.
Created on 15.01.14 at 14:15:45.
<<SNIP>>
</commandsLog>

Seems likely origin, from the description so far, this could be a concurrency issue.

But the Eclipse error contains the error message:

<errorLog>

!ENTRY org.eclipse.rse.ui 4 0 2014-01-15 14:15:46.308
!MESSAGE Error uploading member
!STACK 0
org.eclipse.rse.services.clientserver.messages.SystemMessageException:
Save failed. Could not copy temporary member
/QSYS.LIB/LIBHTTP.LIB/EVFEVENT.FILE/RSE8791045 to member
/QSYS.LIB/LIBHTTP.LIB/EVFEVENT.FILE/BASE64R4.
<<SNIP>>

So apparently the actual failing request that was not recorded in the error log, was:

cpysrcpf libhttp/evfevent libhttp/evfevent
frommbr(rse8791045) tombr(base64r4)
mbropt(*replace) /* srcopt() srcseq() likely n/a */

!ENTRY org.eclipse.rse.ui 4 0 2014-01-15 14:15:46.316
!MESSAGE EVFF5037
</errorLog>

Although an object lock could be the reason for the problem, I wonder
why the content of the EVFEVENT/RSE8791045 member of file EVFEVENT
is different from member EVFEVENT/BASE64R4:

Or possibly a lack of locking; i.e. the copy utility having made decisions based on information obtained without holding a lock. Or, there is an anomaly with the file and\or member(s), but then the effects should be consistent across identical requests [in this scenario, that may depend on the origin for the name RSE8791045 being utilized]; questions and possible doc collections noted later, below.

Seems the source "data" (SRCDTA column data) is identical, but the apparent record format used for the data is different. As one physical file with one RcdFmt, the implication seems to be that the SRCSEQ and SRCDAT columns have been overwritten with data from SRCDTA.

<RSE8791045> (stripped to 70 columns)
*...+....1....+....2....+....3....+....4....+....5....+....6....+....7
000000140115TIMESTAMP 0 20140115141543
...
****** END OF DATA ******
</RSE8791045>

<BASE64R4> (stripped to 70 columns)
*...+....1....+....2....+....3....+....4....+....5....+....6....+....7
TIMESTAMP 0 20140115141543
...
</BASE64R4>

What interface was used for the above two snippets of data? Seems likely Display Physical File Member (DSPPFM)? The EOD line was missing from the second snippet; perhaps oversight, or perhaps there was none presented.? The data of each member viewed with Run Query (RUNQRY) could be worthwhile, to show the data within field; i.e. the layout:

runqry *n ((libhttp/evfevent rse8791045))
runqry *n ((libhttp/evfevent base64r4 ))

Same content, but RSE8791045 is a source file format.

Interesting effect, because The error msg CPF2801 implies the FROMFILE is not a source physical file; i.e. the cause suggests that "CPYSRCF command requires a source file on the FROMFILE parameter."

Does the output from DSPFD LIBHTTP/EVFEVENT *MBR include both members RSE8791045 and BASE64R4? In actual counting, vs trusting the member count presented by DSPFD, do the number of members listed in that prior DSPFD request and the DSPFD LIBHTTP/EVFEVENT *MBRLIST request show the same number of members [and the same members by name; effectively the same origin for the question about if BASE64R4 might be missing in presentation in one request but not the other].

Possibly worth collecting each of:

dmpsysobj 'EVFEVENT RSE8791045' libhttp 0d 50
dmpsysobj 'EVFEVENT BASE64R4 ' libhttp 0d 50

<<SNIP>>
All your comments would be greatly appreciated.

Is the EVFEVENT file being deleted and re-created for each compile or even just some compiles? Sometimes as PF-SRC, and other times as PF-DTA? If object auditing is active, at least the former can be determined. If the file is being deleted and re-created concurrent to Copy Source File (CPYSRCF) requests, that would be a likely origin for a concurrency issue being exposed with that feature.

Or is the EVFEVENT file historical, i.e. existing from prior and was not deleted and created anew for that recent compile activity? The creation data from DSPOBJD LIBHTTP/EVFEVENT *FILE *FULL OUTPUT(*PRINT) would establish that; i.e. if the creation data is long ago. If the EVFEVENT file is historical, then Start Journal Physical File (STRJRNPF) of that file might gives some timestamps of future member activity which might be helpful; [and including data, but] unlikely to significantly impact the ability to recreate the error.