Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the ability to specify the current library as part of a compile action #2566

Open
heymchri opened this issue Mar 7, 2025 · 1 comment
Labels
enhancement New feature or request

Comments

@heymchri
Copy link

heymchri commented Mar 7, 2025

Introduction:

When an object gets created (program, module, panel group, etc.) through an action in VS Code, and EVFEVENT file gets created to communicate any errors back to the VS Code UI. This EVFEVENT file is always created in the same library as where the object gets created.

However, currently, VS Code uses the following logic to determine where to look for the EVFEVENT file:

  1. It will use the qualified path 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.

Problem statement:

However, if a custom action is used that has some preprocessing to determine where to compile the object to, it may get created in another library which is not the library specified on the custom action as part of a PNLGRP/OBJ/PGM/MODULE qualified name or the current library at the time the action is submitted.
In that case, errors end up being fetched from the wrong EVFEVENT file.

Example:

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

This shows the following entries in the log (several non-relevant CP* message entries removed for clarity):

Running Action: Create Object (10:28:32 AM)
Current library: HEYMCHR
Library list: QGPL QTEMP AEFLIB AEALIB HEYMCHR
Working directory: /home/heymchr/builds/xa
Commands:
                BLDOBJ LIB(HEYMCHR) STMF('/home/heymchr/builds/xa/m7x/qclsrc/acearrlec - Add_remove system reply list entry.pgm.clle') BRANCH(XA10A00010) /* OPTION(*EVENTF) */

CPC7301:  File QCLTEMPSRC created in library QTEMP.
CPC7305:  Member ACEARRLEC added to file QCLTEMPSRC in QTEMP.
CPCA081:  Stream file copied to object.
CPC0815:  Program ACEARRLEC created in library XA10A00010.

Fetching errors for HEYMCHR/ACEARRLEC .

The above shows:

  • current library is HEYMCHR
  • program gets compiled to library XA10A00010
  • errors are fetched from EVFEVENT file in library HEYMCHR ('Fetching errors for HEYMCHR/ACEARRLEC')

Suggestions:

Look for a parameter CURLIB on the action, and if it is specified, use that as the current library for the action instead of the current library shown in the User Library List:

  1. If not specified, use current logic
  2. If specified with a value of *CURLIB, use the active current library (so basically use current logic)
  3. If specified with an actual library name, set the current library for that action to the specified library name, and process the action.

This would only work in cases where the library where the object gets created is known when the action is triggered.

Better would be to check for the current library when the action has run, but before errors are fetched, and use that as the library to get the EVFEVENT details from. So the custom action can then, as part of its processing, set the current library for that job to be the library where it ended up compiling the object, and the error fetching logic would then retrieve that current library name to use for fetching the errors (assuming of course that the error fetching logic has no reliable way of determining where the object got created).

@worksofliam
Copy link
Contributor

@worksofliam worksofliam added the enhancement New feature or request label Mar 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants