The only exposure is at VM IPL time.  

You can have duplicate VM system volumes all you want.  It is only a problem at 
VM IPL time.

If you have multiple LPARs, you can have duplicate volumes, just code the IOCP 
to allow only one set of VM volumes to each LPAR.  

However, I have been caught by this, and was saved by IPL'ing an older 420RES 
volume.  Had sufficient of a system up to relabel the duplicate packs and allow 
the production LPAR to IPL.

In my case, I have one 390 LPAR with the VM volumes 520XXX.
The Linux LPAR has VM volumes of 521XXX.
Linux volumes are labeled LxCCUU where x is the lpar number.

The system config is used to bring online all volumes, but the 
USER_VOLUME_INCLUDE is only for 521* and L1* (for the Linux LPAR).

However, as it has been said, you get interrupted and forget to relabel the 
packs.  Then, one night you get a phone call.  You think the DASD system took a 
major hit.  You spend time worrying about it.  You are ready to cold start and 
loose the spool.  Hopefully you think about the possibility of duplicate 
volumes. And you take the right action.  Been there, done that.  Didn't get the 
t-shirt.

It isn't as critical as say, VSE, where the duplicate at the lowest CUA wins, 
and it wins at the next ASSGN card processed.  All of a sudden, you batch jobs 
start using the wrong volume.  No IPL necessary.  Just stupidity <G>


Tom Duerbusch
THD Consulting

>>> Michael MacIsaac <[email protected]> 1/30/2009 1:11 PM >>>
Kris,

> And then, all of a sudden one of your production volumes is gone (e.g.
> someone changed its label, or it was too slow to respond during IPL)
> what causes the gold image copy to become online
I don't think so - in my scenario, all 5 of the cloned z/VM labels have 
changed. 

So to reiterate:
1) Install vanilla z/VM with default labels at highest addresses (no 
duplicate volsers exist)
2) Shut door, get off email, get off IM :))
3) Clone to target disks (now duplicates exist - start the clock)
4) IPL new clone on target LPAR (3 minutes)
5) Run IPWIZARD on integrated 3270 console (5 minutes)
6) Get 3270 session and relabel volsers per documentation - I use sec 4.11 
of the Virt'n cookbooks (15 minutes)
7) SHUTDOWN REIPL and cross fingers (no more duplicates)

So in this example the duplicate volsers exist for about 23 minutes. Yes, 
something could go wrong in this timeframe, but I haven't lost much.

Does this sound better?

> my customer's operators caused such a mess in a disaster test weekend 
...
And looking on the bright side: this is when you really learn z/VM :))

"Mike MacIsaac" <[email protected]>   (845) 433-7061

Reply via email to