SEP issue when the host QB5PHSRV job is terminated

[mkwan01]

Here is the original user scenario:

1. Use VSCode to do SEP debug
2. Switch to RDi to run SEP debug
3. Switch back to VSCode to do SEP debug

Detailed steps to for #1 (SEP Debug in VS Code):

• Connect to the LPAR from VS Code.
• Set the Service Entry Point (SEP) on the program testdbg.sqlrpgle.
• Call the program from the 5250 session.
• The debug session starts in VS Code. Allow the program to run.
• Remove the SEP after the program has been executed.
• Disconnect from the LPAR.

Detailed steps for #2 (SEP Debug in RDi):

• Connect to the LPAR from RDi.
• Set the Service Entry Point (SEP) on the same program testdbg.sqlrpgle.
• Call the program from the same 5250 session.
• The debug session starts in RDi. Allow the program to run.
• Remove the SEP after the program has been executed.
• Disconnect from the LPAR.

Once the above steps are completed in RDi, the user then repeats the same debugging steps in VS Code.

Expected Behavior:

The debug session should launch successfully and allow me to debug the program within VS Code, just as it works earlier.

Actual Behavior:
The debugger does not enter debug mode in VS Code.
Upon recompiling the program and attempting to refresh the SEP, it is reported as invalid and subsequently removed.

[mkwan01]

I have done a deeper investigation on the issue. The problem is related to how we manage the mapping between the SEP client connection and the QB5PHSRV job on the host.

We have one QB5PHSRV job per user. When the user creates the first SEP from the VSCode client, a new QB5PHSRV job is started on the host. The VSCode client SEP connection is mapped to this QB5PHSRV job. When the user switches to the RDi client later, RDi will start its own QB5PHSRV job and terminate the old QB5PHSRV job started by VSCode (we can only have one QB5PHSRV job per user). Later when we switch back to the VSCode client, because the debug service is always running, it is not aware that the old QB5PHSRV job that it started before is already terminated. SEP operations will not function correctly when the VSCode client tries to delegate the SEP requests to an in-existent QB5PHSRV job.

[mkwan01]

The fix is to save the QB5PHSRV job number in the client SEP map, and check whether this particular QB5PHSRV job still exists for some SEP operations. If the job is no longer running, then we need to start a new QB5PHSRV job to handle the subsequent SEP requests.

[mkwan01]

Issue #35 is a different variation of the same problem.