Re: HDS backup process

2006-03-11 Thread John (IBM-MAIN)
--- snip ---
The fact that ickdsf cannot clip the volser is because the hardware knows
that this secondary disk is part of a suspended pair .
When you suspend , ickdsf will tell you
ICK30111I DEVICE SPECIFIED IS THE SECONDARY OF A DUPLEX OR PPRC PAIR
ICK31024I UNABLE TO OPEN VOLUME.
ICK30003I FUNCTION TERMINATED. CONDITION CODE IS 12
( this is happening on IBM dasd  and is Zaromil description )
AFAIK this is just because of pure hardware behaviour .( shutting down your
entire GDPS will not clear the condition . Hardware will remember it is part
of a suspended pair .
So when you say it is possible to clip the volumes , do you mean you can do
it only on other hardware ? (like HDS) or is it just because your BCM
software is manipulating some hardware bits in the controller , in order to
fool ickdsf ?
( i was thinking of a scenario with db2 log suspend , csuspend ,db2 log
resume, dump the secondary volumes on cartridges, and cestpair resynch )
--- snip ---

Does the DUMPCOND(SET) parameter of ICKDSF REFORMAT get you anything?

I've never tried it with a suspended Duplex secondary.

John

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: HDS backup process

2006-03-11 Thread Bruno Sugliani
On Sat, 11 Mar 2006 17:34:12 +0100, John (IBM-MAIN)
[EMAIL PROTECTED] wrote:

--- snip ---
Does the DUMPCOND(SET) parameter of ICKDSF REFORMAT get you anything?
I've never tried it with a suspended Duplex secondary.

Well thanks
I don't know  i did not even know it in ickdsf ( i know the one in dfdss but
as you can see i have no flashcopy )
I'll try it on monday in the office .
Bruno
Bruno(dot)sugliani(at)groupemornay(dot)asso(dot)fr

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: HDS backup process

2006-03-10 Thread TISLER Zaromil
Ron,

 Are you using the BCM (Business Continuity Manager) Host software, or the
archaic PPRC commands?

As a GDPS PPRC site I believe we are stuck to PPRC commands.

Zaromil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: HDS backup process

2006-03-10 Thread John Ticic
-- snip --
Ron,

 Are you using the BCM (Business Continuity Manager) Host software, or the
archaic PPRC commands?

As a GDPS PPRC site I believe we are stuck to PPRC commands.
-- snip -

By default yes.

You can write your own scripts, and could possibly intergrate the BCM
commands into GDPS.

I suspect you wouldn't get much sympathy from IBM if you got into trouble
though.

John

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: HDS backup process

2006-03-10 Thread Ron and Jenny Hawkins
John,

Too true, but there's nothing to stop you using BCM for Shadowimage in a
GDPS environment.

In regards to the original question, let me have the weekend to think of it
in the context of a GDPS/PPRC environment with BCM. I'm assuming a USP for
the storage.

Ron

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of John Ticic
 Sent: Friday, 10 March 2006 5:43 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: HDS backup process
 
 -- snip --
 Ron,
 
  Are you using the BCM (Business Continuity Manager) Host software, or
 the
 archaic PPRC commands?
 
 As a GDPS PPRC site I believe we are stuck to PPRC commands.
 -- snip -
 
 By default yes.
 
 You can write your own scripts, and could possibly intergrate the BCM
 commands into GDPS.
 
 I suspect you wouldn't get much sympathy from IBM if you got into trouble
 though.
 
 John
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: HDS backup process

2006-03-10 Thread Bruno Sugliani
On Fri, 10 Mar 2006 21:13:20 +0800, Ron and Jenny Hawkins
[EMAIL PROTECTED] wrote:
Too true, but there's nothing to stop you using BCM for Shadowimage in a
GDPS environment.

In regards to the original question, let me have the weekend to think of it
in the context of a GDPS/PPRC environment with BCM. I'm assuming a USP for
the storage.

