Author |
Message
|
Ross |
Posted: Mon Jun 14, 2010 10:09 am Post subject: Qmgr Alias Vs Blank - MQ on z/OS |
|
|
Centurion
Joined: 15 Jun 2005 Posts: 127 Location: Ireland
|
Hi.
An app programmer wants to put a message to a QL on my z/OS qmgr.
He says he has to hard code the Q and Qmgr name into the IMS program code.
So for Test and Prod we can use a QAlias and the same name, but the Qmgr names differ obviously.
He would prefer to use the same code rather than have 2 compiles.
Is there a way to use a Qmgr alias to resolve this?
If the Qmgr field is blank, will it just resolve to the host default qmgr? If so, is there a way to verify if there is a default qmgr? Not sure how this works on mainframe, as I've only seen default used on midrange. I have 2 (clustered) mf qmgrs in each of test and prod.
Thanks,
Ross. |
|
Back to top |
|
 |
Vitor |
Posted: Mon Jun 14, 2010 10:18 am Post subject: Re: Qmgr Alias Vs Blank - MQ on z/OS |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Ross wrote: |
He says he has to hard code the Q and Qmgr name into the IMS program code. |
Why? Are you using the IMS adapter and/or bridge? Why can't the qmgr name by located using environmental means (if not)? _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
bruce2359 |
Posted: Mon Jun 14, 2010 10:54 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Quote: |
He says he has to hard code the Q and Qmgr name into the IMS program code. |
Is the IMS program MQ-aware? Does he code MQ calls in the IMS app? What happens if he doesn't code qmgr name? _________________ 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 |
|
 |
Ross |
Posted: Mon Jun 14, 2010 11:01 am Post subject: |
|
|
Centurion
Joined: 15 Jun 2005 Posts: 127 Location: Ireland
|
I have the Bridge and Adapter set up.
This app is using the Adapter, and so the code is MQ aware. They are unable to use an input file or table to pass in parms (like qmgr) so I believe they need to hard code the value.
Any alternative suggestion would be good!
He has not tried a blank value. I had read about it, but not sure if it work in z/OS, or how to verify the default qmgr. I believe there is a change procedure to recompile, so trying to investigate this a little before suggesting the blank value!
Vitor, what do you mean by environmental means?
Thanks,
Ross. |
|
Back to top |
|
 |
bruce2359 |
Posted: Mon Jun 14, 2010 11:14 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Quote: |
He has not tried a blank value. |
Have him leave Qmgr blank. (There are near zero reasons for an application to specify both the Queue name and the Qmgr name.)
Let the qmgr the app connects to resolve the queue name to whatever/wherever the QL exists. _________________ 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 |
|
 |
Vitor |
Posted: Mon Jun 14, 2010 12:48 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Ross wrote: |
He has not tried a blank value. |
He should.
Ross wrote: |
Vitor, what do you mean by environmental means?
|
I meant something like an input table or JCL Parm. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
bruce2359 |
Posted: Mon Jun 14, 2010 2:26 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Quote: |
I meant something like an input table or JCL Parm. |
If there is an actual requirement that the name(s) of qmgrs be determined in real-time, AND may need to be changed in real-time, this method works.
This is not what the OP was looking for. _________________ 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 |
|
 |
Ross |
Posted: Tue Jun 15, 2010 1:42 am Post subject: |
|
|
Centurion
Joined: 15 Jun 2005 Posts: 127 Location: Ireland
|
Thanks for the information.
I will have the user try the blank QMGR value.
Is there any way to tell which qmgr is the default one on a mainframe LPAR?
Thanks. |
|
Back to top |
|
 |
bruce2359 |
Posted: Tue Jun 15, 2010 5:09 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
|
Back to top |
|
 |
Ross |
Posted: Tue Jun 15, 2010 5:43 am Post subject: |
|
|
Centurion
Joined: 15 Jun 2005 Posts: 127 Location: Ireland
|
Thanks.
So CSQQDEFV specifies the default qmgr for IMS, and I have this specified.
So the null value should work.
Thanks.
I'll report back with results! |
|
Back to top |
|
 |
bruce2359 |
Posted: Tue Jun 15, 2010 6:07 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
No, the CSQQDEFV specifies the default qmgr for any/all applications that do not specify a qmgr name in the MQCONNect call. The default value table is not specific to IMS.
But now I'm confused. Which MQ call is the programme having difficulties with? The MQCONN call? The MQOPEN call? Or the MQPUT call? _________________ 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 |
|
 |
Ross |
Posted: Wed Jun 16, 2010 3:48 am Post subject: |
|
|
Centurion
Joined: 15 Jun 2005 Posts: 127 Location: Ireland
|
It is an MQPUT1 call.
They say they should not have to do a CONN or OPEN with a PUT1.
I believe CSQQDEFV is for IMS connections, and I have this table set to my qmgr.
CSQBDEFV is for batch, and I believe more general. |
|
Back to top |
|
 |
bruce2359 |
Posted: Wed Jun 16, 2010 5:28 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Ooops. See what speed-reading does to me? _________________ 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 |
|
 |
Ross |
Posted: Fri Jun 18, 2010 2:20 am Post subject: |
|
|
Centurion
Joined: 15 Jun 2005 Posts: 127 Location: Ireland
|
Further investigation has revealed hy the developers thought they shouldn't be doing an MQConn.
You don't need to do one in CICS, due to the direct Region to Qmgr connection.
So, with this IMS connection, they are trying an MQConn, and an MQPUT1, both with blanks in the qmgr.
This MQConn fails with a 2058 (Qmgr name error).
If they hard code the qmgr in the MQConn, and blank in the PUT1, it works fine.
Am I right in thinking blanks should work for the qmgr field in the MQConn if the default qmgr has been specified as default in the CSQQDEFV (and CSQBDEFV) modules? |
|
Back to top |
|
 |
PeterPotkay |
Posted: Fri Jun 18, 2010 3:59 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
In SYS1.SCSQAUTH, CSQBDEFV and CSQQDEFV live with the default IBM QM name of CSQ1. Batch jobs and IMS systems stick their QM specific *.SCSQAUTH ahead of the SYS1.SCSQAUTH in their JCL. The QM specific *.SCSQAUTH libraries have QM specific CSQBDEFV and CSQQDEFV that point to that particular QM. If you browsed these CSQBDEFV and CSQQDEFV members, you would see your QM name in it. Or you might find the default QM name IBM supplies, CSQ1. These CSQBDEFV and CSQQDEFV are compiled executable code. Instructions on how to produce them are in the manuals.
Yes, IMS and batch programs can be set up so that they don't need to specify a QM name on the MQCONN call. Whether they need to specify a destination QM on a MQOPEN or MQPUT1 depends entirely on where the queue name they are putting to lives. In a typical Request / Reply model, you would need to specify the name of the remote queue manager on the MQOPEN / MQPUT1. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
|