Member Lock

[pabloto]

Hi,

I need a suggestion, some colleagues still using SEU 😭, I want to give their VSCode.

We have a validity check program in STRSEU command. This program simple access to a table and write a row with the developer who are editing that source. If another developer try to open that source it receive a message that prevent open it.

Could I simulate this with vscode? Is there the possibility to simulate a validity check program with a codeforI api?

Many thanks

---

⚠️ REMOVE THIS LINE AND ANY SENSITIVE INFORMATION BELOW! ⚠️

Context	Version
Code for IBM i version	2.14.5
Visual Studio Code version	1.95.3
Operating System	darwin_arm64

Active extensions

COBOL (cobol): 24.11.28
Code Spell Checker (code-spell-checker): 4.0.21
Code for IBM i Walkthroughs (vscode-ibmi-walkthroughs): 0.5.0
Configuration Editing (configuration-editing): 1.0.0
Continue - Codestral, Claude, and more (continue): 0.8.61
Db2 for IBM i (vscode-db2i): 1.7.0
Dev Containers (remote-containers): 0.388.0
ESLint (vscode-eslint): 3.0.10
Emmet (emmet): 1.0.0
Error Lens (errorlens): 3.20.0
Extension Authoring (extension-editing): 1.0.0
Git (git): 1.0.0
Git Base (git-base): 1.0.0
Git Graph (git-graph): 1.30.0
GitHub (github): 0.0.1
GitHub Authentication (github-authentication): 0.0.2
GitHub Pull Requests (vscode-pull-request-github): 0.100.3
GitLab Workflow (gitlab-workflow): 5.21.0
GitLens — Git supercharged (gitlens): 16.0.5
IBM i Debug (ibmidebug): 2.0.1
IBM i Project Explorer (vscode-ibmi-projectexplorer): 2.12.0
JSON Language Features (json-language-features): 1.0.0
Live Share (vsliveshare): 1.0.5941
Markdown All in One (markdown-all-in-one): 3.6.2
Markdown Math (markdown-math): 1.0.0
Merge Conflict (merge-conflict): 1.0.0
Microsoft Account (microsoft-authentication): 0.0.1
NPM support for VS Code (npm): 1.0.1
Node Debug Auto-attach (debug-auto-launch): 1.0.0
Postman (postman-for-vscode): 1.5.0
RPGLE (vscode-rpgle): 0.27.0
Source Orbit (vscode-sourceorbit): 1.0.2
TODO Highlight (vscode-todo-highlight): 1.0.5
TypeScript and JavaScript Language Features (typescript-language-features): 1.0.0
WSL (remote-wsl): 0.88.5

---

Remote system

Setting	Value
IBM i OS	V7R4M0
Tech Refresh	10
CCSID Origin	1144
Runtime CCSID	280
Default CCSID	280
SSHD CCSID	?
cqsh	true
SQL	Enabled
Source dates	Enabled

Enabled features

/QOpenSys/pkgs/bin	/usr/bin	/QSYS.LIB	/QIBM/ProdData/IBMiDebugService/bin	/QOpenSys/QIBM/ProdData/JavaVM/jdk80	/QOpenSys/QIBM/ProdData/JavaVM/jdk11	/QOpenSys/QIBM/ProdData/JavaVM/jdk17	/QOpensys/pkgs/lib/jvm
bash	attr	QZDFMDB2.PGM	startDebugService.sh	64bit	64bit	64bit	openjdk-11
chsh	iconv
find	setccsid
git	uname
grep
ls
md5sum
sort
stat
tar
tn5250

Shell env

BUILDLIB=JDET
CURLIB=JDET
HOME=/home/paolos
HOST=directa1.directa.lan
LANG=IT_IT.UTF-8
LIBLS=EMIR YAJLNEW YAJL DIRSAMPLE DEMODAT DEMOSYS ROBERTO PAOLOS CONTRADAT AL400 AL400SYS AL400MNUV2 FIBLIB BETALIB QGPL GESTSIMDAF GESTSIMDAT JDET QTEMP
LOGIN=paolos
LOGNAME=paolos
LS_COLORS=
MAIL=/var/spool/mail/paolos
OLDPWD=/DIRECTA1/home/paolos
PATH=/QOpenSys/pkgs/bin:/QOpenSys/pkgs/lib/nodejs18/bin:/QOpenSys/usr/bin:/usr/ccs/bin:/QOpenSys/usr/bin/X11:/usr/sbin:.:/usr/bin
PS1=\u@\h@\W$
PWD=/home/paolos
QIBM_PASE_CCSID=1208
SHELL=/QOpenSys/pkgs/bin/bash
SHLVL=1
SSH_CLIENT=192.168.0.141 51895 22
SSH_CONNECTION=192.168.0.141 51895 192.168.0.11 22
SSL_CERT_FILE=/home/cacert.pem
TZ=<CET>-1<CEST>,M3.5.0,M10.5.0
USER=paolos
USERNAME=paolos
WORKDIR=/home/paolos
_=/QOpenSys/pkgs/bin/env

