Just shortly the solution:
The problem was , that the zDASD calculated erroneously the track
capacity.(If someone has interest, I can send the details off-list )
zDASD allowed track capacity , which was larger as the 3390 track
capacity, and the track copy from zDASD to DS6800 failed, with Invalid
Track Format sense code.
As we move now from zDASD, it is not so serious for us, DS6800 work
properly.
Thank you for everybody and the IBM support .
On 15.03.2013 00:39, Miklos Szigetvari wrote:
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
