----- Start Original Message ----- Sent: Fri, 28 Jul 2006 12:35:26 +0200 From: Rob van der Heij <[EMAIL PROTECTED]> To: [email protected] Subject: Re: Bad Linux backups
<SNIP> > I would hope that anything that prevents the flashcopy > from starting could be reported for example with a command reject upon > device end. <SNIP> I have not analyzed a CCW trace of the whole FLASHCOPY operation, but the z/VM FLASHCOPY command returns immediately if the request can be queued to the Shark. At some later point in time an error may be received by z/VM and an asynchronous console message is issued. This is the complication that Mike related to, in that handling such asynchronous messages in a REXX script is complicated and not for a novice. Once again this is practical advice, not theoretical. I have been through this, and it was painful. Alan has stated that something better is coming, perhaps a rewite of the actual z/VM FLASHCOPY command? Can you enlighten us Alan? <SNIP> > If the device could just give up somewhere in the middle of copying a > volume as if it were normal business, then I think I don't want to > share my views on that design with folks on a public mailing list. It is very likely that I have already said many words relating to such views :-) Mark ---------------------------------------------------------------------- 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
