On Tuesday, 02/03/2015 at 06:25 EST, Rick Troth <[email protected]> wrote: > On 02/02/2015 07:19 PM, Alan Altmark wrote: > > The protection is in place because of the allocation map. Unlike other > > files on the disk, it is in a fixed location since it is written during > > FORMAT and its size never changes, as that size is based on the size of > > the disk. But if you add more cylinders, you add more blocks. And as you > > do that, the allocation map has to grow. But it can't grow. It's > > surrounded by other data. > > Am not quite following since you changed ADTMCYL, Mike calls it > malleable, and Ray once had a mod for.
Hence my comment about revisiting DMSFOR and DMSAUD. So instead of trying to modify the disk such that is is large when subsequently accessed, I went the route of tricking the RECOMP code. But I still believe that the allocation map was never intended to physically move, but switches locations along with the DIRECTOR file each time the DOP is "flopped." But it's going to take someone with more patience than I have to perform more experiments. I would first write several files to the disk, THEN expand it, THEN fill the disk. My intuition is telling me that the newly RECOMPed allocation map will gladly overlay those first files and create a mess. But as I say, some more experiments are needed. Or Ray's code. :-) Alan Altmark Senior Managing z/VM and Linux Consultant Lab Services System z Delivery Practice IBM Systems & Technology Group ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 [email protected] IBM Endicott ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
