|
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.
Von: CRPbottle@xxxxxxxxx
An: wdsci-l@xxxxxxxxxxxx,
Datum: 15.01.2014 20:17
Betreff: Re: [WDSCI-L] CRTRPGMOD: CPYSRCF: From-file EVFEVENT in
KS01TS0O not allowed.
Gesendet von: wdsci-l-bounces@xxxxxxxxxxxx
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 theyallowed."
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
</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.
--
Regards, Chuck
--
This is the Rational Developer for IBM i / Websphere Development
Studio Client for System i & iSeries (WDSCI-L) mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/wdsci-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
