It may be a failure in the disk to disk path. Also, our dasd farm has been growing around us for years, some 15 years before I arrived on the scene and nearly another nine since. There is no telling how some of the disks may have been initialized. I am sure that some were inherited from our other mainframe operating systems, both MVS and derivatives and TPF. Some may even have been formatted as CMS disks. It may be a device label or VTOC problem. I know that there were problems with VTOCs early in the days of ACP.
-----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Wednesday, January 03, 2007 9:56 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup of z/VM and z/VSE > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard > Sent: Wednesday, January 03, 2007 11:46 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Backup of z/VM and z/VSE > > > There may be another gotcha. A year ago last June, our shop was in the > middle of a migration to a new datacenter. The concept was simple: > > - Copy disks that were to be migrated into a "bunker box" - a SHARK > facility equipped to synchronize data between the two centers. > - Dress rehearsals to discover an fix any problems in the migration > plans. These included synchronizing the data in the two centers ahead > ago time and doing a final incremental sync when ready to try the > migration. > - Final migration. > > The DASD Storage Management Group, all z/OS-oriented people, scheduled > time to move VM into the bunker box. In the week leading up to the > move, they discovered that the utility they planned to use (and were > assured by the vendor, who shall remain nameless but whose initials > are IBM, that it could handle the task) would not copy the dasd used > by VM. They had worked frantically with IBM trying to fix the problem. > As a last-ditch effort, they were even sent another utility used > internally by IBM that "definitely would work". It also failed. In > near panic, it was 4:45 PM on Thursday and the move was supposed to > take place at 9:00 AM Saturday, they asked me if I had any suggestions > that would save the schedule. The answer was to build a one-pack > system on DASD that was not being migrated and use several virtual > machines to DDR the disks. Task accomplished, and the copying took > only half the time that had been calculated for the z/OS utility. > > Unless they have been fixed, the z/OS utilities may fail when working > with VM DASD. I imagine that DFDSS was the first of the utilities that > failed. I do not even know the name of the one cloaked in black. > > > Richard Schuh That is very strange. I have successfully dumped and restored z/VM DASD using DFDSS on z/OS 1.6. The z/VM system was down at the time. Oh, but this was via TAPE, not disk-to-disk. That may be the difference. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.