EVFEVENT issue - "not allowed"

[zkarj735]

I've just got back from a 4-week break and am noting that my VSCode compiles are "failing".

Which is to say the actual compile works fine and I even get to see the compile listing, but it ends with the following messages:

Fetching errors for QGPL/WRKQB.
Error: Failed fetching table: CPC2206:  Ownership of object QCPEXTEMPS in QTEMP type *USRSPC changed.
                              CPF4102:  File EVFEVENT in library QGPL with member WRKQB not found.
                              CPF2803:  To-file EVFEVENT in QGPL not allowed.
                              CPF2817:  Copy command ended because of error.
                              CPC2206:  Ownership of object QZSHSYSTEM in QTEMP type *USRSPC changed.

 *  The terminal process terminated with exit code: 1. 
 *  Terminal will be reused by tasks, press any key to close it.

I believe this is why the VSCode notification marks the compile as failed. I've seen a couple of similar issues but not quite the same. Note that this was working four weeks ago. I can't imagine much has changed on the server in that time except for PTFs.

I checked the QGPL/EVFEVENT file authority, and my group profile has *ALL. I changed *PUBLIC from *CHANGE to *ALL just in case, but it made no difference.

But I think the issue is that it thinks I was compiling QGPL/WRKQB.

My compile command is a custom one.

FMCMPSRC2 STMF('/home/T816416/builds/system-tools/fmlcl/wrkqb.clle') SBMJOB(*NO) /* OPTION(*EVENTF) */

In this case it translates to and runs...

CRTBNDCL PGM(FMLCL/WRKQB) SRCSTMF('/home/T816416/builds/system-tools/fmlcl/wrkqb.clle') DBGVIEW(*ALL) OPTION(*EVENTF)

...which, as I mentioned, successfully compiles the object. I get all of the output from our compile tool, plus the full compile listing, then the above errors.

So how is VSCode showing me the compile listing on the one hand but then failing to 'fetch errors' from the same? Or am I misunderstanding how it fits together?

I would appreciate any help getting to the bottom of this. It doesn't stop me compiling, but it makes it so I have to double check every listing to see whether it actually worked.

[sebjulliand]

Note that this was working four weeks ago. I can't imagine much has changed on the server in that time except for PTFs.

I'm afraid this part of the action processing hasn't changed since ages 😅

So how is VSCode showing me the compile listing on the one hand but then failing to 'fetch errors' from the same? Or am I misunderstanding how it fits together?

That's because running the action and fetching the errors from EVFEVENT are two different processes.
The output is retrieved from the action's command execution and then, if the command contains *EVENTF in it's definition (like yours) then it triggers errors retrieval from <member_library>/EVENTF when the action is run on a member or <current_library>/EVENTF when run on a streamfile.

Given what you reported, I'll assume that QPGL is your current library in your library list view. And since the compilation took place in FMLCL, then FMLCL should be the current library as the EVENTF file Code for i looks for is in there. Try changing it and run the compilation again.

[zkarj735]

That does indeed remove the error, but...

I'm afraid this part of the action processing hasn't changed since ages 😅

Something has changed, because I have never set my current library before. It has always been the default.

[chrjorgensen]

@zkarj735 FWIW, I have the same setup as you and see the same behavior as you: Failing compiles even though the compile completed.

Like you, I use a custom compile command (a modified version of BUILD from Scott Klement). The compile library is controlled by instructions in the source streamfile, and C4i does not know which library was the target. So the compile will be marked "failed" in C4i, unless I change the current library to the target library before compiling.

It has always been like that.

RDi has a similar issue, but uses *LDA data structure to retrieve the location of the EVFEVENTF file. C4i can't use that technique, since actions in C4i are stateless while RDi has a stateful connection.

[zkarj735]

It has always been like that.

I regularly compile into several different libraries (my compile tool uses the IFS folder structure to determine which) and have never set my current library before yesterday.

How did it ever find EVFEVENT before?

I guess if it's a stateless connection, then there's no smoke and mirrors I can use in my tool.

[chrjorgensen]