Ron
just by curiosity
The fact that ickdsf cannot clip the volser is because the hardware knows
that this secondary disk is part of a suspended pair .
When you suspend , ickdsf will tell you
ICK30111I DEVICE SPECIFIED IS THE SECONDARY OF A DUPLEX OR PPRC PAIR
ICK31024I UNABLE TO OPEN VOLUME.
ICK30003I FUNCTION TERMINATED. CONDITION CODE IS 12
( this is happening on IBM dasd  and is Zaromil description )
AFAIK this is just because of pure hardware behaviour .( shutting down your
entire GDPS will not clear the condition . Hardware will remember it is part
of a suspended pair .
So when you say it is possible to clip the volumes , do you mean you can do
it only on other hardware ? (like HDS) or is it just because your BCM
software is manipulating some hardware bits in the controller , in order to
fool ickdsf ?
( i was thinking of a scenario with db2 log suspend , csuspend ,db2 log
resume, dump the secondary volumes on cartridges, and cestpair resynch )
but ...
Thanks
Bruno
Bruno(dot)sugliani(at)groupemornay(dot)asso(dot)fr

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: HDS backup process

2006-03-10 Thread Dennis Leong
Apologies if you have already seen this posting.  I'm having problems seeing

posting as I only view thru the News group.  I have NOMAIL set so I do not 
get email for any postings.  I'm not sure if I also need to post to news 
group.

Since we are not able to purchase something like FDR Instant, I'm looking
for other ways to avoid having to clip volume labels.  Has anyone had any
experience copying volumes with DFDSS COPY with the dumpconditional and
fastreplication keywords on a HDS 9900?  Is Showdow Image invoked?

Also what functionality does ShadowImage Flashcopy v2 Extension provide? 
What is
the difference if I run DFDSS COPY with dumpconditional with and without 
this extension?
Thank you
Ron and Jenny Hawkins [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]
 John,

 Too true, but there's nothing to stop you using BCM for Shadowimage in a
 GDPS environment.

 In regards to the original question, let me have the weekend to think of 
 it
 in the context of a GDPS/PPRC environment with BCM. I'm assuming a USP for
 the storage.

 Ron

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
 Behalf Of John Ticic
 Sent: Friday, 10 March 2006 5:43 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: HDS backup process

 -- snip --
 Ron,

  Are you using the BCM (Business Continuity Manager) Host software, or
 the
 archaic PPRC commands?

 As a GDPS PPRC site I believe we are stuck to PPRC commands.
 -- snip -

 By default yes.

 You can write your own scripts, and could possibly intergrate the BCM
 commands into GDPS.

 I suspect you wouldn't get much sympathy from IBM if you got into trouble
 though.

 John

 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html

 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: HDS backup process

2006-03-09 Thread TISLER Zaromil
This thread has begun with a PPRCopy question. I am not sure if this two
parts of Bruce' mails (not to cite John and Ron) talk about PPRC (Truecopy)
or Flashcopy (Shadowimage). I wasn't able to see any of these features in
our z/OS 1.7 PPRC environment using HDS 9980.

- snip -
You don't need to lose the relationship to do the backup.  You probably 
want to backup a point-in-time copy of the volumes, so you can just 
SUSPEND the PPRC relationship.  This freezes the copy and makes it 
read/write so you can relabel (CLIP) it.  After the backup, you can 
RESYNC the PPRC copy, which just copies tracks updated since the SUSPEND. 
- snip -

Supposing we do it in a z/OS 1.7 system I don't understand how is it
possible to clip the secondary volume. I get the info about the device being
a PPRC secondary device. Even if I take the primary volume offline, I get
the same kind of message if I try to take the secondary volume online.


Bruce wrote:
- snip -
I believe that RESYNC will copy any tracks which have been modified on 
the source OR target.
- snip -

The other thing that I don't understand:
To be able to write on the secondary volume, I suppose I have to use
CDELPAIR or at least CRECOVER. If I use CDELPAIR, I can not RESYNC anymore.
If I use CRECOVER the secondary volume switches in the SIMPLEX status, so
how comes its bitmap is updated?

Zaromil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: HDS backup process (resend)

2006-03-09 Thread Andrew N Wilt
Dennis,
  I believe that if you have the FlashCopy v2 Extension for your HDS,
DFSMSdss
should act just like it is working with an ESS and attempt to use the
FlashCopy interface
to do an instant copy of the volume. (I can't say for sure since I haven't
had the chance
to try it on an HDS. We don't have any lying around to play on.)
  If you don't have the Extension, then we would revert to using manual
I/O on the
volume and the copy process would take longer to complete.

Thanks,

 Andrew Wilt
 IBM DFSMSdss Architecture/Development
 Tucson, Arizona


IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 03/09/2006
10:53:52 AM:

 Retry sending this post

 Since we are not able to purchase something like FDR Instant, I'm looking
 for other ways to avoid having to clip volume labels.  Has anyone had any
 experience copying volumes with DFDSS COPY with the dumpconditional and
 fastreplication keywords on a HDS 9900?  Is Showdow Image invoked?

 Also what functionality does ShadowImage Flashcopy v2 Extension
 provide?   What is
 the difference if I run DFDSS COPY with dumpconditional with and without
 this extension?
 Thank you

 - enD sin

 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: HDS backup process

2006-03-08 Thread Dennis Leong

Since we are not able to purchase something like FDR Instant, I'm looking
for other ways to avoid having to clip volume labels.  Has anyone had any
experience copying volumes with DFDSS COPY with the dumpconditional and
fastreplication keywords on a HDS 9900?  Is Showdow Image invoked?

Also what functionality does ShadowImage Flashcopy v2 Extension 
provide?   What is
the difference if I run DFDSS COPY with dumpconditional with and without 
this extension?

Thank you.

- enD sin 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: HDS backup process

2006-03-08 Thread Ron and Jenny Hawkins
Dennis,

You don't have o clip the labels of a conditioned volume - that's the reason
for dumpconditioning. However conditioning is a function provided by DFDSS,
so you will be doing a normal copy of every volume prior to dumping it.

DFDSS can interact with Flashcopy so that the hardware will handle the copy.
On HDS you need Shadowimage with the FC add-on so that Shadowimage executes
as FC compatible. This means your DFDSS copies will be complete almost
instantly and Dumpconditioning will leave the target volume online so you
can DUMP it.

With the FC extension you can also combine Dumpconditioning with FCNOCOPY
and FCWITHDRAW.

In your first e-mail you mentioned PPRCcopy, which the ensuing thread
assumed you meant TrueCopy. If that's right then none of the discussion
about DFDSS is applicable because FC does not interact with Remote Copy
software.

You also mentioned a new HDS 9900. There are no new 9900s, and in fact
we stopped making them half a decade ago. IIRC the Flashcopy extension is
limited to FC Version functions only.

Ron

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Dennis Leong
 Sent: Thursday, 9 March 2006 5:51 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: HDS backup process
 
 Since we are not able to purchase something like FDR Instant, I'm looking
 for other ways to avoid having to clip volume labels.  Has anyone had any
 experience copying volumes with DFDSS COPY with the dumpconditional and
 fastreplication keywords on a HDS 9900?  Is Showdow Image invoked?
 
 Also what functionality does ShadowImage Flashcopy v2 Extension
 provide?   What is
 the difference if I run DFDSS COPY with dumpconditional with and without
 this extension?
 Thank you.
 
 - enD sin
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: HDS backup process

2006-03-06 Thread Bruce Black


Actually he is always right 

Thanks, Bruno.  If only it were true (sigh)

--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: HDS backup process

2006-03-04 Thread Ron and Jenny Hawkins
John,

Not actually true. There is a bitmap merge as part of the resynch.

Ron

 
 If you CLIP the secondary DASD, just remember that a subsequent RESYNC
 will
 not copy the label since that wasn't changed on the primary subsystem. You
 may want to CLIP it back.
 
 John
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: HDS backup process

2006-03-04 Thread Ron and Jenny Hawkins
Bruno,

Yeah, but we are talking TrueCopy not PPRC :)

Bruce is correct.

Ron

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Bruno Sugliani
 Sent: Wednesday, 1 March 2006 3:00 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: HDS backup process
 
 On Tue, 28 Feb 2006 11:45:37 -0500, Bruce Black [EMAIL PROTECTED]
 wrote:
 
 I believe that RESYNC will copy any tracks which have been modified on
 the source OR target.  Ron Hawkins, can you confirm?
 
 
 I dont think so ( i am not Ron)
 A cestpair resynch in a pprc IBM disks environment will only synch from
 primary to secondary , only if a track in the primary has been updated.
 Well let's wait Ron .
 Bruno
 Bruno(dot)sugliani(at)groupemornay(dot)asso(dot)fr
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: HDS backup process

2006-03-04 Thread John (IBM-MAIN)
-- snip --
John,

Not actually true. There is a bitmap merge as part of the resynch.

Ron

 
 If you CLIP the secondary DASD, just remember that a subsequent RESYNC
 will
 not copy the label since that wasn't changed on the primary subsystem. You
 may want to CLIP it back.
 
 John
 
-- snip --
Ron, 

I assume that if both bitmaps indicated that the same track was changed that 
the latest timestamp wins.

If I remember correctly, the timestamps are sourced via the MVS I/O (typically 
from a SYSPLEX timer). Since the primary and secondary may not be attached to 
the same time source, don't you see this as being a little risky!

John



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: HDS backup process

2006-03-04 Thread Bruno Sugliani
On Sat, 4 Mar 2006 18:59:56 +0800, Ron and Jenny Hawkins
[EMAIL PROTECTED] wrote:

Bruno,
Yeah, but we are talking TrueCopy not PPRC :)
Bruce is correct.

