ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Mainframe, CICS, TXSeries » Qmgr Alias Vs Blank - MQ on z/OS

Post new topic  Reply to topic Goto page 1, 2  Next
 Qmgr Alias Vs Blank - MQ on z/OS « View previous topic :: View next topic » 
Author Message
Ross
PostPosted: Mon Jun 14, 2010 10:09 am    Post subject: Qmgr Alias Vs Blank - MQ on z/OS Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Mon Jun 14, 2010 10:18 am    Post subject: Re: Qmgr Alias Vs Blank - MQ on z/OS Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Mon Jun 14, 2010 10:54 am    Post subject: Reply with quote

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
View user's profile Send private message
Ross
PostPosted: Mon Jun 14, 2010 11:01 am    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Mon Jun 14, 2010 11:14 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Mon Jun 14, 2010 12:48 pm    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Mon Jun 14, 2010 2:26 pm    Post subject: Reply with quote

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
View user's profile Send private message
Ross
PostPosted: Tue Jun 15, 2010 1:42 am    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Tue Jun 15, 2010 5:09 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.

A quick search on Mr. Google for mq+z/OS+default qmgr yielded this:
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=/com.ibm.mq.csqzal.doc/fg12030_.htm
_________________
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
View user's profile Send private message
Ross
PostPosted: Tue Jun 15, 2010 5:43 am    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Tue Jun 15, 2010 6:07 am    Post subject: Reply with quote

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
View user's profile Send private message
Ross
PostPosted: Wed Jun 16, 2010 3:48 am    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Wed Jun 16, 2010 5:28 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.

Quote:
CSQQDEFV

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
View user's profile Send private message
Ross
PostPosted: Fri Jun 18, 2010 2:20 am    Post subject: Reply with quote

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
View user's profile Send private message
PeterPotkay
PostPosted: Fri Jun 18, 2010 3:59 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » Mainframe, CICS, TXSeries » Qmgr Alias Vs Blank - MQ on z/OS
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.