Shadowing Question without being in the shadowset

[3parhpux]

$1$DGA10 = Source; $1$DGA100 = Destination

We are in the process of migrating from one san to another. So want to go with live migration as much as possible. And I was able to do offline shadowing by dismounting the disk and add the shadowset and that works. Here is the challenge, Can I keep the source $1$DGA10 available online without adding to the shadowset or dismounting as if I add to shadowset then disk will become DSA and application can't write to it. So I want to keep $1$DGA10 as it is and add $1$DGA100 to the shadowset and will it mirror?

Startup.com

$ mount/system $1$DGA10: SYSDATA SYSDATA

$ mount/system DSA10: /shadow=$1$DGA100: SYSDATA SYSDATA

So when server is rebooted, will the $1$DGA100 be mirroring(shadowing) to $1$DGA10?

Thank you!

[Volker Halle]

I'm not completely sure I understand what you're up to...

You can add $1$DGA100: to the DSA10: shadowset in the running system. It will cause a shadow-copy to be started. Applications reading/writing to DSA10: will continue with a slight performance loss while the shadow-copy operation is underway. Once the shadow-copy is completeld you should change the MOUNT command in SYSTARTUP_VMS.COM to include both members: MOUNT/SYSTEM DSA10:/SHADOW=($1$DGA10:,$1$DGA100:)  SYSDATA SYSDATA

Did this answer your question ?

Volker.

[abrsvc]

As I read theoriginal question, the answer is NO.  Once a shadowset has been created, you MUST access the shadowset using the DSA device.  The original poster wants (I believe) to access the intial drive $1$DGA10 even when the shadowset has been formed.  This will not work.

If the application accesses the current drive using a logical name, change the name to access the DSA device.  This will be an invisible change to the application and will work as you expect.  If the application(s) access the drive directly, than an application change will be necesary to use the DSA device rather than the DGA device.

[Steven Schweda]

> [...] If the application(s) access the drive directly, than an
> application change will be necesary [...]

   Will it?

its $ write sys$output f$getdvi( "dka0:", "freeblocks")
391432816

its $ write sys$output f$getdvi( "dka100:", "freeblocks")
222208575

its $ define dka100 dka0:
its $ write sys$output f$getdvi( "dka100:", "freeblocks")
391432800

   I'd use a process-specific logical name, not a system-wide one, but
why couldn't both the logical-name and the equivalence-name be physical
device names?

[3parhpux]

Issue is the particular legacy DB on the legacy system, they can't write to the DSA device and logicals also doesn't work in this scenario. Once the $1$DGA10 dismount, that means need downtime. And if I go to the minimal boot and add both $1$DGA10 and $1$DGA100, then it will be a shadowset and will become DSA disk, which means application can't use it.

So I trying to see if I can make the $1$DGA10 available while $1$DGA100 is shadowing.

[Volker Halle]

You need to convince the application to use $1$DGA100 once the migration to the new storage is complete. Why can't the application use DSA10 ?

Please note that when booting minimum, shadow-copy will NOT start !  Also remember to use MOUNT/OVER=SHADOW $1$DGA100: at least once to convert the shadowset-member $1$DGA100: back to a non-shadowed disk.

Without the use of shadowing, there is no way to prevent downtime in this scenario.

Volker.

[Steven Schweda]

> Issue is the particular legacy DB on the legacy system, [...]

   _Which_ " the particular legacy DB on the legacy system"?  How does
that explain anything?

> [...] they can't write to the DSA device and logicals also doesn't
> work in this scenario.

 "can't" or "doesn't work" is not a useful problem description.  It
does not say what you did.  It does not say what happened when you did
it.  As usual, showing actual actions (commands, code, ...) with their
actual results (error messages, ...) can be more helpful than vague
descriptions or interpretations.