Add support for member locking

[SanjulaGanepola]

Changes

This PR adds support for member locking using a shared-update lock (*SHRUPD) that is allocated on reads and deallocated when we close the editor. This is an opt in setting meaning it is disabled by default.

This has been requested in #1688 and #2409

How to test this PR

1. Debug the extension using this branch.
2. Navigate to the connection settings and enable Member Locking under the Source Code tab.
3. Open a member.
4. Launch a separate VS Code window running the release version of Code4i.
5. Attempt to open the same member in this new window and observe the member is locked.
6. In the first window, disable the setting.
7. In the second window, reattempt to open the member and observe that it can be opened.

Checklist

• have tested my change
• have created one or more test cases
• updated relevant documentation

[github-actions]

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

• Download here.
• Read more about how to test

[SanjulaGanepola]

@codefori/core Before proceeding with more testing of this PR, any major issues with support member locking?

[buzzia2001]

Hi @SanjulaGanepola,
There is something that is not ok for me...
With *SHRRD any other job can take a lock for that specific member and in that case I'm not able to change it from vscode:

In my example I've opened a member from vscode (job 682461/QUSER_NC/QZDASOINIT) and from a 5250 session with the same command:

Now, if I change a row and I try to save it, it doesn't work because the member is locked by my other job:

My suggestion is to use EXCLUSIVE_ALLOW_READ instead of SHARED_UPDATE. In this way, we can be sure that no one can steal our lock.

---

Another issue I had is that the object is locked even if I'm not connected anymore:

Without Mapepire, my suggestion is to use *THREAD instead of *JOB in lock scope. In this way, when your connection end, the thread is closed and the lock released. But with Mapepire is not so easy, it seams that the lock survive also to the client disconnection. We need to analyze better this issue.

---

Currently, there are no safeguards in place when opening members with defined locks; this means that a user can open a member, attempt to modify it, and then get stuck when trying to save... Ideally, you should check for locks before opening the member, so that it opens in view-only mode if locks already exist. You could manipulate the WRKOBJLCK spool or use the SQL service, but be careful not to make this operation take too long...

---

At the moment I can't see anything related to IFS, anyway I think that also IFS should be covered (IDK idf in this pr or in another one).