Fetching errors from EVFEVENT in compiled object library vs. current library

[heymchri]

When compiling a program from a streamfile using the 'standard' compile commands, the program gets created (or not...) into the current library and any errors are retrieved from the EVFEVENT file that gets created in the current library.

However, we have created additional tasks that do some pre-processing and may end up creating the program in another library than the library that was the current library at the time the task was run. E.g., current library in VS Code shows XA10A00008 as the current library.

As part of the pre-processing when running the task, we may end up changing the current library to another library (CHGCURLIB...) or just as part of the compile command, explicitly specify the library name where the program needs to be compiled. However, when fetching errors, they're always fetched from the EVFEVENT file in the library that was the current library at the time the task was run. So, in this situation, if compile errors occur, they're not shown because the wrong EVFEVENT info is retrieved.

Is this expected? Shouldn't the actual library where the program was compiled be used to retrieve the EVFEVENT info?

Here's what the terminal shows:

CPC7301:  File QCLTEMPSRC created in library QTEMP.
CPC7305:  Member ACEARRLEC added to file QCLTEMPSRC in QTEMP.
CPCA081:  Stream file copied to object.
CPC7301:  File EVFEVENT created in library XA10A00010.
CPC7305:  Member ACEARRLEC added to file EVFEVENT in XA10A00010.
CPD4090:  Printer device PRT01 not found. Output queue changed to QPRINT in library QGPL.
CPFA0A9:  Object not found.  Object is EN_US.UTF-8.
CPFA0A9:  Object not found.  Object is EN_US.UTF-8.
CPFA0A9:  Object not found.  Object is EN_US.UTF-8.
CPC0815:  Program ACEARRLEC created in library XA10A00010.
CPI2218:  Authority *ALL or *AUTL revoked from *PUBLIC.
CPI2201:  Authority given to user *PUBLIC for object ACEARRLEC in XA10A00010 object type *PGM.
CPC2103:  Object changed for ACEARRLEC in XA10A00010 type *PGM.
AEC1012:  ACEARRLEC type *PGM compiled to library XA10A00010.
CPFA0A9:  Object not found.  Object is EN_US.UTF-8.

Fetching errors for XA10A00008/ACEARRLEC .

The program gets compiled into XA10A00010, and that's where the EVFEVENT gets created, but you can see that the errors are retrieved from XA10A00008.

