'Remote file has been modified' loop when working with PDS/PDSE

[BernardoFern]

Bug description: When using the Zowe Extension for VSCode and performing an edit and save to a dataset member of a PDS or PDSE, an error message is issued by VSC.

Steps to reproduce:

1. Create a new partitioned dataset;
2. Create a new member within this new dataset;
3. Edit-in data, save the member;
4. Edit-in data again, save the member again;

Observed issue: Source is refreshed: the vscode tab to edit member goes blank momentarily, and the data reappears; The following error message is issued by vscode, when the local and remote sources actually match: . Pressing 'Overwrite' or 'Compare>Overwrite' leads to the file being saved and therefore issuing the error message from the previous image again.

System configuration:

• OS: Windows 10 build 19044.2130
• Zowe Explorer Version: v2.4.0
• Zowe CLI Version: 7.6.1
• Are you using Secure Credential Store? Yes

Additional comments: Not a deal breaker, but this bug renders vscode autosave feature completely unusable. A user that might have it on will be unable to perform any changes as the file is saved on the server side constantly.

[github-actions[bot]]

Thank you for creating a bug report. If you haven't already, please ensure you have provided steps to reproduce it and as much context as possible.

[traeok]

I was able to replicate this issue and it seems like a bug with the API. For my testing I avoided the compare/overwrite buttons and just continued to edit and save, mainly to see where the save conflict is being detected. Here is an example sequence (placing here for future reference):

1. first save: etag is empty, so no etag is sent. since etag was empty, upload will always work for first save
2. node etag now updated to etag from putContents api: 3F15C25C4662BDD3...
3. Change and save PDS member
4. node etag is 3F15C25C4662BDD3..., BUT upload fails in API, and so we re-assign the node's etag w/ getContents API response
5. node etag is now 87E3BBDFB42D5816..., received from getContents API
6. Change and save PDS member
7. successful upload this time, node etag is now updated with returned etag from putContents: E1B3232545DDF12F...
8. Change and save PDS member
9. Node etag is now E1B3232545DDF12F..., BUT upload fails in API again.

Sorry for the verbose debug comments, but wanted to highlight that the loop doesn't always occur for every change/save iteration. It looks to be an issue with how the API is returning etags - at first glance, it looks like putContents is returning an invalid etag, because after syncing w/ the etag from getContents, putContents accepts that etag for the next change/save - however, the returned etag from putContents does not work for subsequent calls.

[traeok]

~I stand corrected - we were able to reproduce the problem with PDS within Zowe Explorer, but when using the API directly, the PDS type seems to work - so this can definitely be a problem with Explorer. With LIBRARY/PDSE types the API seems to have issues accepting the previously saved Etag. Going to spend some time today doing some further API testing and will update.~

I spoke too early, my apologies for the confusion. I did some more testing w/ the API on both PDS and LIBRARY types and received a 412 response for both. Suggesting that we report this to z/OSMF as the Etag works after grabbing it from getContents, but the saved putContents Etag is not accepted

[BernardoFern]

My apologies, I was sick shortly after I submitted the bug - but I am back now (: . Thank you for investigating this. This issue was observed for a PDS (not a library). Cheers

[traeok]

No worries! Thank you for the clarification. We did some further testing and the issue seems to be related to mainframe profiles/permissions on the LPARs. @t1m0thyj was not able to replicate this issue as the API is working as intended and returning the proper return codes, but I was able to reproduce this problem with my account. We are going to follow up with the z/OSMF team on this issue, as well as some further testing and will report back with updates. Thanks for your patience!

[traeok]

@BernardoFern Sorry again for the delay - we did hear back from the z/OSMF API team, and the issue seems to arise from 8-character username IDs. A fix is currently in the works and I will follow-up once we receive an update 🙂

[traeok]

Hi @BernardoFern ,

We've received news that the fix is publicly available in the following PTF: https://www.ibm.com/support/pages/apar/PH52243

I've done some testing locally to confirm that this PTF has resolved the issue 🙂 so, I will mark this issue as completed. Feel free to reply to this thread if the issue still appears for you after having installed this PTF.

Thanks!