>>> On 3/12/2013 at 08:31 AM, "Pavelka, Tomas" <tomas.pave...@ca.com> wrote: > We have been trying to format all minidisks from Linux only and this turned > out to be problematic. I am looking for a solution that would let us stay in > Linux without having to involve CMS format for every new minidisk. Let me > first describe the problem: > When there is a record on dasd that has incorrect cylinder in the count > area, this leads to "record not found" errors when the dasd is brought > online. Since the dasd needs to be online before the problem is fixed (by > formatting) the only way around that I can see is to preformat in CMS. > If new minidisks are regularly formatted and destroyed, it is possible to > run into situation where part of the disk has the correct format and part has > the cylinder number in the count area wrong.
To me, this is a process failure on the part of the humans involved. If you're running on z/VM, you should use z/VM tools to prepare the disks for each guest. With a hypervisor slicing and dicing real physical resources, it is incumbent on the people to make sure that what the hipervisor presents to a guest is in a usable format to the guest. The guest shouldn't have to examine every byte on every track to figure out what state it's in. Not to mention the security implications of data being left behind on a volume from the previous, most likely different, owner. What I would suggest in this case is perhaps an enhancement request to the IBM developers to add an option to the DASD driver to make a device available for dasdfmt without making any assumptions as to the status of the device. Or a program that will start a channel program to format a device by device number, similar to the offlindr backup program that was developed for z/OS before the CDL format was created. But from a security perspective, that's a nightmare in the making. Making it "safe" in both z/VM and LPAR mode would be very hard to say the least. Just think about what would need to be done to make sure you're not formatting a DASD volume belonging to z/OS, or some other operating system on the CEC. I would invite others to think of some different possibilities, but at the moment, this just looks like a bad idea all the way around. Mark Post ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