Variants

{
  "american": "#@$",
  "local": "£§$",
  "qsysNameRegex": {}
}

[pabloto]

Hi,

Someone can Help me?

Thank you

[sebjulliand]

Hi @pabloto,
in its current state, Code for i and its API won't allow you to reproduce this or even handle any kind of lock.

ALCOBJ would not even be an option since commands executed from SSH are run in non-persistent jobs.
Since Code for IBM i reads members using CPYTOSTMF or SQL if source date support is enabled, I'd say that you might try using exit points to catch if anyone's trying to open a member supposedly locked...

Otherwise, having Code for i to support member locking (without having a way to bypass it) doesn't seem feasible, IMHO.

[SJLennon]

@sebjulliand
By way of discussion: It looks to me that this request could be satisfied to prevent simultaneous updating. This might be of value to those shops that don't have a source control system and/or make ad-hoc, unsynchronized changes.

1. You would need to optionally allow a call to a user supplied program on the IBM i.

2. User supplied program would be passed the user id; source library/file/member; and an action flag, either open or close.

3. Program is called by the extension before a member is opened and after it is closed.

4. How the program operates is of no concern to the Code for i extension and is solely the responsibility of the users.

   a. If action is open, the program is responsible for implementing whatever protection is desired on the server, and returning 'Y' if the source can be opened (in this user's case, it would write a record to the controlling table on the IBM i), otherwise return 'N'. The Code for i extensions would either open the source or display "Open blocked by library/program" or "library/program says source is in use" or something similar.

   b. If action is close, the program is responsible for removing whatever protection is in effect of the server (in this user's case, it would delete the record in the controlling table on the IBM i) and return 'Y' (though this could be ignored...).

If this approach is workable, it puts the responsibility back on those shops who don't follow generally accepted best practices. IFS wouldn't need to be considered because such shops are unlikely to be using the IFS for source.

[sebjulliand]

I agree with you @SJLennon, that would probably be the best way to offer the possibility to implement a lock mechanism.
That setting would need to be saved somewhere on the LPAR (so users can't opt in or out from VS Code)...could be a data area located in a library (the lock would be scoped to that library) or an environment variable at *SYS level to make the lock system-wide.

[joelcamacho97]

I have been looking into this problem because we have the same requirement in our environment, but I do not see this as something specific to one shop only.

The key point, from my perspective, is that this is really about IBM i job context, not about implementing one particular custom dependency or one specific lock policy inside the extension.

For example, with ALCOBJ, if the allocation is created in one job and that job ends, the allocation is released. If a later action runs in a different job, that new job does not inherit control of the previous allocation or its context. So for workflows like this, running related commands in the same IBM i job is essential.

That matters for lock-like scenarios, where the system must know who is allowed to edit and who is not, but it also applies more generally to any workflow where job-scoped context must be preserved across separate actions. That can include:

• object allocations such as ALCOBJ/DLCOBJ
• server-side validation/open/close programs
• temporary state kept in the job
• information stored in job memory or other job-scoped resources
• any sequence of actions where later commands must continue in the same execution context

Because of that, I think the missing capability is not a built-in lock mechanism, but an optional way to run related ILE actions in the same persistent job while the Code for IBM i connection remains active.

I have been prototyping exactly that: an optional persistent ILE job mode, scoped to the active connection. With that in place, multiple commands can run in the same IBM i job for the duration of the connection. This makes it possible to support custom shop-specific workflows such as:

• calling a validation/open program before editing
• calling a close/unlock program afterwards
• using ALCOBJ/DLCOBJ or similar mechanisms
• preserving server-side job context between separate actions

This does not try to implement a lock policy directly in Code for IBM i, and it does not force any specific locking model on users. It only provides the execution model needed for IBM i workflows that depend on job continuity.

I also had to account for save operations, because if edit/open runs in a persistent job but save runs in a different job, the workflow breaks. In the prototype, when a persistent action session is active, member save can also use that same persistent job.

Another important point is that, once this capability exists in the extension, anyone who needs a specific locking workflow could build a companion extension on top of the Code for IBM i API. That companion extension could implement the kind of lock requested in this discussion, but it could also support many other job-context-based workflows.

To me, that is a strong advantage: people could extend the behavior they need without forking this project, while staying aligned with the main Code for IBM i codebase and contributing to a shared path of growth and development in VS Code.

So from my point of view, this is not about adding a built-in lock manager. It is about providing an optional same-job execution capability that can support locking workflows, but also any other workflow that depends on job-scoped state or in-memory context.

If this direction makes sense, I can prepare a PR.