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
