A volume is a convenient picture - they no longer exist on modern DASD. Data is spread across many different PC sized disks. 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 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. If we copy the dataset to a different DASD subsystem - then every block will be read - and written to the other subsystem.
Some of the above is not true - but it gives the picture. Colin On Mon, 31 Jul 2023 at 16:46, Grant Taylor < 0000023065957af1-dmarc-requ...@listserv.ua.edu> wrote: > On 7/31/23 6:37 AM, Jay Maynard wrote: > > It's not just CPU power or number of cores, but the ability to connect > > thousands of volumes of data and access them simultaneously, and move > > that data from point A to point B efficiently. > > Please elaborate, are those volumes separate DASD devices or are they > possibly some logical component thereon? > > I also wonder how common it is to have four digits of volumes (physical > or logical) varied on at the same time. > > I wonder this about both mainframes and some of the largest Open Systems > that I've been exposed to. > > Hundreds absolutely happens. I don't know about a thousand or more. > > Also, what constitutes a volume? How different are FCP and FC LUNs? > How different are they when the same back end storage system is > exporting LUNs to both mainframe and Open Systems, with the primary > difference being FCP vs traditional FC? > > > > -- > 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
