Removed netstat_job_info calls

[sebjulliand]

Changes

This PR removes the queries to netstat_job_info as it requires *IOSYSCFG special authority since 7.6.
It was used to retrieve the debug server and service job information.

The queries are replaced by queries to job_info, using the service and server job names (as they are not supposed to change).

Finally, a direc call to updateConnectedBar has been removed as it turns out it's already called twice when the user connects (indirect calls).

How to test this PR

1. Connect
2. Check the debugger status
3. Ensure debug service can't be started from Code for i anymore
4. Check that the service status is correctly updated once started/stopped from iNav and refreshed in Code for i

Checklist

• have tested my change

[github-actions]

👋 A new build is available for this PR based on bc9e138.

• Download here.
• Read more about how to test

[worksofliam]

@SanjulaGanepola @mkwan01 any chance one of you can test this PR? Neither @sebjulliand or I have a debug service working. It requires a 7.6 vm.

[mkwan01]

Our 7.6 machine requires an update to the Navigator. I will test the changes after the update.

[SanjulaGanepola]

The PR also removes the start/stop actions on the Debug Service item in the IBM i Debugger view as it's now iNav reponsibility to manage the debug service.

@sebjulliand While this is true, I personally like having the stop/start actions in VS Code for convenience. If we do want to still promote users to use iNav instead for this, can we add a VS Code Setting to enable these options (can be disabled by default)? What do you think?

Unless there is in fact a difference in how it is started in iNav vs VS Code?

[mkwan01]

@sebjulliand @SanjulaGanepola I also prefer to keep the start/stop actions, as it is more convenient to do everything inside VS Code, without switching to a Navigator browser. I am OK if this is controlled by a setting and it is disabled by default.

[sebjulliand]

@SanjulaGanepola @mkwan01 fair enough, I've put the start/stop actions back.
Back to you for approval. Thanks 😄

[SanjulaGanepola]

When testing this out, I noticed that there were constant calls to updateConnectedBar. One issue is that we are doing:

onCodeForIBMiConfigurationChange("connectionSettings", updateConnectedBar)

which means any time the user adds a filter, or really does a lot of the core tasks, we are going to constantly call isDebugEngineRunning which is overkill imo.

[sebjulliand]

which means any time the user adds a filter, or really does a lot of the core tasks, we are going to constantly call isDebugEngineRunning which is overkill imo.

@SanjulaGanepola yes, totally. We should address that in a separate PR.

[mkwan01]

@sebjulliand I just tested a Code for IBM i driver with the latest changes (code-for-ibmi-2.18.3-dev.0.vsix). I noticed that starting the debug service is much faster than before. However, I am seeing an intermittent status refresh problem in the IBM i Debugger view.

Here are the steps to reproduce the problem:

1. Start debug service from the IBM i Debugger view
2. After debug service is started, click on the square stop button to stop debug service
3. When the status of debug service is changed to "Stopped" (with the red 'X'), press the start button (the arrow) to start debug service
4. Repeat step 2 and 3 a few times
5. We will finally get the following error message after hitting the start button:

[mkwan01]

@sebjulliand If we refresh the IBM i Debugger view after error messages appear, the status of the debug service is updated to "started" (a green check mark), which means there is no startup failure. I think the error message could be triggered by a timing issue. We may be checking the status too early, before debug service is fully started.

[sebjulliand]

@mkwan01 @SanjulaGanepola since netstat_info can't be used anymore to check the debug service status, we need another way to check the actual status of the service (hence why it seems to start faster than before: we return ok when the submitted job is started which is very fast, but doesn't mean the Java process actually started and keeps on running).

So what would be the best way to ensure the service is running? Any idea is welcome.

[mkwan01]

@sebjulliand Can Code for IBM i client retrieve a host job by filter? If it has this capability, you can search for the job "*/QDBGSRV/QP0ZSP??", where the job user is QDBGSRV, and the job name starts with "QP0ZSP", followed by two other arbitrary characters. If this job is found, then debug service is started. The underlying Java process normally takes 10-15 seconds to start up. If you do not find it at the beginning, you can repeat the search for up to 30 seconds.

