On 03/14/2013 10:36 AM, Miklos Szigetvari wrote:
Hi
In some previous message I have described that , we are moving now
from the zDASD storage system to DS6800.
We have a "relative" large number of volumes (140) , so we decided to
move via DFSDD COPY
all the volumes to the proper new addresses. It worked for every
volume, except the z/OS 1.13 system volumes (Z1DT11 and Z1DT12),
worked also for the z/OS 1.12 system volumes
We got output track format errors, and nobody can say the reason till
now:
- if I change the output (target) the error moves to the new volume,
but the message complains about the output volume
- if I COPY logically by dataset , I got errors for
sys1.linklib
cee.sceerun
sys1.shasmig
csf.scsfmod0
As last attempt I copied again this datasets by IEBCOPY, and try to
IPL, and the new system is working
(or at last I think so) .
I lost my confidence on me , DS6800 zDASD and the IBM support , but
maybe somebody have seen something like this.
I have never used zDASD, but the Internet descriptions of zDASD sounds
like your data integrity would be totally dependent on the integrity of
the Open Systems Disks used for the physical storage. Perhaps you
actually have corrupted tracks in the problem datasets. It's possible
that zDASD might have some different exposures for "strangeness" if
writes are in flight at the time of a z/OS abend or power failure. Back
in the days of "real" 3990's and non-emulated DASD, after some crashes
it was not uncommon to get an unreadable track when in-flight data
failed to get properly written. Or you might even be seeing some
failure in the underlying physical storage used by zDASD if that storage
was not configured as RAID5 or mirrored storage.
If IEBCOPY appears to work but other forms of copy do not, that almost
suggests the libraries in question might have corrupted tracks but the
corrupted tracks might not be part of any active member in the library.
If the track is corrupted in some way that the track read "succeeds"
without error but the count, key, or data fields are bad, DFDSS might
not check for all possibilities, especially if with IBM DASD such a
failure would have been detected at the I/O or DASD hardware level and
never make it to DFDSS. Because of the internal error detection and
error correction in IBM DASD subsystems, I have never seen an undetected
read failure on IBM DASD, but perhaps that can happen with some zDASD
configurations. If an "impossible" track data inconsistency was not seen
until the attempt to write the track on the target drive failed, that
might explain why the failure seems to point to the target drive even
though the failure seems to be independent of the target drive chosen.
Since IEBCOPY processes the dataset by blocks and can re-arrange data
across track boundaries, if zDASD has any possibility of undetected read
failures, then there is also a possibility that if IEBCOPY were somehow
fed a bad block from an undetected read failure it might also be able to
store a corrupted block on the target successfully where a track image
copy would fail. If that scenario could happen, you couldn't rule out
the possibility of having some corrupted members in the copied dataset.
If any problems are in members that are seldom used, it might take a
long time for it to produce a failure on the copied system. If I had
any independent backups of those datasets, I would be strongly tempted
to make some restored copies under another name and see if there is any
way to "prove" there aren't any unexplained inconsistencies.
Perhaps someone else will have better ideas on ways to validate the
datasets in question.
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
