Locking the source on the IBMi while editing in Code for IBM i

[christianlarsen]

I am trying to introduce "Code for IBMi" in my company, and one of the problems that I am reporting is that, while someone is using a source code with another IDE (RDI, SEU...), other people can open and modify the same source with VSCode. And that is not good..., because it can cause errors, code deletion, etc...

I don't know if there is a way to do this, but it would be great to be able to lock the source when editing it using Code for IBMi, so that no one could touch it in the meantime...

Thank you!

[worksofliam]

We have this discussion every once in a while, but it is likely impossible for us to implement locking due to the way jobs are managed and the way source is opened.

Cc @codefori/core any creative ideas?

[christianlarsen]

Well, when you are using RDi, it is copying the source you are editing into your own computer... and it is locking the source, so nobody can open it for editing... and when you are saving the source, it is copying it from your computer to the IBMi ...

It can be made with an ALCOBJ for the file QRPGLESRC (for example) and the member....

The problem is when you are trying to save your changes, it has to deallocate the file, save it, and allocate it again... so between those operations, someone can try to open it, and allocate it ... so you will get an error....
But I know that in my team, some people has been having problems with this in RDi, too ... and I think that is because of lost connections... and so on....

I dont know if this is an idea for you, or a problem. :-D

[Wright4i]

We have this discussion every once in a while, but it is likely impossible for us to implement locking due to the way jobs are managed and the way source is opened.

Cc @codefori/core any creative ideas?

Sure here's a crazy idea: Would it be possible to detect the source has changed and auto open a diff?

I seriously doubt we could get the magical git 3way merge diff, but even just being able to communicate the changes to the user when they save and offering to commit(replace) or rename would probably be a big QOL upgrade.

IMHO I don't think it's worth trying to get locking working in the same way RDi does as the headache of locks lingering unintentionally due to network drops/closed vscode sessions, etc. would introduce even more problems.

[beckhamrryyaann]

just another benefit of local development with git. Even if the team were able to solve this, this sounds more like a development strategy problem. At the very least the source should be "checked out" if the source is be developed on by a developer so the team knows its off limits.

[christianlarsen]

IMHO I don't think it's worth trying to get locking working in the same way RDi does as the headache of locks lingering unintentionally due to network drops/closed vscode sessions, etc. would introduce even more problems.

Okay, yeah... it may not be the best option.

But... I think something like this should be implemented, at least until there is a better option. Most RPG programming users today use RDi and SEU (although it may seem incredible, they still use it massively...)
Moving towards using another environment, like VSCode, which I personally think is fantastic, is much more complicated when things like blocking a source while someone uses it (something that, using SEU, you already have), is something necessary, and I would say , essential.

[sebjulliand]

The main problem is any command that's run from VSCode goes through SSH but it's not run in a job that persists. Running ALCOBJ in this context doesn't work since: the command job gets spawned, the command runs, the job ends.

I guess there might be a way using an SQL procedure in an SSH channel dedicated to locking members, but we'd need one channel per member and kill them whenever the member needs to be saved.

I completely understand why this should be implemented but for now, technically, we may end up developing a Rube Goldberg machine 😅