Re: FW: QUSEC being cleared

On 25-Mar-2014 05:09 -0700, Paul Bailey wrote:

Whenever I clear my cached files, all the temporary files are removed
from the workspace. This is what I want. However, afterwards for a
few days/weeks, whenever RDi comes across a new /COPY book within an
RPGLE source member, it might load it into the LPEX editor (as well
as the source member requested) and I need to close it manually.
Sometimes this is the QSYSINC/QRPGLESRC(QUSEC) member, which is write
inhibited. This is just odd behaviour, but it might be related to the
main issue.

Sometimes I get an error response when the QUSEC member is loaded
telling me I have received a CPF4194 "Member QUSEC can be opened only
for input" error. However, it has somehow succeeded in *clearing* the
QUSEC source member before this message and I then need to restore
this system file from a backup in order to get programs to compile!

The lack of capabilities for the methods write, update (ALWUPD), and delete (ALWDLT) capability does not in any way influence nor prohibit the clear method.

This has happened three times since December. I only have
circumstantial evidence that RDi is doing the deed, but it is a
major issue and so I need as much advice as I can get. It only
happens for me (my other colleagues don't get the /COPY book loading
behaviour, nor any errors about QUSEC.)

FTP used to, and as far as I know never corrected, a near identical defect for the PUT feature that must clear before writing. As I recall, the error was that the feature effected a separate clear operation in preparation for the write activity before learning that write was not allowed; i.e. it was not the side effect of an open-with-clear method that had completed the clear prior to denying the open. The /upload/ and /transfer/ work noted later [from the logs] may have a similar defect.?

<<SNIP sync oddity>>

This is in the .log file after the most recent QUSEC deletion
incident:

!ENTRY org.eclipse.rse.ui 4 0 2014-03-25 10:03:58.521
!MESSAGE QSYSTempFileListener.upload trying to find editor wrapper
!STACK 0
com.ibm.as400.access.AS400Exception: CPF4194 Member QUSEC can be opened only for input.
<<SNIP>>

!ENTRY org.eclipse.rse.ui 4 0 2014-03-25 10:03:58.599
!MESSAGE QSYSRemoteMemberTransfer: error putting member to server
!STACK 0
com.ibm.as400.access.AS400Exception: CPF4194 Member QUSEC can be opened only for input.
<<SNIP>>

If anyone else has seen these behaviours or errors then I would
appreciate any advice you might have.

Object auditing (CHGOBJAUD) of the file should show the clear activity, but more valuable information should be available from a journal after starting jounaling again that file (STRJRNPF). If the feature implements the clear activity with the CLRPFM, then that CL command being audited would also provide some more details.

I would probably just trace the server jobs that implement the above upload\transfer effects, review for the error message, and then review the activity in the trace since that point; most notably, the invocation of the QDBCLRPF program that implements the OS portion of the clear.

Between us, my colleagues and I have only just made the connection
between the QUSEC going missing and this error on my screen (you
don't notice QUSEC is missing until you compile a source member that
uses it.)
<<SNIP>>

The error from the database is likely correct; i.e. the caller likely requested /all/ open options, but that request failed due to the conflict between what is requested for available capabilities and what capabilities\methods will be allowed against that file [member]. For example, see the proper effect of the following request:

Request: OPNDBF FILE(QSYSINC/H) OPTION(*ALL) MBR(QUSEC)
CPF4194: "Member QUSEC can be opened only for input."
CPF4125: "Open of member QUSEC file H in QSYSINC failed."