(I have also submitted a related question in the discussions section (https://github.com/orgs/codefori/discussions/2561) regarding the ability to set the curent library through a script, as that would be a way for us to circumvent this issue)

---

Context	Version
Code for IBM i version	2.15.2
Visual Studio Code version	1.97.2
Operating System	darwin_arm64

Active extensions

.NET Install Tool (vscode-dotnet-runtime): 2.2.8
Amazon Q (amazon-q-vscode): 1.49.0
C# (csharp): 2.63.32
C# Dev Kit (csdevkit): 1.16.6
CL (vscode-clle): 1.1.7
COBOL (cobol): 25.3.3
Code for IBM i Walkthroughs (vscode-ibmi-walkthroughs): 0.5.0
Configuration Editing (configuration-editing): 1.0.0
Db2 for IBM i (vscode-db2i): 1.9.3
Debugger for Java (vscode-java-debug): 0.58.1
Dev Containers (remote-containers): 0.401.0
Docker (vscode-docker): 1.29.4
Emmet (emmet): 1.0.0
Error Lens (errorlens): 3.23.0
Excel Viewer (gc-excelviewer): 4.2.63
Extension Pack for Java (vscode-java-pack): 0.29.0
Git (git): 1.0.0
Git Base (git-base): 1.0.0
GitHub (github): 0.0.1
GitHub Authentication (github-authentication): 0.0.2
GitLess (gitless): 11.7.2
Gradle for Java (vscode-gradle): 3.16.4
Grunt support for VS Code (grunt): 1.0.0
Gulp support for VSCode (gulp): 1.0.0
HTML Language Features (html-language-features): 1.0.0
IBM i Debug (ibmidebug): 2.0.2
IntelliCode (vscodeintellicode): 1.3.2
JSON Language Features (json-language-features): 1.0.0
Jake support for VS Code (jake): 1.0.0
Jira and Bitbucket (Atlassian Labs) (atlascode): 3.4.12
Language Support for Java(TM) by Red Hat (java): 1.40.0
Live Preview (live-server): 0.4.15
Merge Conflict (merge-conflict): 1.0.0
Microsoft Account (microsoft-authentication): 0.0.1
NPM support for VS Code (npm): 1.0.1
Node Debug Auto-attach (debug-auto-launch): 1.0.0
Overtype (overtype): 0.5.0
Prettier - Code formatter (prettier-vscode): 11.0.0
Print (vscode-print): 1.2.1
Project Manager for Java (vscode-java-dependency): 0.24.1
RPGLE (vscode-rpgle): 0.28.6
SQL Server (mssql) (mssql): 1.29.0
Server Ready Action (debug-server-ready): 1.0.0
Source Orbit (vscode-sourceorbit): 1.0.2
TODO Highlight (vscode-todo-highlight): 1.0.5
Task Buttons (vscode-task-buttons): 1.1.3
Test Runner for Java (vscode-java-test): 0.43.0
TypeScript and JavaScript Language Features (typescript-language-features): 1.0.0
YAML (vscode-yaml): 1.17.0
vscode-icons (vscode-icons): 12.11.0

---

Remote system

Setting	Value
IBM i OS	V7R5M0
Tech Refresh	5
CCSID Origin	37
Runtime CCSID	37
Default CCSID	37
SSHD CCSID	?
cqsh	true
SQL	Enabled
Source dates	Enabled

Enabled features

/QOpenSys/pkgs/bin	/usr/bin	/QSYS.lib/ILEDITOR.lib	/QSYS.LIB	/QIBM/ProdData/IBMiDebugService/bin	/QOpenSys/QIBM/ProdData/JavaVM/jdk80	/QOpenSys/QIBM/ProdData/JavaVM/jdk11	/QOpenSys/QIBM/ProdData/JavaVM/jdk17
bash	attr	GETNEWLIBL.PGM	QZDFMDB2.PGM	startDebugService.sh	64bit	64bit	64bit
chsh	iconv
find	setccsid
git	uname
grep
ls
md5sum
sort
stat
tar
tn5250

Shell env

BUILDLIB=XA10A00008
CURLIB=XA10A00008
HOME=/home/HEYMCHR
HOST=usalil2c.infor.com
LIBLS=XA10A00008 HEYMCHR AEALIB AEFLIB QTEMP QGPL
LOGIN=heymchr
LOGNAME=heymchr
MAIL=/var/spool/mail/heymchr
OLDPWD=/home/HEYMCHR
PATH=/QOpenSys/usr/bin:/usr/ccs/bin:/QOpenSys/usr/bin/X11:/usr/sbin:.:/usr/bin
PWD=/home/HEYMCHR
SHELL=/QOpenSys/pkgs/bin/bash
SHLVL=1
SSH_CLIENT=10.61.4.120 57612 22
SSH_CONNECTION=10.61.4.120 57612 10.39.80.80 22
TGTRLS=V7R4M0
TZ=<EST>5<EDT>,M3.2.0,M11.1.0
USER=heymchr
USERNAME=heymchr
WORKDIR=/home/HEYMCHR
_=/QOpenSys/usr/bin/env

Variants

{
  "american": "#@$",
  "local": "#@$"
}

[worksofliam]

Hi @heymchri

So, as of today this is how the the compile library is detected:

1. It will use the qualified defined in one of these parameters: PNLGRP, OBJ, PGM, MODULE
2. If no library is found from the qualified path, then it will default to the current library.

This is how it's worked for all these years as we don't have a way of detecting where objects are created by the compiler directly, which is what it sounds like your custom processing is doing.

With that said, we may be able to look for the library from the result of CPC0815 in the job log. In your output it says:

CPC0815: Program ACEARRLEC created in library XA10A00010.

But, I don't think we can rely on this as the output will be different for different locales.

[heymchri]

@worksofliam thanks for this information. How do you determine the name of the compiled program though? My custom action uses this command:

BLDOBJ LIB(HEYMCHR) STMF('/home/heymchr/builds/xa/m7x/qclsrc/acearrlec - Add_remove system reply list entry.pgm.clle') BRANCH(XA10A00010) /* OPTION(*EVENTF) */

The name of the actual compiled program is not in this command string - as part of our processing we determine the actual program name from the STMF value.

I just tried something like this:

BLDOBJ LIB(HEYMCHR) STMF('/home/heymchr/builds/xa/m7x/qclsrc/acearrlec - Add_remove system reply list entry.pgm.clle') BRANCH(XA10A00010) /* OPTION(*EVENTF) OBJ(XA10A00010/DUMMY) */

and this indeeds causes the EVFEVENT file from the XA10A00010 library to be used, but of course it also uses 'DUMMY' as the program name...

Just a thought: could the logic that detects the compile library be enhanced to look for a CURLIB parameter? If it's not specified on the action command, current logic would be used. CURLIB(*CURLIB) would use the current library, and CURLIB() would use as the current library just for the action, i.e., an override from the actual current library.

[worksofliam]

How do you determine the name of the compiled program though? My custom action uses this command:

It's the same as the library: either via one of those parameters I mentioned before, or we derive it from the file name.

If it's not specified on the action command, current logic would be used.

This is a pretty good idea: if one of those parameters (PNLGRP, OBJ, PGM, MODULE) is not a qualified path, then we could get the current library after the command has run.

I think this issue should be converted to a discussion and a new issue be raised with your idea and the information we both shared. I will mark it as an enhancement. Is that something you can do?

[heymchri]

@worksofliam looking at that code you shared, it looks like this piece of code is the one that gets the actual object name by only keeping the part before the '-', so that makes sense.

So you want me to create a new discussion, and also create a new issue with this CURLIB idea? I can certainly do that.

[worksofliam]

@heymchri You just create a new issue/feature request, and I will convert this to a discussion. Thanks!