Your Copy on Write - may be what I know as dual write - where you write to different volumes - usually on different dasd subsystems, so if you lose one dasd subsystem - the data is available on another. You can have synchronous write - used in same "site" and async - where the remote end is miles away. This is used for media failure. Note. This is not a backup. If you delete the dataset, both copies will be deleted.
I was talking about what I think is called snapshot. It is used like 1- Issue Snapshot copy (of your database) - this takes a couple of seconds or less. 2- Backup this copy - it may take a couple of hours to read from the DASD subsystem, and write to perhaps Virtual Tape. 3- The original data set continues to be updated, whereas the copy does not change, so you have point of time consistency 4- You can restore to the point of time, and for products like DB2 and MQ, read the logs and reapply all of the updates. On Tue, 1 Aug 2023 at 03:06, Grant Taylor < 0000023065957af1-dmarc-requ...@listserv.ua.edu> wrote: > On 7/31/23 12:45 PM, Colin Paice wrote: > > A volume is a convenient picture - they no longer exist on modern DASD. > > ACK > > My limited understanding is that the S/360 or S/370 would probably not > recognize anything in use today as DASD. The S/390 /might/ see > something that vaguely reminds it of DASD through ESCON / FICON. > > It seems as if things are significant numbers of layers of abstraction > and emulation. > > > Data is spread across many different PC sized disks. > > Yep. > > It's amazing if not mind blowing what can be done with abstraction and > virtualization of storage. > > > We have extended volumes which are bigger than traditional volumes. > > It gives more space for the same number of volumes. > > :-) > > > A "track" is mapped to one PC sized disk, and block on disk.. > > If you rewrite a track it will most probably go to a different > > PC disk. In the storage controller there is a big array which has > > VOLID.CYL.Track -> pcdisk.position. > > I'm not unpacking and scrutinizing that based on your "Some of the above > is not true" comment. > > > I can "copy a dataset" on the same DASD subsystem just by copying > > the relevant bits of this array. So if we have part of dataset1 > > USER00.00.01 -> PCDISK1. 4000 the copy creates USER99.4002.12 -> > > PCDISK1.4000. This copy takes a second or so. There is no data > > transfer. If you update dataset1, then its VOLID.CYL.track will > > point to a new block, and so the arrays diverge. > > This sounds like what I generally hear referred to as "copy on write" > and is frequent enough that it's abbreviated as C.O.W. and multiple > things support this, one even with COW in the file name. > > > If we copy the dataset to a different DASD subsystem - then every block > > will be read - and written to the other subsystem. > > Yep. > > > Some of the above is not true - but it gives the picture. > > ;-) > > > > Grant. . . . > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
