This is the public portal for all IBM Z Hardware and Operating System related offerings. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
To developer:
>>Would it be desirable to have a new option on the COPY command that would invoke the PDSE validation utility prior to data movement?
No.
After DSS COPY completed with RC=0, 4 data pages of the target PDSE were corruped.
So, we think, the validation check must be invoked every data page moving.
>>And if the validation failed then fail the copy?
Yes.
The COPY processing should be stopped immediately with a SVDUMP, which is usable to invesitigate the root cause.
This sounds to me like something that should be addressed with a PMR. There is NO excuse for any IBM product allowing data corruption. Data integrity is paramount.
The customer requested this RFE enhancement strongly.
It may be too difficult to identify the root cause.
Similar problem occured in other system,
PMR 04898,615,760
Of course I think so. We and our customer think it is important to identify the root cause in PMR.
But now DSS cannot check out curruptions of its own moving data. So it must verify data by another way and additional check logic when any other unexpected problem occurs, espcially data integrity.
In our opinion a ADRDSSU COPY should not end with RC=0 when the target dataset is corrupted. So we feel that this is a case for a PMR and not for an RFE.
Thanks for your response
We concern, the validation of the records between the sorce and target is needed in each data record moving or after the copy. Because we think that data compare is only way to detect problem.
We hope the copy job abend if DSS detects the error. Because this is data integrity problem.
Incidentally IEBPDSE utility cannot check out that data are different from source like this problem.
I would like some clarification on this requirement. Would it be desirable to have a new option on the COPY command that would invoke the PDSE validation utility prior to data movement? And if the validation failed then fail the copy? Or are you asking for something that would perform the data movement first, read the source and target data sets after the copy and compare them to make sure they are identical?
Thank you,
Robert Gensler
Bank of Tokyo Mitsubishi UFJ
Creating a new RFE based on Community RFE #89574 in product z/OS.