[mkwan01]

@sebjulliand We also have another way to check the debug service status.

Debug service is started correctly if

1. The IFS file /QIBM/UserData/IBMiDebugService/startDebugService_workspace/startDebugServiceNavigator.log has a newer modified or creation timestamp than the time the user clicks on the Start button, which means it has up-to-date contents for the current startup instance.
2. The startDebugServiceNavigator.log file contains the following string contents:
   EQARD1007I The Remote Debug Service daemon started on port 8001.
   EQARD1053I The Remote Debug Service daemon started on secured port 8005.

Please note that the two port numbers 8001 and 8005 are configurable. Since the message ID is unique for each message, you can check for the two message IDs EQARD1007I and EQARD1053I. If they appear in the startDebugServiceNavigator.log file, then the debug service is started correctly. Since the startup can take some time, the strings may not be there at the first check, we need to repeat the check for up to 30 seconds.

[mkwan01]

@sebjulliand I am OK if you want to implement a new status check solution for debug service in a different PR. If that is the case, we can approve this PR first, and give you more time to think about how to address the status check issue later.

[sebjulliand]

Thank you very much @mkwan01 , this was insightful 😄
I pushed a change to now look for the QP0ZSP* kind of job for the Debug Service.

Let me know how it goes; thanks! If it fails, I'll implement the debug log ckech instead.
We'll try to sort this out in this PR, if possible 😉

[mkwan01]

@sebjulliand I just tested a build (dated 2026-02-12). I can see that the debug service job name is updated to the QP0ZSP* job in the view. I am still seeing an intermittent startup error like this:
Debug Service job 193947/QDBGSRV/QDBGSRV failed: job has ended.

If I refresh the IBM i Debugger view after the error, the debug service status is updated a green check mark.

I think the error message may be triggered by a defect in another place. The error message points to a debug service job like "193947/QDBGSRV/QDBGSRV". However, the real debug service job is the QP0ZSP* job. You can investigate how and when this message is raised, and see whether there is a potential issue in the code related to this error.

[sebjulliand]

Thanks for the feedback @mkwan01 !
I made some changes and now the debug service start routine will:

• Check if the submitted job started
• If found, look for the QP0ZSP* job
• Once found, check if the debug and SEP ports are opened
• If the QP0ZSP job dies in the meantime, show an error and offer to open the debug service log file

I could't test it through and through since I don't have access to an LPAR with an updated debug service. But I could check that the routine failed as expected.

I'll let you validate it once more on your LPAR. Thanks!

[mkwan01]

@sebjulliand I just tested a Code for IBM i build dated 02-13, which should include the latest changes. The new driver has more problems than the previous one. After starting the debug service, I can see the following from the Code for IBM i output channel:

Running SQL query: select 'SERVER' as TYPE, JOB_NAME from table(QSYS2.ACTIVE_JOB_INFO(JOB_NAME_FILTER => 'QB5ROUTER')) Union select 'SERVICE' as TYPE, JOB_NAME from table(QSYS2.ACTIVE_JOB_INFO(JOB_NAME_FILTER => 'QP0ZSP*')) where JOB_USER = 'QDBGSRV'
-> 2 row(s) returned

Although the query seems to return a result with 2 rows, we continue to see "Starting debug service..." in the status bar and the status of the debug service is never updated in the IBM i Debugger view.

Here is a screen capture:

[mkwan01]

When I manually run the same SQL query from ACS, it returns the following two rows:

SERVICE | 194969/QDBGSRV/QP0ZSPWT
SERVER | 193101/MKWAN/QB5ROUTER

[SanjulaGanepola]

What is the status of this PR (aka should I give this a try again)?

[sebjulliand]

What is the status of this PR (aka should I give this a try again)?

@SanjulaGanepola yep, if you can give it a try that would be great. I don't have an LPAR with a working service at my disposal right now 🥴