Ron
Actually he is always right and that was the reason i was very cautious
i wrote with PPRC on IBM hardware !
:-))
Bruce ... 1000 apologies grin
Bruno
Bruno(dot)sugliani(at)groupemornay(dot)asso(dot)fr

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: HDS backup process

2006-03-04 Thread Ron and Jenny Hawkins
John,

There is no timestamps in a bitmaps. 

After the merge any tracks marked as changed in the merged bitmap will be
sent from P-VOL to S-VOL.

Ron

 Ron,
 
 I assume that if both bitmaps indicated that the same track was changed
 that the latest timestamp wins.
 
 If I remember correctly, the timestamps are sourced via the MVS I/O
 (typically from a SYSPLEX timer). Since the primary and secondary may not
 be attached to the same time source, don't you see this as being a little
 risky!
 
 John
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: HDS backup process

2006-03-01 Thread TISLER Zaromil
- snip -
I was told that in order to do this the secondary volume labels' must be
clipped before I can bring them online but by clipping them I also loose the
primary-secondary volume relationships.  Besides using another lpar or other
3rd party utilities to run the backups, how does  one handle this situation?
- snip -



From Hitachi Freedom Storage™ Lightning 9900™ V Series Hitachi TrueCopy –
S/390® User and Reference Guide

snip

