Hi Alan, If I DUMP a z/Linux volume using CPVOLUME as a parameter on the input statement will this hurt anything? That is will be ok when restored?
Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 -----Original Message----- From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of Alan Altmark Sent: Sunday, February 28, 2010 10:40 PM To: [email protected] Subject: Re: z/VM backup&restore procedure On Thursday, 02/25/2010 at 05:17 EST, Mike Walter <[email protected]> wrote: > If you format VM DASD from VM using the CPFMTXA EXEC is will ALWAYS install a > Format 5 label, and he few other and absolutely critical things that VM > requires. If you are not very careful to read the ICKDSF doc when INITing a VM > DASD from MVS, you can easily write a VTOC that makes it appear that the DASD > has scads of free space available. Do that just ONE single time on a VM page > DASD, and get it mounted (by accident, of course) on an MVS system as a PUBlic > volume, and watch your VM system crash in seconds! Not a very good career > enhancing move. ICKDSF CPVOLUME (which is what CPFMTXA does) is required for CP-owned volumes. In addition to the allocation map and other stuff, CPVOLUME writes a VTOC that tells z/OS the volume has no empty space on it. USER volumes can be INITed, but z/OS will think the volume is empty and could be persuaded to start scribbling on it. (Interested parties can read up on what a CPVOLUME-formatted volume label and VTOC looks like at http://www.vm.ibm.com/devpages/altmarka/vtoc.html.) > That said, for over 15 years our z/VM system **used to be** backed up by jobs > on z/OS (and it's forerunners). Once the restores were completed at the D.R. > site, we ran a CMS filesystem checker on every CMS minidisk, looking for > problems - never had a single one. WE were very lucky, or very good, or > something else entirely. Both. When you open a CMS file and update it, the master file directory (MFD) remains unchanged until the file is closed. If you have multiple files open concurrently, the MFD is not updated until ALL files are closed. This means that if you copy a minidisk that has open files on it, the copy will not include any of the updates that have been made since the last time all open files on the disk were closed prior to the start of the copy. Any open file on the disk will prevent the MFD from being updated. Good news (?): The copy will be free from filesystem errors, but may not have the content you wish as all of those changes appear to have been rolled back. MDCHECK will not complain. Bad news (?): You get only one free update (open, open, open, update, update, update, close, close, close) at no risk to the minidisk copy. If you do it more than once while you are copying the disk, the disk copy will be toast. It is very likely that this will be detected by MDCHECK. Alan Altmark z/VM Development IBM Endicott
