Debug using wrong current library

[SanjulaGanepola]

When trying to debug a program, I noticed there are a few issues with debug in relation to using the wrong current library:

Scenario 1: Debug from active editor

When debugging the local file mypgm.pgm.rpgle in the active editor from ibmi-company_system which I have built into the library WDSCTEST, I get an error message that the object does not exist. Since I have the CURLIB variable in my .env file set to WDSCTEST, I would expect it to check here, but when debugging the extension I see that it is checking the current library that is set in the User Library List view -> https://github.com/codefori/vscode-ibmi/blob/master/src/api/debug/index.ts#L161. I see that later on we do try to get the current library from the CURLIB env var but it does not get to that point since it fails at the previous spot -> https://github.com/codefori/vscode-ibmi/blob/master/src/api/debug/index.ts#L63

Scenario 2: Debug from Project Explorer

When IBM i Project Explorer calls the code-for-ibmi.debug command, it is not able to pass in the workspace folder which is an issue because it fails the check here to get the CURLIB from the project's .env file. One option would be to allow this API to accept a workspaceFolder. However, one thing I was wondering was why the library list and current library are needed for the SBMJOB command in the first place?

Context	Version
Code for IBM i version	2.10.2
Visual Studio Code version	1.89.1
Operating System	win32_x64

Active extensions

``` Code for IBM i Walkthroughs (vscode-ibmi-walkthroughs): 0.5.0 Db2 for IBM i (vscode-db2i): 1.0.0 Emmet (emmet): 1.0.0 Extension Authoring (extension-editing): 1.0.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 IBM i Debug (ibmidebug): 1.0.0 IBM i Project Explorer (vscode-ibmi-projectexplorer): 2.10.4 JSON Language Features (json-language-features): 1.0.0 Merge Conflict (merge-conflict): 1.0.0 NPM support for VS Code (npm): 1.0.1 Node Debug Auto-attach (debug-auto-launch): 1.0.0 TODO Highlight (vscode-todo-highlight): 1.0.5 TypeScript and JavaScript Language Features (typescript-language-features): 1.0.0 WCA@IBM (wca-at-ibm): 6.3.0 WSL (remote-wsl): 0.88.2 ```

---

Remote system

|Setting|Value| |-|-| |IBM i OS|n/a| |Tech Refresh|n/a| |CCSID Origin|undefined| |Runtime CCSID|37| |Default CCSID|37| |SQL|Enabled |Source dates|Disabled ### Enabled features |/QOpenSys/pkgs/bin|/usr/bin|/QSYS.lib/ILEDITOR.lib||/QSYS.LIB|/QIBM/ProdData/IBMiDebugService/bin| |-|-|-|-|-|-| |bash|attr|GETNEWLIBL.PGM|ILEDITOR.GETMBRINFO|QZDFMDB2.PGM|startDebugService.sh| |chsh|iconv||||| |git|setccsid||||| |grep|||||| |ls|||||| |md5sum|||||| |sort|||||| |stat|||||| |tar|||||| |tn5250||||||

Shell env

```bash BUILDLIB=QGPL CURLIB=QGPL HOME=/home/SANJULA HOST=p8adt05.rch.stglabs.ibm.com LIBLS=QTEMP QGPL TESTTOOLS LOGIN=sanjula LOGNAME=sanjula MAIL=/var/spool/mail/sanjula OLDPWD=/home/SANJULA PATH=/QOpenSys/pkgs/bin:/QOpenSys/usr/bin:/usr/ccs/bin:/QOpenSys/usr/bin/X11:/usr/sbin:.:/usr/bin: PWD=/home/SANJULA SHELL=/QOpenSys/pkgs/bin/bash SHLVL=1 SSH_CLIENT=9.67.181.225 54012 22 SSH_CONNECTION=9.67.181.225 54012 9.5.12.241 22 TZ=0 USER=sanjula USERNAME=sanjula WORKDIR=/home/SANJULA _=/QOpenSys/pkgs/bin/env ```

Variants

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

Errors

```json [ { "command": "/QOpenSys/usr/bin/qsh", "code": 1, "stderr": "CPF2111: Library ILEDITOR already exists.", "cwd": "/home/SANJULA" } ] ```

[mkwan01]

Sanjula points to an issue in line 485 of vscode-ibmi/src/api/debug/index.ts:

