MQSeries.net :: View topic

harlando2 · Posted: Wed Nov 01, 2006 6:30 am Post subject:

We have a unix lpar with v5 and v6 message broker installed sharing the same broker database. There are lots of active v5 brokers on there.

After v6 install, we created the first v6 broker using the wrong database user name and password which appears to have messed up the v6 migration. We submitted this

mqsicreatebroker BMBOAP1A -i wmqiuid -a wmqiuid99 -q QMBOAP1A -n DWDCBRK1 -u system -p cc6_system

And we should have submitted this

mqsicreatebroker BMBOAP1A -i wmqiuid -a wmqiuid99 -q QMBOAP1A -n DWDCBRK1 -u wmqiuid -p snoopy

After realising our error we deleted the broker called BMBOAP1A with the mqsideletebroker command and then resubmitted using the correct credentials and we experienced the following error:

AMQ8110: WebSphere MQ queue manager already exists.
WebSphere MQ queue manager running.
The setmqaut command completed successfully.
The setmqaut command completed successfully.
The setmqaut command completed successfully.
The setmqaut command completed successfully.
The setmqaut command completed successfully.
The setmqaut command completed successfully.
The setmqaut command completed successfully.
The setmqaut command completed successfully.
The setmqaut command completed successfully.
The setmqaut command completed successfully.
The setmqaut command completed successfully.
The setmqaut command completed successfully.
The setmqaut command completed successfully.
The setmqaut command completed successfully.
The setmqaut command completed successfully.
BIP8703S: Column 'RTD_MSG_SET_ALIAS' is missing from database table 'WMQIUID.BRMRTDINFO'
BIP8703S: Column 'PROCARCHITECTURE' is missing from database table 'WMQIUID.BROKERAAEG'
BIP8702W: Post-migration check failed; see previous messages for possible causes.
The migration utility found configuration errors for the component. This means that the component configuration is not correct in some way; previous messages should provide the exact errors.
Examine previous messages, and errors reported during migration steps, to determine the cause of the failure. The migration may need to be reversed, or completed manually.

Looking at the database I can see that we have two instances of the same tables e.g. BROKERAAEG. wmqiuid.BROKERAAEG is v5 config populated with data. system.BROKERAAEG is v6 config with no data. If I dropped all the system owned broker database tables and resubmitted using the wmqiuid database logon would this force the mqsicreatebroker command to think it has to alter the table definitions for version 6 again? Is there some special flag stored somewhere that tells the mqsicreatebroker to perform the v6 broker database changes?

Example output from broker database.

OWNER TABLE_NAME
------------------------------ ------------------------------
SYSTEM BROKERAA
WMQIUID BROKERAAEG
SYSTEM BROKERAAEG

SQL> select count(*) from wmqiuid.BROKERAAEG;

COUNT(*)
----------
117

SQL> select count(*) from system.BROKERAAEG;

COUNT(*)
----------
0
_________________
Kristian

Environment
---------------
AIX 5.2.0.0
V6 brokers at CSD2
Win 2000 Config manager at CSD2
WIN xp desktop at CSD2