1.

Moving vobs

have been asked to get some of our VOBs to another company. I know ideally using Multi-Site is the best
way but neither of the companies is using that. What is the easiest way to get these VOBs moved from
one company to another. Would using export and import work or what? Any ideas and help is greatly
appreciated.

Thanks!

If CC version and host OS/architecture are the same, lock, unregister, copy and register. If not, lock,
unregister, reformatvob -dump, copy, reformatvob -load and register. Moving between Windows and
UNIX, user identities must be mapped with vob_siddump/vob_sidwalk.

2.query about chmaster & mkreplica 11 Months, 1 Week ago Karma: 0

could someone please clarify me about below.

chmaster - how can I compute the time it takes to transfer the masterships of all the objects at
one site to another? does chmaster -all transfer the mastership of replica as well?

mkreplica - for a site hosting vobs of around 500GB of space each vob is around 25GB, how
much temp-space ( -workdir) would I need to create the replica-creation packets. Also what
would be the size of the replica-creation packets for a vob of around 25GB?

chmaster - how can I compute the time it takes to transfer the masterships of all the objects at
one site to another?
Don't know... Try with a few, and extrapolate?
It all depends on your replication anyway. How the packets are shipped, how many hops, do you
use a receipt handler on the shipping server hosts, and then of course, what is the latency (and
even the bandwidth).
And what else will there be in your sync packets.
does chmaster -all transfer the mastership of replica as well?
Yes... Including the local replica, and you don't what that if you still intend to use it...

So last time I was asked to do something like that, I transferred the different bits separately:

 You need to be the vob owner, and to have a view context

 You want to retain the mastership of the local replica (otherwise you could use -all)
 Pay attention to files with spaces in their name

 Take care of locks:

o Locks are not replicated unless they are -obsolete

o In any case, if you need to change the mastership of a locked object, you need to
first unlock it (it doesn't make much sense to lock it -nusers yourself)

o The easiest is to try to chmaster, and to process the error list.

o Now with locked objects, it probably doesn't make sense to transfer mastership at
all!
You'd rather make sure the locks are -obsolete, thus visible to other sites, in a way
which will not disturb them, yet retains the guarantee you once made to avoid
modifying them.

 Because of the metadata type prefix, and because elements have nothing equivalent, one
needs to handle at least the two kinds of objects separately (even with %Km: in the
format, one needs an explicit :).
tgr> ct lsmaster -fmt "%m:%nn" eeiath_mnoss_tgr | cut -d: -f1 | sort -u
branch type
directory element
file element
label type
replica
tgr> ct lsmaster -fmt 'chmaster xtesa_mnoss_tgr "%n"n' -kind delem,felem eeiat
h_mnoss_tgr | cleartool >/dev/null
tgr> ct lsmaster -fmt 'chmaster xtesa_mnoss_tgr %Km:%nn' -kind lbtype,brtype e
eiath_mnoss_tgr | cleartool >/dev/null
tgr> ct lsmaster -fmt 'lock -rep -obs %Km:%nn' -kind lbtype,brtype eeiath_mnos
s_tgr | cleartool >/dev/null

3.