Fix deleting member when PDS is open in ISPF

[t1m0thyj]

What It Does

Fixes #916

How to Test

1. List data sets in ZE using SSH profile
2. Expand a PDS to show its members
3. Launch a 3270 session and browse the same PDS
4. Back in ZE, verify you can delete one of its members

Review Checklist
I certify that I have:

• tested my changes
• added/updated automated tests
• updated the changelog
• followed the contribution guidelines

Additional Comments

[github-actions]

Client artifacts:

• CLI Plug-in: https://github.com/zowe/zowex/actions/runs/24423832084/artifacts/6438407539
• VSCode Extension: https://github.com/zowe/zowex/actions/runs/24423832084/artifacts/6438408048
• SDK: https://github.com/zowe/zowex/actions/runs/24423832084/artifacts/6438408461

[dkelosky]

one thing I wonder about if this new portion should be at the ds.cpp layer in the same way the iebcopy is at that layer. I dont see a specific hard in the current implementation, but was thinking that the zds.cpp layer would be for more programmatic APIs.

Otherwise, it feels like this makes sense. I was also surprised to see (TIL) that deleting a member via ISPF is supported while that same member is open for browse in another ISPF screen.

[t1m0thyj]

I can move it to commands/ds.cpp if we prefer. As you said it would be consistent with invoking IEBCOPY at that layer for the zowex ds compress command.

However if I remove it from zds.cpp, then we won't be providing a function for users of our C++ libraries to delete members without exclusively allocating their parent PDS. Are we ok with this?

[traeok]

Going to test now but left a suggestion about building the DDs 👍

[t1m0thyj]

This seems too permissive - it allows a member to be deleted even when its open in ISPF mode, while z/OSMF does not because the data set has an ENQ.

[dkelosky]

This seems too permissive - it allows a member to be deleted even when its open in ISPF mode, while z/OSMF does not because the data set has an ENQ.

Perhaps the existing behavior is more desirable anyway? That is maybe it’s good thing the delete fails, and we can give a clearer error message

[zFernand0]

This seems too permissive - it allows a member to be deleted even when its open in ISPF mode, while z/OSMF does not because the data set has an ENQ.

Perhaps the existing behavior is more desirable anyway? That is maybe it’s good thing the delete fails, and we can give a clearer error message

I'm confused, 😕

We want to keep the behavior as-is, i.e. fail when the PDS (not the member) is open in either mode (browse, view, edit) in ISPF.
And the goal of this PR should be to provide a better error message?

[dkelosky]

My vote would be to provide a better error message to surface the conflict.

[t1m0thyj]

Updated the error message to be more clear, but the error handling in ZRS extension seems to hide the additionalDetails part of the message - plan to investigate this further:

[2026/04/14 15:33:26.370] [ERROR] [node:events:519] Error for response ID: 5
{"code":-1,"message":"Error: could not delete data set: 'TIMOTHY.TEST.PDS7(ABCD)' rc: '-1'","data":"  Details: Failed to allocate data set '//'TIMOTHY.TEST.PDS7(ABCD)'' for deletion (errno=91). It may be in use by another process.\n"}

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud