If I could respectfully (and teasingly) remark): An intriguing
Friday-ish statement perhaps?
"DB2 z/OS image copies are physical copies of the underlying
datasets (tablespaces) They are not copies of the table".
Are you perhaps alluding to the fact that an image copy and say,
DB2's representation of the table in the catalog OR a table row's
external representation can be very different?
Have a great weekend.
From: Avram Friedman <[login to unmask email]>
To: DB2-L <[login to unmask email]>
Sent: Fri, 11 May 2018 18:14
Subject: [DB2-L] - RE: Integrity check of image copy on Db2 v11
I would like to take issue with those who suggest DSNCOPY with the
While it is true that having a clean run of this utility will raise
the level of confidence that the copy can be restored, a dirty run
of the same utility (except for a physical I/O) error will provide
the same level of confidence that the copy can be restored..
Recover restores the copied pages. If the original table space has
page damage and an image copy is taken then the original table
space including the page damage will be restored.
Should you be concerned about a damaged copy there are two ways to
1. Dual copies, if one copy is not readable use the other.
2. replicate the copy using a utility like IEBGENER or IDCAMS
REPRO. This comes with a difficulty ... the replicated copy can
usually only be restored with DSN1COPY
DB2 z/OS image copies are physical copies of the underlying
datasets (tablespaces) They are not copies of the table.
DB2-L hall of fame contributor
DB2-L 'past' administrator
[login to unmask email]
Site Links: View post online View mailing list online Start new
thread via email Unsubscribe from this mailing list Manage your
This email has been sent to: [login to unmask email]
Faster data refresh is here! The long waits and babysitting of
unload/load jobs is over. Contact
ESAi to learn about BCV5 & XDM. Be a hero to users with fast
on-demand test/QA data provisioning.See
Use of this email content is governed by the terms of service