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.