| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| WMQI and WBIMB Coexistence |
View previous topic :: View next topic |
| Author |
Message
|
| CHF |
 Posted: Wed Jun 08, 2005 4:47 am Post subject: WMQI and WBIMB Coexistence |
 |
|
Master
Joined: 16 Dec 2003
Posts: 297
|
Hello,
We are on z/OS and planning to have both v2.1 and v5 Broker co-exist. I went through the migration doc and I didn't understand
The broker schema of the message flow must not contain, at the schema level, any of the following in its ESQL files: – A PATH statement – The declaration of a constant, which includes a NAMESPACE or NAME constant
– The definition of a function – The definition of a procedureIn addition, the broker schema must not contain a mapping file. These conditions mean that the broker schema can contain only module definitions.
And the migration doc says message flow deployed on wmqi 2.1 cannot contain 'DataDelete', 'Extract'..... this means if we have already deployed flows on v2.1 do we have to modify or update them??
And I want to know do I have to make any updates for existing message flows or message sets ??
Thanks.
_________________
CHF  |
|
| Back to top |
|
 |
| RocknRambo |
| Posted: Wed Jun 08, 2005 2:36 pm Post subject: |
|
|
Partisan
Joined: 24 Sep 2003
Posts: 355
|
During our Migration.. we did face few Issues similarly.. pblms with nested queries.. and so on..
we manually edited the .esql before deploying...
-RR |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jun 09, 2005 3:20 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If you want to run a v5 configMgr - which you have to do to talk to v5 brokers, you have to migrate *all* of your message flows and sets from 2.1 to v5.
You can still then deploy the migrated flows to 2.1 brokers from the v5 configmgr. But you will have to reregister them with the new configmgr.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| CHF |
| Posted: Thu Jun 09, 2005 4:37 am Post subject: |
|
|
Master
Joined: 16 Dec 2003
Posts: 297
|
| jefflowrey wrote: |
If you want to run a v5 configMgr - which you have to do to talk to v5 brokers, you have to migrate *all* of your message flows and sets from 2.1 to v5.
You can still then deploy the migrated flows to 2.1 brokers from the v5 configmgr. But you will have to reregister them with the new configmgr. |
When we talk about migration is something like copying db2 database from old config mgr to new config mgr db can be done... or we have to migrate each and every flow and message set??
Thanks
_________________
CHF |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jun 09, 2005 5:06 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| CHF wrote: |
| ... or we have to migrate each and every flow and message set?? |
| Migration wrote: |
Before you start to migrate a WebSphere MQ Integrator Broker Version 2.1 broker domain, do the following:
1. Make sure that Control Center users have checked in all WebSphere MQ Integrator Broker resources. For information about how to use the Control Center to perform this and other tasks, see WebSphere MQ Integrator Broker Version 2.1 Using the Control Center.
2. Back up all configuration repository, message repository, and broker database tables. For information about how to do this, see the WebSphere MQ Integrator Broker Version 2.1 Administration Guide.
3. Decide which message flows and message sets you want to migrate and use in the WebSphere Business Integration Message Broker broker domain.
a. Using a Control Center session in which all the required message flows are visible in the workspace, export the message flows. Save the export files in a directory other than the one in which WebSphere MQ Integrator Broker is installed. The export files also contain information about the user defined nodes that are used by the message flows. For advice on how to export the message flows, see “Migrating a message flow” on page 6.
b. On the system where the Configuration Manager is running, export all the required message sets using the mqsiimpexpmsgset command with the -e parameter. Save the export files in a directory other than the one in which WebSphere MQ Integrator Broker is installed. For information about how to use this and other WebSphere MQ Integrator Broker commands, see the WebSphere MQ Integrator Broker Version 2.1 Administration Guide.
4. Decide how you are going to migrate the brokers:
* Decide which brokers you no longer require after migration. v Decide which brokers you want to migrate from the Version 2.1 level of code to the Version 5.0 level.
* Decide which brokers you want to preserve at the Version 2.1 level of code. If two or more of the brokers share the same set of database tables, and you still require these brokers after migration, you must either migrate all of the brokers at the same time or preserve them all at the Version 2.1 level of code.
5. For each broker that you want to migrate from the Version 2.1 level of code to the Version 5.0 level, and for the associated assignments configuration data you want to preserve, record the following information:
* The name of the broker.
* The name of each message set that is assigned to the broker.
* The name of each execution group within the broker.
* For each execution group within the broker, the name of each message flow that is assigned to the execution group.
* For each message flow assigned to an execution group, the following properties:
– Additional instances
– Commit count
– Commit interval
– Coordinated transaction
Record this information in one of the following ways:
* You can view the information in a Control Center session and record it manually.
* You can export everything in the Control Center workspace by clicking File -> Export All in Workspace. Save the export file in a directory other than theone in which WebSphere MQ Integrator Broker is installed. You can then extract the required information from the export file. To find out how to do this, see “Assignments configuration data in an export file” on page 54.
6. Decide whether you want to preserve the following configuration data, which is stored in the configuration repository:
* Assignments data
* Topology data
* Topics data
Unless you decide that you no longer require any of your existing brokers after migration, you must preserve this configuration data.
7. Decide which components of WebSphere Business Integration Message Broker you want to run on each of your systems after migration. Consider the following when making your decision:
* A broker must run on the same system and use the same queue manager as it did before migration unless you decide that you no longer require the broker after migration.
* The Configuration Manager must run on the same system and use the same queue manager as it did before migration unless you decide not to preserve the assignments, topology, and topics data in the configuration repository.
* A workbench can run on any system after migration. It does not have to run on a system where Control Center sessions used to run.
* To avoid adding unnecessary complexity into the migration process itself, run a User Name Server on the same system, and configure it to use the same queue manager, as it did before migration. If required, you can change the location of a User Name Server and the queue manager it uses after a successful migration.
You do not need to change the configuration of a queue manager that is preserved during migration. You might, however, need to ensure that the WebSphere MQ product code is at the required release and service level to support WebSphere Business Integration Message Broker. At the same time, you might want to ensure that you have installed the other software prerequisites. See Checking software prerequisites for the details. If you are not able to stop a broker during migration because it is doing critical work, but you want to migrate the broker to the Version 5.0 level of code, create a new Version 2.1 broker on a system on which you are not going to install WebSphere Business Integration Message Broker. Using a Control Center session, deploy to the new broker all the configuration data that was deployed to the original broker. The new broker can then take over the work of the original broker during the migration. If you intend to preserve any brokers at the Version 2.1 level of code, see “Coexistence with previous releases and other products” on page 41 for what you need to consider in this case.
8. Decide where you are going to store the development data that is created and maintained in the workbench. You can store the data in the local file system, on a shared drive, or in a shared repository that is supported by Eclipse. The instructions for the individual migration tasks assume that you are using the local file system or a shared drive. |
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| CHF |
| Posted: Thu Jun 09, 2005 5:16 am Post subject: |
|
|
Master
Joined: 16 Dec 2003
Posts: 297
|
Thanks Jeff.
_________________
CHF |
|
| Back to top |
|
|
|
|
|
|
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
