Conversation
Signed-off-by: Amber <amber.torrise@broadcom.com>
|
Client artifacts: |
Signed-off-by: Amber <amber.torrise@broadcom.com>
Signed-off-by: Amber <amber.torrise@broadcom.com>
|
Server artifacts: |
Signed-off-by: Amber <amber.torrise@broadcom.com>
Signed-off-by: Amber <amber.torrise@broadcom.com>
Signed-off-by: Amber <amber.torrise@broadcom.com>
Signed-off-by: Amber <amber.torrise@broadcom.com>
Signed-off-by: Amber <amber.torrise@broadcom.com>
Signed-off-by: Amber <amber.torrise@broadcom.com>
Signed-off-by: Amber <amber.torrise@broadcom.com>
Signed-off-by: Amber <amber.torrise@broadcom.com>
|
Does the existing copy ability in Zowe Explorer support masking / wildcarding? For example, can I copy all members that match |
Signed-off-by: Amber <amber.torrise@broadcom.com>
Signed-off-by: Amber <amber.torrise@broadcom.com>
Signed-off-by: Amber <amber.torrise@broadcom.com>
zFernand0
left a comment
There was a problem hiding this comment.
LGTM! 😋
I do see a few commits trickling in, so I'll wait for those two slow down before approving, but overall LGTM! 😋
traeok
left a comment
There was a problem hiding this comment.
Thanks Amber, working on testing the functionality now. I left a couple requests for changes, mostly surrounding the dsorg check. Left a suggestion about reducing parameter count for the newly-exposed zds API.
Signed-off-by: Amber Torrise <112635587+ATorrise@users.noreply.github.com>
Signed-off-by: Amber <amber.torrise@broadcom.com>
Signed-off-by: Amber <amber.torrise@broadcom.com>
Signed-off-by: Amber <amber.torrise@broadcom.com>
Requested changes have been addressed, thanks
Signed-off-by: Amber <amber.torrise@broadcom.com>
Signed-off-by: Amber <amber.torrise@broadcom.com>
traeok
left a comment
There was a problem hiding this comment.
Thanks Amber, latest changes make sense to me. All tests are passing on the internal zVDT.
LGTM
zFernand0
left a comment
There was a problem hiding this comment.
🍰🍰🍰 LGTM! 🍰🍰🍰
Thanks for adapting to all the upcoming feedback 🙏
Very well done! 👍
pujal0909
left a comment
There was a problem hiding this comment.
Copying from a PDS to PS returns a success message, but it should fail.
Data set 'pujal.test.pds1' copied to 'pujal.ps.test13'
Signed-off-by: Amber <amber.torrise@broadcom.com>
|
❌ The last analysis has failed. |
addressed

Add Data Set Copy Command (
zowex ds copy)This PR introduces the
zowex ds copycommand for data sets and members, featuring overwrite protection via--replaceand--delete-target-membersoptional flags.What It Does
Backend copy functionality supporting the following operations:
-r-dManual Test Commands for
zowex ds copyCopy paste these commands into a new file and substitute
USERIDwith your chosen HLQ :) (also you don't need to test this way I just want to help make reviewing easier and faster because there are many branches of this copy pr) Pay attention to expected replacement/overrides when executing these commands. Working through these setup and copy commands then verifying should take 10-15 minutesInitial Setup
PS
PDS
Member
Cleanup
Review Checklist
I certify that I have:
Additional Comments
Development Notes: Why This PR Took Longer Than Expected
This PR encountered several z/OS-specific challenges that required significant investigation and architectural decisions:
Copy uses member-by-member binary I/O (fopen/fread/fwrite) rather than IEBCOPY. This approach was chosen despite initial advice to leverage compress code because:
When creating target data sets, z/OS's System-Determined Block Size (SDFS) can round BLKSIZE for track efficiency. The target BLKSIZE may be larger than the source (ie 800 -> 6080) depending on SMS Data Class settings. This is expected z/OS behavior, but I didn't anticipate it initially, so debugging why tests were failing with "mismatched BLKSIZE" took some time to understand and handle correctly.
Some z/OS systems override DSNTYPE(PDS) requests via SMS, creating PDSEs instead. This is handled by:
The original --overwrite flag was renamed to --delete-target-members for clarity and to align with its actual behavior.
This naming makes the destructive nature of the flag explicit and avoids confusion despite veering from the original semantics of the Zowe CLI. Pujal and Dan both suggested something less confusing be done with the overwrite flag naming.
🤠