The RCU does not allow a TC390 R-VOL to be online and rejects all
host-requested read and
write I/O operations for a TC390 R-VOL. The TC390 R-VOLs must be offline
during normal
TC390 operations. Note: TrueCopy – S/390® provides a special R-VOL read
option (see section
2.2.4) which allows read-only access to the R-VOL while the pair is
suspended. If you need
write access to a TC390 R-VOL, you must delete the pair.

2.2.4 R-VOL Read Option

For additional flexibility, TrueCopy – S/390® offers a special R-VOL read
option. The Hitachi
Data Systems representative enables the R-VOL read option on the RCU (mode
20). The
R-VOL read option allows you to read a TC390 R-VOL only while the pair is
suspended, that
is, without having to delete the pair. The RCU will allow you to change only
the VOLSER of
the suspended R-VOL, so that the R-VOL can be online to the same host as the
M-VOL while
the pair is suspended. All other write I/Os will be rejected by the RCU. The
MCU copies the
M-VOL VOLSER back onto the R-VOL when the pair is resumed. When the R-VOL
read option
is not enabled and/or the pair is not suspended, the RCU rejects all read
and write I/Os to a
TC390 R-VOL. Note: If you need write access to an R-VOL, you must delete the
pair.

Note: For 2105 controller emulation, the CSUSPEND command to the R-VOL of a
suspended
TC390 pair will be rejected when the TC390 R-VOL read option is used.

