| Author |
Message
|
| Vitor |
 Posted: Mon Feb 09, 2009 3:28 pm Post subject: |
 |
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| tanishka wrote: |
problem is not connect to QC.OCF.RDF.REQUEST. and getting below error and no linked exception
|
IF you have correctly coded the application to pick up the linked exception, and there is no linked exception, then raise a PMR with IBM because the software is failing. Without the reason code we are all guessing what the problem is.
If you have not coded to pick up the linked exception, revise the code (because you should be doing this anyway), see what the reason code is and resolve the problem from there.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Feb 09, 2009 9:41 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20757
Location: LI,NY
|
And I hope that in your permissions you remembered that JMS requires inq as permission... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| tanishka |
| Posted: Wed Feb 11, 2009 8:01 am Post subject: |
|
|
Centurion
Joined: 24 Nov 2008
Posts: 144
|
the below error they getting
com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2035
when i want to see authorizations for this queue below is output
dspmqaut -m QMA -n QC.OCF.RDF.REQUEST-t q -p admocf
AMQ7085: Object QC.OCF.RDF.REQUEST, type q not found.
i know it was defined under Q17S as cluster queue. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 11, 2009 8:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| tanishka wrote: |
| AMQ7085: Object QC.OCF.RDF.REQUEST, type q not found. |
So it's throwing a 2035, and dspmqaut says there's nothing defined.
Not an unreasonable state of affairs there. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Feb 11, 2009 8:23 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| tanishka wrote: |
the below error they getting
com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2035
when i want to see authorizations for this queue below is output
dspmqaut -m QMA -n QC.OCF.RDF.REQUEST-t q -p admocf
AMQ7085: Object QC.OCF.RDF.REQUEST, type q not found.
i know it was defined under Q17S as cluster queue. |
No surprises there then as further up the thread...
| tanishka wrote: |
| QC.OCF.RDF.REQUEST cluster queue defined in QM17S and QC.RDF.OCF.REPLY cluster queue defined in QMA. |
...you stated that queue QC.RDF.OCF.REPLY is defined in QMA (UNIX) and queue QC.RDF.OCF. REQUEST is defined in QM17S (z/OS - which is pretty damned good as I thought all z/OS sub-system names were four character).
You might want to check RACF authorisations etc. 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| tanishka |
| Posted: Wed Feb 11, 2009 8:44 am Post subject: |
|
|
Centurion
Joined: 24 Nov 2008
Posts: 144
|
[quote]You might want to check RACF authorisations etc
on mainframe side?
| Quote: |
| Not an unreasonable state of affairs there |
now what i need to do application to connect QC.RDF.OCF. REQUEST |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Feb 11, 2009 8:57 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| now what i need to do application to connect QC.RDF.OCF. REQUEST |
Until you have sufficient authorization to connect to the queue manager and open the queue, etc., there is nothing you can do in your application to make this work.
When the RACF security admins grant you appropriate authorizations, try your application again to see if it works. If it doesn't, repeat the problem-determination cycle, namely: what ReasonCode? what does it mean? persue the appropriate resolution, try again.
_________________
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 |
|
|
| exerk |
| Posted: Wed Feb 11, 2009 9:04 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| tanishka wrote: |
| on mainframe side? |
As that is where the queue resides (according to your posts) what do you think?
| tanishka wrote: |
| ...now what i need to do application to connect QC.RDF.OCF.REQUEST |
Oh lordy....
Please correct me if I'm wrong, but:
1. Application on UNIX (via queue manager QMA) puts a REQUEST message to queue QC.RDF.OCF.REQUEST, which is a clustered queue on z/OS (queue manager QM17S)
2. Application on z/OS (via queue manager QM17S) gets the REQUEST message, processes it and forms a REPLY message, which it puts to queue QC.RDF.OCF.REPLY, which is a clustered queue on UNIX (queue manager QMA).
3. Application on UNIX (via queue manager QMA) gets the REPLY message and processes it, and everything is hunky dory.
The above is what I deduce from your posts to be what you are trying to achieve, but happy to concede I have got completely the wrong end of the snake...oh, and I'd still like to know how you managed to have a five character z/OS sub-system name.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| tanishka |
| Posted: Wed Feb 11, 2009 10:04 am Post subject: |
|
|
Centurion
Joined: 24 Nov 2008
Posts: 144
|
excellent. that's perfect.
the quemanaer name actually four characters. just renamed in this post.sorry for that. |
|
| Back to top |
|
|
| tanishka |
| Posted: Thu Feb 12, 2009 10:00 am Post subject: |
|
|
Centurion
Joined: 24 Nov 2008
Posts: 144
|
Hi All,
I am glad that application able to connect request queue. since unix admin made some changes to application ID.
Thanks for all your support |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Feb 12, 2009 10:34 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| since unix admin made some changes to application ID. |
Please be specific so we can learn from this. What exactly fixed your problem?
_________________
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 |
|
|
| exerk |
| Posted: Thu Feb 12, 2009 11:02 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| bruce2359 wrote: |
| Quote: |
| since unix admin made some changes to application ID. |
Please be specific so we can learn from this. What exactly fixed your problem? |
My guess is they created a user that already exists on z/OS, and which has the required RACF authorisation on the target queue.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| tanishka |
| Posted: Thu Feb 12, 2009 11:17 am Post subject: |
|
|
Centurion
Joined: 24 Nov 2008
Posts: 144
|
To be honest i don't know what he made changes exactly. I asked him he didn't tell anything. again i will try and come
| Quote: |
| My guess is they created a user that already exists on z/OS, and which has the required RACF authorisation on the target queue |
no changes have made on mainframeside only on unix side[/quote] |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Feb 12, 2009 9:06 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20757
Location: LI,NY
|
Possibly the MQ admin created the q as a qremote that resolves to a the cluster queue and gave permissions for that remote queue....
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Feb 13, 2009 1:05 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| tanishka wrote: |
To be honest i don't know what he made changes exactly. I asked him he didn't tell anything. again i will try and come
| Quote: |
| My guess is they created a user that already exists on z/OS, and which has the required RACF authorisation on the target queue |
no changes have made on mainframeside only on unix side |
On the UNIX side by implication, as that would generally be easier to change than the z/OS side...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
|
|
