Closed benetti-smeup closed 2 years ago
Correct. There is no concept of 'member locking' like RDi and SEU have. This is due to the way we are connecting to the system.
Not sure how to combat this right now.
I see. Wouldn't it be possible to mitigate the problem with a message in the event of a concurrent change? assuming that it is possible to identify the cases.
I think that could be an easy one. But it needs to be tested very well to prevent dead locks. @benetti-smeup goes in the right direction.
I propose the following solution:
But it's very important that number 3 and 5 is working very well. Otherwise you'll suffer from very bad deadlocks.
I would also suggest that the changes in VS Code are always compared with the original member before opening and before saving. Then it works also very similar to SEU.
What do you think?
@szsascha that's how ILEditor 1 used to work, since it only had a single connection (FTP)
Allocate the member to the VS Code job (Or maybe thread? Not pretty sure atm. It's depending on the connection handling in VS Code. I'm not so deep into it atm.)
This is where it gets complex. vscode-ibmi has many jobs. One connection job, which ILE commands do not run in. To run ILE commands, we have to use the system command, which runs in it's own job.
Kinda tricky.
Thoughts on identifying if a change has been been made.
if db2Util is installed you can use SQL. When you open the source you can get the last changed timestamp with SQL, though it is only good to the second. When you save the source, you check if this timestamp has changed. If it has, some action, yet to be determined, is triggered.
For a source PF member I believe you can get the changed time stamp with SQL like this:
SELECT LAST_SOURCE_UPDATE_TIMESTAMP
FROM qsys2.SYSPARTITIONSTAT
WHERE table_schema = 'LENNONS1'
AND table_name = 'TEMP'
AND table_partition = 'MBRINF';
According to IBM.COM this goes back to 7.1.
For an IFS file, SQL like this:
SELECT data_change_timestamp
FROM TABLE (
QSYS2.IFS_OBJECT_STATISTICS(START_PATH_NAME => '/home/lennons/test.js')
) AS t;
But I couldn't find IFS_OBJECT_STATISTICS on 7.2 on IBM.COM so looks like at least 7.3 is needed.
@worksofliam @benetti-smeup @szsascha
Maybe the best option would be to reduce the default lock time for the job that does the file open? I mentioned this in 323.
@ChrisHird The way this is architected isn't the same as RDi or SEU - we don't have a mechanism to lock a member - though we can likely check if one is locked before opening it.
Liam,
Maybe its just a case of getting the lock message back quicker? I was clicking the member constantly thinking It was not picking up the request in the IDE, but it obviously was because the lock message was returned after 30 seconds. My suggestion is to change the remote job so it has a default wait time for locks of say 1 second, that way the message about a failure to get the copy would be returned a lot faster. 2 ways to do that, 1. Have the job when its launched run under job description that has the default wait time set to the relevant value (Another possible option for the user based variables??) or have the job changed once it has been started to change the job attribute setting for the default wait time.
I am not sure where to look in the code for the connection request, but will attempt to take a look tomorrow (I know it’s a SSH connection request and I see the 2 jobs running under QUSRWRK) and maybe offer my 2 cents for what its worth once I see that.
Chris…
From: barry @.> Sent: September 23, 2021 6:10 PM To: halcyon-tech/vscode-ibmi @.> Cc: Chris Hird @.>; Mention @.> Subject: Re: [halcyon-tech/vscode-ibmi] Concurrent modification of a member (#217)
@ChrisHirdhttps://github.com/ChrisHird The way this is architected isn't the same as RDi or SEU - we don't have a mechanism to lock a member - though we can likely check if one is locked before opening it.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/halcyon-tech/vscode-ibmi/issues/217#issuecomment-926197661, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AELHN4NBW5WA53UE7UM4AR3UDOQSDANCNFSM5AVQOJ5Q. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
This is where that error is likely happening: https://github.com/halcyon-tech/vscode-ibmi/blob/master/src/filesystems/qsys/basic.js#L36
Would be interested in your feedback or PR.
Liam,
Possible solution.
I am not sure how you manage the connections or if you spawn new jobs from the original connection, but the same process would run if necessary?
Does that make sense?
Chris…
From: barry @.> Sent: September 23, 2021 6:37 PM To: halcyon-tech/vscode-ibmi @.> Cc: Chris Hird @.>; Mention @.> Subject: Re: [halcyon-tech/vscode-ibmi] Concurrent modification of a member (#217)
This is where that error is likely happening: https://github.com/halcyon-tech/vscode-ibmi/blob/master/src/filesystems/qsys/basic.js#L36
Would be interested in your feedback or PR.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/halcyon-tech/vscode-ibmi/issues/217#issuecomment-926212535, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AELHN4KLY2WVB52YFEROQC3UDOTXXANCNFSM5AVQOJ5Q. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
I am not sure that will work.
When running ILE commands (CPYTOSTMF
), we use system
, which is forking the connection job and running in that I believe. I am not sure the CHGJOB
will actually have any effect.
Just to add, getting the error is not a problem, its waiting the 30 seconds to see it appear which I think should be addressed. Because you are using CPYSTMF to do the copy its always going to be a problem because it requires the lock to do its work, only other alternative would be to use a new command that does the same thing but allows a read only with no lock (I do it under some circumstances in our HA replication process when an IFS file is locked and a copy needs to be created).
From: barry @.> Sent: September 23, 2021 6:37 PM To: halcyon-tech/vscode-ibmi @.> Cc: Chris Hird @.>; Mention @.> Subject: Re: [halcyon-tech/vscode-ibmi] Concurrent modification of a member (#217)
This is where that error is likely happening: https://github.com/halcyon-tech/vscode-ibmi/blob/master/src/filesystems/qsys/basic.js#L36
Would be interested in your feedback or PR.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/halcyon-tech/vscode-ibmi/issues/217#issuecomment-926212535, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AELHN4KLY2WVB52YFEROQC3UDOTXXANCNFSM5AVQOJ5Q. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Hmmm maybe that will be an issue I can do some testing as we use system in a number of cases. I would have thought the request is still run within the same workspace, but never looked that closely. Will let you know what I find? Just thinking allowed, but system should not get forked away from the workspace because it uses the current workspace users security???
Anyhow that will be clearer once I have run some tests 😊
From: barry @.> Sent: September 23, 2021 7:04 PM To: halcyon-tech/vscode-ibmi @.> Cc: Chris Hird @.>; Mention @.> Subject: Re: [halcyon-tech/vscode-ibmi] Concurrent modification of a member (#217)
I am not sure that will work.
When running ILE commands (CPYTOSTMF), we use system, which is forking the connection job and running in that I believe. I am not sure the CHGJOB will actually have any effect.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/halcyon-tech/vscode-ibmi/issues/217#issuecomment-926223308, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AELHN4PQIIKYBQHDQM5JZ63UDOW6BANCNFSM5AVQOJ5Q. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Further note: your suggestion will only work when source dates are disabled (default). When enabled, we fetch the member with SQL.
But how does the SQL get launched (via the ssh job?) if so the same principle applies? And maybe the SQL fetch is not affected? (I have not tried it).
From: barry @.> Sent: September 23, 2021 7:10 PM To: halcyon-tech/vscode-ibmi @.> Cc: Chris Hird @.>; Mention @.> Subject: Re: [halcyon-tech/vscode-ibmi] Concurrent modification of a member (#217)
Further note: your suggestion will only work when source dates are disabled (default). When enabled, we fetch the member with SQL.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/halcyon-tech/vscode-ibmi/issues/217#issuecomment-926225863, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AELHN4OIM5HN4KVVG2JFZHTUDOXTPANCNFSM5AVQOJ5Q. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
We use db2util
under the covers, which runs in the same ssh connection we get - so no new job for running SQL.
I disabled db2util (its not installed) and set the embedded dates flag (I think that forces the SQL request?? Or that’s what I read on the settings page) and it still took 30 seconds to respond..
I will play with the system command locally to see if changing my job environment affects it?
From: barry @.> Sent: September 23, 2021 7:13 PM To: halcyon-tech/vscode-ibmi @.> Cc: Chris Hird @.>; Mention @.> Subject: Re: [halcyon-tech/vscode-ibmi] Concurrent modification of a member (#217)
We use db2util under the covers, which runs in the same ssh connection we get - so no new job for running SQL.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/halcyon-tech/vscode-ibmi/issues/217#issuecomment-926227058, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AELHN4ITBZ6P3VUCVSDEYE3UDOX6RANCNFSM5AVQOJ5Q. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Source dates are disabled when SQL is not enabled.
Liam, Simple test I ran showed that system does not fork outside the current workspace.
int main(int argc, char **argv) { char cmd[3000];
sprintf(cmd,"CPYTOSTMF FROMMBR('/QSYS.LIB/NAG4I10SRC.LIB/QCSRC.FILE/NA4I000.MBR') TOSTMF('/home/chrish/nag4i001.c') STMFOPT(*ADD)"); if(system(cmd) != 0) { printf("failed to copy\n"); } return 1; }
This is for a member that I have opened in RDi. I ran the program with no changes to the default job settings and it took 30 seconds for the command to fail, I then updated my job using the same commands described previously so the default wait time would now be 1 second, the request returned the lock message almost immediately, so I think it would work in your circumstances.
I cannot test the SQL stuff because I do not have db2util installed..
Chris..
From: barry @.> Sent: September 23, 2021 7:04 PM To: halcyon-tech/vscode-ibmi @.> Cc: Chris Hird @.>; Mention @.> Subject: Re: [halcyon-tech/vscode-ibmi] Concurrent modification of a member (#217)
I am not sure that will work.
When running ILE commands (CPYTOSTMF), we use system, which is forking the connection job and running in that I believe. I am not sure the CHGJOB will actually have any effect.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/halcyon-tech/vscode-ibmi/issues/217#issuecomment-926223308, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AELHN4PQIIKYBQHDQM5JZ63UDOW6BANCNFSM5AVQOJ5Q. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
@ChrisHird We are not using the system
API, we are using the system
command from pase.
https://www.ibm.com/docs/en/i/7.3?topic=utilities-pase-i-system-utility
Read the -i
parameter.
I still think it will work the same as the both map over the same program under the covers. If not it might be a simple case of deciding which parameters force the job attributes to be set when the request is spawned. Bit late now but tomorrow I will create a request the run under PASE and see what if any differences there are? I have a feeling ( or maybe that’s hope) this should return the same result???
Sent from my iPhone
From: barry @.> Sent: Thursday, September 23, 2021 7:41:20 PM To: halcyon-tech/vscode-ibmi @.> Cc: Chris Hird @.>; Mention @.> Subject: Re: [halcyon-tech/vscode-ibmi] Concurrent modification of a member (#217)
@ChrisHirdhttps://github.com/ChrisHird We are not using the system API, we are using the system command from pase.
https://www.ibm.com/docs/en/i/7.3?topic=utilities-pase-i-system-utility
Read the -i parameter.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/halcyon-tech/vscode-ibmi/issues/217#issuecomment-926241310, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AELHN4KVLP3OM7WUBES3TLDUDO3KBANCNFSM5AVQOJ5Q. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Sure, feel free to run any tests as you wish.
Moral of the store is that running these commands will have no affect on the wait time:
system "CHGJOB DFTWAIT(1)"
system "CPYTOSTMF ..."
OK, I ran a test as below.
Moral of the tale, if the terminal environment is called from a job that has the default wait time set to something other than default then that setting is in effect when any commands are run in the terminal. Setting the job attributes while in the terminal session has no effect! I would think this would be the same for the remote command request??? Problem will be how that connection is made and if it can be manipulated to set the attribute… I am sure there is a way to work around this, just a question of figuring it out.
I have heard the process for QP2TERM is not the same as running a pase request remotely? So not sure how that would effect the results, but it does show if the job the request is run from has the job attributes set, the pase request runs under the same attributes even if it is spawned.
I do not have the environment here (node_ssh) to test the process, so I can only try with what should be similar requests from my environment? I will try that out tomorrow because I am fried now 😊
Have a great evening.
Chris…
From: barry @.> Sent: September 23, 2021 7:53 PM To: halcyon-tech/vscode-ibmi @.> Cc: Chris Hird @.>; Mention @.> Subject: Re: [halcyon-tech/vscode-ibmi] Concurrent modification of a member (#217)
Sure, feel free to run any tests as you wish.
Moral of the store is that running these commands will have no affect on the wait time:
system "CHGJOB DFTWAIT(1)"
system "CPYTOSTMF ..."
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/halcyon-tech/vscode-ibmi/issues/217#issuecomment-926244842, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AELHN4POQYLPNCA2UH5HZZLUDO4URANCNFSM5AVQOJ5Q. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Chris Hird said: "Just to add, getting the error is not a problem, its waiting the 30 seconds to see it appear which I think should be addressed."
Perhaps, if all else fails, just immediately pop up a "Downloading data, please wait" notification. Exact internal logic elude me, but it would just flash by like the message that appear when signing on. It would at least let you know that your click has registered.
I tried this with SQL. I set commit isolation level = RR CREATE ALIAS W_BENMAR/BENMAR FOR W_BENMAR/SRC (B£DAT8) select from w_benmar/benmar
Then I tried to access the member with SEU option 2 and it was allocated until I committed.
That would definitely work for me..
I am testing via putty to the IBMi and found the following.
When I tried to change the running job using the command system “CHGJOB DFTWAIT(1)” or system CHGJOB JOB(*) DFTWAIT(1) the default wait time did not change! However when I ran system “CHGJOB JOB(491159/QSECOFR/QP0ZSPWP) DFTWAIT(1)” the default wait time is actually changed in the job.
I will ask on Ryver if anyone has a solution to this such as being able to pull the job information back from the shell?
Chris… From: SJLennon @.> Sent: September 23, 2021 9:54 PM To: halcyon-tech/vscode-ibmi @.> Cc: Chris Hird @.>; Mention @.> Subject: Re: [halcyon-tech/vscode-ibmi] Concurrent modification of a member (#217)
Chris Hird said: "Just to add, getting the error is not a problem, its waiting the 30 seconds to see it appear which I think should be addressed."
Perhaps, if all else fails, just immediately pop up a "Downloading data, please wait" notification. Exact internal logic elude me, but it would just flash by like the message that appear when signing on. It would at least let you know that your click has registered.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/halcyon-tech/vscode-ibmi/issues/217#issuecomment-926284876, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AELHN4JMYHHTN2GTK547YELUDPK4VANCNFSM5AVQOJ5Q. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
I think the solution would be to use cl as suggested on Ryver, I did a test and it worked although I was using putty for the test and in bash, I would think it’s the same environment as would be formed through the node_ssh connect?
cl “CHGJOB JOB(*) DFTWAIT(5)” and checked the running job, the default wait time was now 5 seconds.
Chris…
From: SJLennon @.> Sent: September 23, 2021 9:54 PM To: halcyon-tech/vscode-ibmi @.> Cc: Chris Hird @.>; Mention @.> Subject: Re: [halcyon-tech/vscode-ibmi] Concurrent modification of a member (#217)
Chris Hird said: "Just to add, getting the error is not a problem, its waiting the 30 seconds to see it appear which I think should be addressed."
Perhaps, if all else fails, just immediately pop up a "Downloading data, please wait" notification. Exact internal logic elude me, but it would just flash by like the message that appear when signing on. It would at least let you know that your click has registered.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/halcyon-tech/vscode-ibmi/issues/217#issuecomment-926284876, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AELHN4JMYHHTN2GTK547YELUDPK4VANCNFSM5AVQOJ5Q. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
@ChrisHird We won't be moving to cl
quite yet, since we still have a bunch of users who don't have it (aren't on the latest version of bash). We also don't require any user to have a specific shell installed.
Though feel free to PR this change and I'd happily review it.
@barry OK I understand, perhaps a check of the cl command availability would be in order and if its there then use it? I think the other option of just showing a in progress message would be very helpful as well. I will look at doing something but been a hell of a long time since I used git ☹
From: barry @.> Sent: September 24, 2021 8:43 AM To: halcyon-tech/vscode-ibmi @.> Cc: Chris Hird @.>; Mention @.> Subject: Re: [halcyon-tech/vscode-ibmi] Concurrent modification of a member (#217)
@ChrisHirdhttps://github.com/ChrisHird We won't be moving to cl quite yet, since we still have a bunch of users who don't have it (aren't on the latest version of bash). We also don't require any user to have a specific shell installed.
Though, feel free to PR this change and I'd happy review it.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/halcyon-tech/vscode-ibmi/issues/217#issuecomment-926594465, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AELHN4PDTRP3XO7227TLHPDUDRW3TANCNFSM5AVQOJ5Q. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
OK so I found that even in a normal shell I can use getjobid to find the actual job its running under, then use that information in the system command 😊 maybe that is the answer as I know the system command will set the default wait using it..
From: barry @.> Sent: September 24, 2021 8:43 AM To: halcyon-tech/vscode-ibmi @.> Cc: Chris Hird @.>; Mention @.> Subject: Re: [halcyon-tech/vscode-ibmi] Concurrent modification of a member (#217)
@ChrisHirdhttps://github.com/ChrisHird We won't be moving to cl quite yet, since we still have a bunch of users who don't have it (aren't on the latest version of bash). We also don't require any user to have a specific shell installed.
Though, feel free to PR this change and I'd happy review it.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/halcyon-tech/vscode-ibmi/issues/217#issuecomment-926594465, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AELHN4PDTRP3XO7227TLHPDUDRW3TANCNFSM5AVQOJ5Q. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
@ChrisHird Yes, doing that is likely the answer:
https://www.ibm.com/docs/en/i/7.2?topic=jobs-getjobid
# Store the job ID from this. Happens when connection is made
getjobid $$
# Use the JOB id here. Happens when connection is made
system "CHGJOB JOB(x) DFTWAIT(x)"
# Any future system commands will inherit it
system "CPYTOSTMF ..."
OK sounds good.
From: barry @.> Sent: September 24, 2021 8:55 AM To: halcyon-tech/vscode-ibmi @.> Cc: Chris Hird @.>; Mention @.> Subject: Re: [halcyon-tech/vscode-ibmi] Concurrent modification of a member (#217)
@ChrisHirdhttps://github.com/ChrisHird Yes, doing that is likely the answer:
https://www.ibm.com/docs/en/i/7.2?topic=jobs-getjobid
getjobid $$
system "CHGJOB JOB(x) DFTWAIT(x)"
system "CPYTOSTMF ..."
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/halcyon-tech/vscode-ibmi/issues/217#issuecomment-926601974, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AELHN4IQD5FASWPLMQF2PG3UDRYIRANCNFSM5AVQOJ5Q. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Not a node.js guy so while I have a smattering of understanding adding the functionality is beyond my scope :-( I can see that the use of paseCommand can return the output from getjobid -jv I am not sure how to restructure the call to then go back and add that into another system command? If anyone wants to help it would be much appreciated.
@ChrisHird I will have a go at making the DFTWAIT configurable from within the extension, but it won't be until after the 1st.
I might have a PR ready by then, though.
Liam
Liam, thanks… Happy to wait..
From: barry @.> Sent: September 24, 2021 10:03 AM To: halcyon-tech/vscode-ibmi @.> Cc: Chris Hird @.>; Mention @.> Subject: Re: [halcyon-tech/vscode-ibmi] Concurrent modification of a member (#217)
@ChrisHirdhttps://github.com/ChrisHird I will have a go at making the DFTWAIT configurable from within the extension, but it won't be until after the 1st.
I might have a PR ready by then, though.
Liam
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/halcyon-tech/vscode-ibmi/issues/217#issuecomment-926651147, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AELHN4OIVFMJZGELCQE74XDUDSAKXANCNFSM5AVQOJ5Q. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
@ChrisHird The way this is architected isn't the same as RDi or SEU - we don't have a mechanism to lock a member - though we can likely check if one is locked before opening it.
So, I was trying to look into this as well. I kept hitting dead ends.
One thing I did find is if you are in an interactive shell, the Rfile
command will hold a lock on a member while it is waiting for stdin.
Example:
@Dman247 We were using Rfile
at one point but had to remove it since it has issues not supporting many encodings.
Edit: Rfile
issue here: https://github.com/halcyon-tech/vscode-ibmi/issues/293#issuecomment-919135509
Right, but in that implementation, you were using Rfile
to actually write the members out. We don't necessarily need to write the member out with Rfile
, we can still just use it to hold the member lock on the IBMi. Then, when a user tries to save a file we cleanly end the Rfile command trying to read Stdin (effectively wiping the lock) and write the file out with the current SQL method.
Just an idea! I don't know, yet, of it's feasibility.
Some progress,
I was able to get this code to lock out my DTHLIB/QCLLESRC(TESTING)
member for the 15 seconds the code was asking for.
When the shell closes, the member is freed up.
One important thing to note, is that since this
Edit: This is actually easily mitigated if we just execute the Rfile
command is trying to read stdin to write to the member, once the command is run it immediately clears the file. But, this should be okay; because, after we free up the lock we will just write the file back out.Rfile
command with the -a
, specifying append mode. Then the file never gets cleared.
Describe the bug I opened a member in SEU with option 2 and the same member in "Code for i". I changed a row in "Code for i" and saved. Then exited without saving in SEU and reopened the member in SEU. The row modified in "Code for i" was changed. It seems that "Code for i" can save a member even if it is in use.
I also tried to open the same member at the same time in Code for i on 2 different PCs and made different modifications. The last one to save overwrote the changes.
Expected behavior I expected that, as in SEU, it would not be possible to make simultaneous changes to the same member.
Environment (please complete the following information):