snip

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: HDS backup process

2006-02-28 Thread John Ticic
-- snip --
 I was told that in order to do this the secondary volume labels' must be
 clipped before I can bring them online but by clipping them I also
 loose the
 primary-secondary volume relationships.  Besides using another lpar or
 other
 3rd party utilities to run the backups, how does  one handle this
 situation?
You don't need to lose the relationship to do the backup.  You probably
want to backup a point-in-time copy of the volumes, so you can just
SUSPEND the PPRC relationship.  This freezes the copy and makes it
read/write so you can relabel (CLIP) it.  After the backup, you can
RESYNC the PPRC copy, which just copies tracks updated since the SUSPEND.
-- snip --

If you CLIP the secondary DASD, just remember that a subsequent RESYNC will
not copy the label since that wasn't changed on the primary subsystem. You
may want to CLIP it back.

John

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: HDS backup process

2006-02-28 Thread Bruce Black


If you CLIP the secondary DASD, just remember that a subsequent RESYNC will
not copy the label since that wasn't changed on the primary subsystem. You
may want to CLIP it back.
I believe that RESYNC will copy any tracks which have been modified on 
the source OR target.  Ron Hawkins, can you confirm?


--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: HDS backup process

2006-02-28 Thread Bruno Sugliani
On Tue, 28 Feb 2006 11:45:37 -0500, Bruce Black [EMAIL PROTECTED]
wrote:

I believe that RESYNC will copy any tracks which have been modified on
the source OR target.  Ron Hawkins, can you confirm?


I dont think so ( i am not Ron)
A cestpair resynch in a pprc IBM disks environment will only synch from
primary to secondary , only if a track in the primary has been updated.
Well let's wait Ron .
Bruno
Bruno(dot)sugliani(at)groupemornay(dot)asso(dot)fr

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: HDS backup process

2006-02-28 Thread Clark, Maurice
-Snip--
I believe that RESYNC will copy any tracks which have been modified on 
the source OR target.  Ron Hawkins, can you confirm? 
-Snip- 

Kinda depends whether you are talking about Trucopy of Shadowimage...
That is true for Trucopy (see below from the manual):

-
If the RCU accepts write I/Os for a split S-VOL (S-VOL write enable
pairsplit option), the RCU keeps track of the S-VOL cylinders/tracks
which are updated. When the split pair is resumed, the MCU merges the
P-VOL and S-VOL cylinder/track bitmaps to determine the out-of-sync
cylinders/tracks and ensure accurate resynchronization.
-

But I don't think a normal Shadowimage resync will do that

Cheers... 

Maurice Clark


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: HDS backup process

2006-02-27 Thread Bruce Black
We've just moved to a new HDS 9900 storage device and now we are 
planning to
use PPRCopy to replicate volumes for backup.  We want to be able to 
run the
backups on the same lpar that the primary volumes are online to using 
DFDSS.

I was told that in order to do this the secondary volume labels' must be
clipped before I can bring them online but by clipping them I also 
loose the
primary-secondary volume relationships.  Besides using another lpar or 
other
3rd party utilities to run the backups, how does  one handle this 
situation? 
You don't need to lose the relationship to do the backup.  You probably 
want to backup a point-in-time copy of the volumes, so you can just 
SUSPEND the PPRC relationship.  This freezes the copy and makes it 
read/write so you can relabel (CLIP) it.  After the backup, you can 
RESYNC the PPRC copy, which just copies tracks updated since the SUSPEND. 

You didn't mention if you are going to use HDS ShadowImage (PPRC 
within a subsystem) or real PPRC (HRC) between two subsystems.  In 
either case HDS has manuals on this, I am most familiar with the 
ShadowImage manual. 

Having said that, you might want to check out our FDRINSTANT (see our 
web site below).  It supports ShadowImage and HRC and allows you to do 
the backup of the point-in-time copy without relabling it or any 
tomfollery like that.


--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html