"startBatchJobCommand": SBMJOB CMD(${currentCommand}) INLLIBL(${options.libraries.libraryList.join( )}) CURLIB(${options.libraries.currentLibrary}) JOBQ(QSYSNOMAX) MSGQ(*USRPRF) CPYENVVAR(*YES),

The problem Sanjula observed is likely to be triggered by the use of the CURLIB parameter in the SBMJOB command line. The CURLIB and INLLIBL parameters are not used in the RDi debug scenario, please evaluate whether these parameters are really needed.

[edmundreinhardt]

@mkwan01 Morris, let me just be clear. When doing the SBMJOB, the CURLIB parameter is setting the CURLIB, which will have the effect of sett the CURLIB for the job being debugged. If the RPG program being debugged has LIBL qualified files it is referencing, then this will be critical for the correct execution/debugging of the target program. Why do you think it is not relevant?

[mkwan01]

@edmundreinhardt The CURLIB parameter is not used at the debug level. The RDi debug code path does not set this parameter in SBMJOB when starting a debug session. As Sanjula indicated that the problem he observed may come from the CURLIB setting, we will let Liam decide whether there is a reason to keep the CURLIB parameter in the command line.

[sebjulliand]

@SanjulaGanepola for scenario 1, the current process tries to get the type of the object being debugged to ensure it is a *PGM or *SRVPGM. The check is done using an SQL query. Can you check what you have in your Code for i output when you see the error message from your screenshot? (it should look like this: https://github.com/codefori/vscode-ibmi/blob/master/src/api/debug/index.ts#L127 - maybe the library is wrong here somehow?) If this check passes, then the debug process can carry on (and it should use the values from your .env file afterwards).

For scenario 2, I think the code-for-ibmi.debug command must be updated to allow a workspace folder to be passed as a parameter.

And both CURLIB and INLLIBL will remain in the SBMJOB command. Submitting a program call without these would make absolutely no sense, as stated by @edmundreinhardt . Qualifying files in RPG programs is a bad practice and is usually avoided; it defeats the purpose of having a library list.

@mkwan01 since RDi probably runs SBMJOB from the persistent command job started from RSE, that would explain why it doesn't set CURLIB and INLLIBL, as they are inherited from the submitting job (hopefully they are, else you may have a problem here 😅). Generally, I guess RDi debug code path won't be relevant when compared to Code for i's since they don't connect the same way to an LPAR.

[SanjulaGanepola]

In the output channel, I can see that the current library is incorrect (it uses the current library from the connection settings instead of .env file):

/home/WDSCTEST: LC_ALL=EN_US.UTF-8 system "call QSYS/QZDFMDB2 PARM('-d' '-i' '-t')"
CREATE TABLE QTEMP.O_LJICK AS (select OBJTYPE from table(qsys2.object_statistics('QGPL', '*PGM *SRVPGM', 'MYPGM')) X) WITH DATA;
Call QSYS2.QCMDEXC('CPYTOIMPF FROMFILE(QTEMP/O_LJICK *FIRST) TOSTMF(''/tmp/vscodetemp-O_TBGiTC4G'') MBROPT(*REPLACE) STMFCCSID(1208) RCDDLM(*CRLF) DTAFMT(*DLM) RMVBLANK(*TRAILING) ADDCOLNAM(*SQL) FLDDLM('','') DECPNT(*PERIOD)')
{
    "code": 0,
    "signal": null,
    "stdout": "DB2>\nDB20000I  THE SQL COMMAND COMPLETED SUCCESSFULLY.\nDB2>\n  ?>\nDB20000I  THE SQL COMMAND COMPLETED SUCCESSFULLY.",
    "stderr": ""
}

The problem seems to actually be because of the getObjectFromUri function returning the wrong library. In the case of a file schema, I see we are using configuration.currentLibrary. Instead we should be checking here for the CURLIB env var like we do here?

[mkwan01]

@sebjulliand I am OK to have these parameters in the SBMJOB command, as far as the issue found by Sanjula would be addressed.

[sebjulliand]

@SanjulaGanepola I did the job to get this working (hopefully).

There are two PRs that needs to be applied:

• https://github.com/codefori/vscode-ibmi/pull/2079 (for which a build is attached in the PR)
• https://github.com/IBM/vscode-ibmi-projectexplorer/pull/478

I guess the best way to test it is to install the build from #2079 and then run https://github.com/IBM/vscode-ibmi-projectexplorer/pull/478 in debug mode.