| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| How to migrate to QSG without changing Application Code |
« View previous topic :: View next topic » |
| Author |
Message
|
| dogbert64 |
 Posted: Tue Dec 09, 2008 2:35 pm Post subject: How to migrate to QSG without changing Application Code |
 |
|
Acolyte
Joined: 11 Jun 2003
Posts: 58
|
HI- we are running MQ 6.0 on z/OS 1.9. We have 2 LPARs in our SYSPLEX, but are only running MQ on one of them. The 2nd LPAR was just brought up a few months ago to give DB2 high availability, especially while we IPL the first LPAR on the weekend.
The LPAR names are ZOS1 and ZOS2. The queue manager name is PMQ1 and it runs on ZOS1. No MQ runs on ZOS2 (currently).
We also have some distributed Queue Managers (MQ 6.0) which run on Windows and send/receive MQ messages from PMQ1.
Applications have been using PMQ1 for about 8 years now, so as you can guess, almost all of them have been hard coded to connect to QM PMQ1.
The marching orders I have been given has been to implement QSG and make it as transparent (as possible) to these applications.
Is this possible? Can we call the QSG PMQ1 and have a QM on ZOS1 called PMQ1 at the same time? Or do we have to create a QSG called PMQ1 and delete/redefine (or rename) PMQ1 to something like PMZ1?
I guess it goes without saying we will also be building a Queue Manager on ZOS2 and having it as part of the QSG as well. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed Dec 10, 2008 7:23 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Yes.
| Quote: |
| Can we call the QSG PMQ1 and have a QM on ZOS1 called PMQ1 at the same time? |
Yes.
| Quote: |
| Or do we have to create a QSG called PMQ1 and delete/redefine (or rename) PMQ1 to something like PMZ1? |
Yes to first part; not necessary to the second.
MQCONNect can be to a specific qmgr or to a qsg. No app changes will be needed to achieve the simplest WMQ application designs that you currently have without qsg's.
More advanced qsg features will require some code changes. An example is intra-group messaging - sending a message from one qmr in the qsg to another, all within the CF, within the qsg without the need for point-to-point channels.
IBM offers an advanced system admin course that covers qsg defining qsg's. Visit https://www-304.ibm.com/jct03001c/services/learning/ites.wss/us/en?pageType=course_description&courseCode=WM310
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Dec 10, 2008 8:44 am Post subject: Re: How to migrate to QSG without changing Application Code |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| dogbert64 wrote: |
The marching orders I have been given has been to implement QSG and make it as transparent (as possible) to these applications.
|
What's riskier? What has the potential for more outages? What will cost the company more money?
A. The programs change at most 4 characters in their code to reference the the new QSG name instead of the QM name at MQCONN time.
B. You tear down a mainframe QM and build a new one in its place?
How do the apps deal with the QM name changing when going from test to PROD?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| dogbert64 |
| Posted: Thu Dec 18, 2008 7:19 am Post subject: Re: How to migrate to QSG without changing Application Code |
|
|
Acolyte
Joined: 11 Jun 2003
Posts: 58
|
| PeterPotkay wrote: |
What's riskier? What has the potential for more outages? What will cost the company more money?
A. The programs change at most 4 characters in their code to reference the the new QSG name instead of the QM name at MQCONN time.
B. You tear down a mainframe QM and build a new one in its place?
|
I agree with you. I would rather have stood up a new QSG and 2 new QMs from the ground up and have the developers change their code to connect to it. Since it's not "transparent and automatic" then it makes a wonderful touchpoint to go over with the developer to ensure proper conduct of their code before they can start storing messages in the coupling facility. That way I get to act in a Gatekeeper role. And I'll still try to pull it off, but given my "marching orders" I'm not betting on it.
I can't think of a very good technical reason to have the name of the QSG different from one of the QM names, but I think its a good practice. Something deep down inside of me says that one day, having the QSG named the same as one of the Queue Managers will come back to bite me in the butt. 25 years of IT experience gives you these "bad vibes" from time to time. 
| PeterPotkay wrote: |
How do the apps deal with the QM name changing when going from test to PROD? |
We have 4 environments - DEV, INTG, SYST and PROD. From INTG to PROD, they keep the same QM name and each environment is localized to its own LPAR. That way, all the names are the same as the code progresses...DSN, CICS Regions, MQ Queue Managers, DB2, etc.
It's not a perfect setup, but it works (most of the time). The emphasis when this was designed was to keep the developers from changing ANYTHING as they promote code from environment to environment. Its not necessarily how I would have set it up, but it is what it is. We've had it this way for 6+ years, so bucking it is virtually impossible. |
|
| Back to top |
|
|
| markt |
| Posted: Thu Dec 18, 2008 7:55 am Post subject: |
|
|
Knight
Joined: 14 May 2002
Posts: 508
|
From the z/OS Planning Guide - it was not difficult to find the information:
| Quote: |
| Queue-sharing groups have a name of up to four characters. The name must be unique in your network, and must be different from any queue manager names. |
|
|
| 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
|
|
|
|