I guess if it's a stateless connection, then there's no smoke and mirrors I can use in my tool.

No unfortunately, there is currently no way of sending information back to C4i about which EVFEVENTF file(s) to retrieve...

[zkarj735]

I was more thinking I could set the current library before returning, but would C4i see that, or just keep its own idea?

[chrjorgensen]

C4i sets the current library and library list before running the command(s) in your action, and it does not detect any changes to that after command is completed. No information except the joblog and compiler output is returned to C4i. So no, C4i will not notice if you change the current library in your command.

[zkarj735]

I suppose I could copy the EVFEVENT member to the current library after the compile. My compile tool will know where the real one is, and can copy to *CURLIB.

[zkarj735]

That works a treat. I can leave QGPL set as my current library, and this gets EVFEVENT to where C4i expects to find it. I created this as a module and then called it as the very last step of my compile processor.

/* Copies the EVFEVENT member under specific circumstances.     */
/* This enables Code for i to read back errors on compiles.     */ 
pgm parm(&objlib &obj)

dcl &objlib *char 10
dcl &obj *char 10
dcl &curlib *char 10
dcl &copy *char 1 value('Y')

rtvjoba curlib(&curlib)
/* If the following are true                                    */
/*  - a current library is set (*CURLIB), and                   */
/*  - that contains an EVFEVENT file, and                       */
/*  - an EVFEVENT member exists in the compile target library   */
/* then the member is copied to the current library.            */
if (&curlib ¬= '*NONE') then(do)
  chkobj &curlib/EVFEVENT *file
  monmsg cpf9800 exec(chgvar &copy 'N')
  chkobj &objlib/EVFEVENT *file mbr(&obj)
  monmsg cpf9800 exec(chgvar &copy 'N')
  if (&copy = 'Y') then(do)
    cpyf &objlib/EVFEVENT &curlib/EVFEVENT frommbr(&obj) tombr(*frommbr) mbropt(*replace)
  enddo
enddo

The only prerequisite is that QGPL/EVFEVENT must already exist. In my case it did. I decided I wasn't going to have the code creating new files anywhere - just copy members between existing ones. That saves messing with definitions and authorities in the code.

[chrjorgensen]

Nice!

One suggestion: You can create the EVFEVENT file if it does not exist...

...
dcl &crtfile *char 4 '*NO'
...
  chkobj &curlib/EVFEVENT *file
  monmsg cpf9800 exec(chgvar &crtfile '*YES')
...
    cpyf &objlib/EVFEVENT &curlib/EVFEVENT frommbr(&obj) tombr(*frommbr) mbropt(*replace) crtfile(&crtfile)
...

Now there's no requirement for the EVFEVENT to already exist.

[chrjorgensen]

Btw, I'm puzzling with another idea: Having C4i search the joblog for messages identifying any EVFEVENT files output from the command run by the action. This would allow C4i to download the correct file, disregarding the current library.

It's easy to write to the joblog, SQL procedure SYSTOOLS.LPRINTF can be called from anywhere.

[sebjulliand]

Btw, I'm puzzling with another idea: Having C4i search the joblog for messages identifying any EVFEVENT files output from the command run by the action. This would allow C4i to download the correct file, disregarding the current library.

It's easy to write to the joblog, SQL procedure SYSTOOLS.LPRINTF can be called from anywhere.

Sounds interesting 😉

[zkarj735]

One suggestion: You can create the EVFEVENT file if it does not exist...

Per my comment after the code, this was a decision I made deliberately. Who knows what someone might have as their current library – I won't be the one to pollute them with EVFEVENT files. I'll leave it as a deliberate act.

Btw, I'm puzzling with another idea: Having C4i search the joblog for messages identifying any EVFEVENT files output from the command run by the action.

I also looked at the joblog for anything canonical to identify this but there isn't, that I can see. You would have to determine the object library and finding that will differ depending on the object type being created. C4i won't even necessarily know the object type, either. In my case, my compile tool decided on CRTMOD versus CRTBNDRPG based on directives embedded in source comments.

There are many possible processes and outcomes between defined VSCode actions and whatever they run on the server.