You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
It will use the qualified path defined in one of these parameters: PNLGRP, OBJ, PGM, MODULE
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:
If not specified, use current logic
If specified with a value of *CURLIB, use the active current library (so basically use current logic)
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).
The text was updated successfully, but these errors were encountered:
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:
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):
The above shows:
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:
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).
The text was updated successfully, but these errors were encountered: