I looked, and I still have my update to DMSFOR. All it needs is rework to accommodate the intervening quarter-century's worth of changes to the source :-)
On 2/3/2015 23:19, Alan Altmark wrote:
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/
---------------------------------------------------------------------- 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/
