Peter,
> What is the right way to get QM2FULL to get itself
up to date????
>
>REFRESH CLUSTER(CLUSTER1) REPOS(NO) did not do it.
You would have to use REPOS(YES) on QM2FULL after
altering it so that it is not a full rep. The steps
are:
1- Alter QM2FULL REPOS(' ')
2- REFRESH CLUSTER(CLUSTER1) REPOS(YES)
3- Alter QM2FULL REPOS(CLUSTER1)
Regards,
Ruzi
--- "Potkay, Peter M (PLC, IT)"
<[EMAIL PROTECTED]> wrote:
> The REFRESH command does not accomplish what I need.
> I guess I will see what
> IBM says. I'll post there answer.
>
>
> Kumar gave me this idea. What do you guys think?
>
> 1.) Start the QM back up after the image restore.
>
> 2.) Alter the QM to be a partial repository.
> (Cluster now has only 1 full
> repository)
>
> 3.) Remove the QM from the cluster.
>
> 4.) Reintroduce the QM to the cluster as a full
> repository.
>
>
> Would reintroducing this QM again as a "new" full
> repository work, and cause
> the other full repository to push everything over?
> Or would I corrupt the
> cluster with duplicate entries for that QM, even
> though the QMID stayed the
> same?
>
>
>
>
>
>
> -----Original Message-----
> From: John Scott [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 16, 2004 3:37 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Image backup of a Full Repository QM.
> Then a restore. Uh-oh
>
>
> I hear what you are saying and your theory sounds
> fine, however, the Queue
> Manager Clusters manual in Chapter 7 says the
> following on recovering a
> Queue Manager:
>
> Recovering a queue manager
> To recover a queue manager in a cluster, restore the
> queue manager from a
> linear log. (See the WebSphere MQ System
> Administration Guide for details)
>
> If you have to restore from a point-in-time backup,
> issue the REFRESH
> CLUSTER command on the restored queue manager for
> all clusters in which the
> queue manager participates.
>
> There is no need to issue the REFRESH CLUSTER
> command on any other queue
> manager.
>
> So if yo do this and it does not work, then it would
> seem about the right
> time to call IBM support to find out why it doesn't
> work.
>
> Regards
> John Scott
> IBM Certified Specialist - MQSeries
> Argos Ltd
>
>
> -----Original Message-----
> From: Potkay, Peter M (PLC, IT)
> [mailto:[EMAIL PROTECTED]
> Sent: 15 January 2004 13:24
> To: [EMAIL PROTECTED]
> Subject: Re: Image backup of a Full Repository QM.
> Then a restore. Uh-oh
>
>
> In the cluster manual, they do talk about fixing a
> QM that was restored from
> an image backup. But in the example, they only deal
> with a QM that was, is
> and will be a partial repository. The refresh
> command works fine in this
> case, since all it does it is PUSH out all its info
> to the full
> repositories, and then learns about other queues in
> the cluster on an
> as-need-to-know basis from the fulls.
>
> A full repository needs to PULL in info from the
> other full repository in
> this case, so that it knows everything. The problem
> I was having was that
> puts were failing because the QM did not know about
> the other new queues in
> the cluster, and being a full repository itself, it
> considered itself the
> definitive source. "If I don't know about, it must
> not be true!!!" It did
> not even bother checking with the other full.
>
> I don't see how issuing that command, even after
> making it a partial and
> using the repos yes option, would give me what I
> want.
>
> Consider a cluster with 1000 partial repositories
> and 2 full. If I made a
> new QM that is a partial and issued the REFRESH
> command, even with repos
> YES, that new QM would not suck in all the info for
> all 1000 QMs held in the
> full repositories. It would only push out its own
> info to the fulls. And it
> would only get new info on queues on those 1000
> other QMs as it needed them.
>
>
> I need a particular QM (QM2FULL) to suck in ALL the
> info from another QM's
> full repository (QM1FULL). The refresh command does
> not do that. It pushes
> info our rather than pulling info in.
>
> Its almost as if I need a SYNC type command, to tell
> one QM to get all the
> Full repository info from another QM.
>
> I had hoped that QM2FULL would connect and sync with
> QM1FULL when I brought
> it back up, but it did not.
>
> I guess it almost makes sense that it didn't. Full
> repositories do not
> constantly talk to each other for no reason. They
> just update each other
> when there is new info to share. When QM2FULL was
> restored, QM1FULL just saw
> that event as his buddy coming back up, not a new QM
> that needed to be told
> everything.
>
> Since QM2FULL was the exact QM, why would QM1FULL
> need to push everything
> over again? How would QM1FULL know that QM2FULL was
> out of sync? Maybe
> QM1FULL was out of sync. And how would it even know
> how long it has been out
> of communication with its partner QM? Maybe it was
> only 1 second, or 1 week.
> These questions make me believe that the full
> repositories do not keep
> pulsing info back and forth. And why perhaps a "SYNC
> from QM1 to QM2" type
> command is needed for Full Repositories?
>
>
>
>
> -----Original Message-----
> From: John Scott [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 15, 2004 3:38 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Image backup of a Full Repository QM.
> Then a restore. Uh-oh
>
>
> According to the command reference manual, REFRESH
> CLUSTER is not normally
> necessary unless: <snip/> The queue manager has been
> restarted from an
> earlier point in time than it last finished, (for
> example, by restoring
> backed up data.)
>
> I assume that this command gets run on the qmgr you
> restored, not on the
> queue manager with the queue definitions.
>
> Regards
> John Scott
> IBM Certified Specialist - MQSeries
> Argos Ltd
>
>
> -----Original Message-----
> From: Potkay, Peter M (PLC, IT)
> [mailto:[EMAIL PROTECTED]
> Sent: 14 January 2004 20:45
> To: [EMAIL PROTECTED]
> Subject: Image backup of a Full Repository QM. Then
> a restore. Uh-oh
>
>
> QM1FULL and QM2FULL are full repositories for
> CLUSTER1.
>
=== message truncated ===
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
