On 14.03.2013 19:21, Joel C. Ewing wrote:
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.
Thank you very much, it is a very good feeling , that some of the list
members take the time, and think over my problem ad give very useful
advices.
With the "inactive" tracks, it would be a very good explanation, and
would suggest that the error is on the "old" zDASD side and the new
DS6800 is working properly. I'm now mixed up a little, but as far as I
remember, the first thing we tested was a DFDSS COPY , the same
volumes, from zDASD to zDASD and it worked. I will check this again .
Thank you again .
--
Kind regards, / Mit freundlichen Grüßen
Miklos Szigetvari
Research& Development
ISIS Papyrus Europe AG
Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria
T: +43(2236) 27551 333, F: +43(2236)21081
E-mail: [email protected]
Info: [email protected] Hotline: +43-2236-27551-111
Visit our brand new extended Website at www.isis-papyrus.com
---------------------------------------------------------------
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS Papyrus accepts
no responsibility for malicious or inappropriate content.
---------------------------------------------------------------
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
