| Author |
Message
|
| steinra |
 Posted: Thu May 23, 2002 2:11 pm Post subject: expire report message not being delivered |
 |
|
Apprentice
Joined: 23 May 2002
Posts: 28
Location: USA
|
I have an interesting issue. I have two queue managers, one AIX the other AS/400. The application sends a request message from the AIX system to the AS/400 via a remote queue. The message is set to return an expire report if the message expires.
If I stop the channel between the two queue managers, wait for the message to expire (it is on the transmit queue), and then start the channel, I will get a report in the reply to Q.
Now if I stop the application on the AS/400 and monitor the queue there, when the message is put it is visible in the queue until the expire hits. Then the message is gone. (I am sure the AS/400 tools are issuing a BROWSE option which should cause the message to be deleted off the queue because it has expired). What is not happening is I am not getting a report message back from the AS/400 indicating the message expired.
Any suggestions? I have not checked my DLQ on the 400 yet (I don't have access), but the header in the message works for the application to get the reply message back to the AIX system.
Thanks!
Randy |
|
| Back to top |
|
 |
| muralidhar |
| Posted: Fri May 24, 2002 8:14 am Post subject: |
|
|
Acolyte
Joined: 28 Feb 2002
Posts: 50
|
We experienced similar kind of problem when using Windows NT(OS for local QMgr) and OS/390(OS for remote QMgr). Finally we found that on OS/390 a destructive GET method should be called in order for us on Windows to receive a Report message. It seems, this is how it works on OS/390.
I suspect it might be the same reason on AS/400 too.
The second possible reason might be a security issue. When your message expires on the local queue of remote Qmgr, then Remote QMgr tries to send the report message with the userId set in the original message(this depends on the security setup on your side). And if that userid is not authorised to send messages from the Remote QMgr, then that would end up in DLQ with DeadLetterHeader MQRC_NOT_Authorized.
Hope this helps in your analysis. I will let you know if I can think about any other possible reasons. |
|
| Back to top |
|
|
| steinra |
| Posted: Fri May 24, 2002 10:37 am Post subject: |
|
|
Apprentice
Joined: 23 May 2002
Posts: 28
Location: USA
|
Thanks for the reply.
I had someone pull the DLQ today from the AS/400. It turns out it is a security issue. I am getting a 2035 Not Authorized.
Now what I am wondering is if anyone knows whether the MQ subsystem on a 400 runs under a specific ID or it runs using mqm as the user id.
The message on the dead letter queue is by user MQM, but from reading other posts on this issue, that most likely is not the user id that the queue manager is using when the report message is placed on the queue.
Going to dig a little further.
Thanks again!
Randy |
|
| Back to top |
|
|
| mqonnet |
| Posted: Fri May 24, 2002 10:44 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Check out the following thread with a detailed explaination of why you are getting 2035.
http://www.mqseries.net/phpBB/viewtopic.php?topic=2680&forum=5&1
Cheers.
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| steinra |
| Posted: Fri May 24, 2002 1:18 pm Post subject: |
|
|
Apprentice
Joined: 23 May 2002
Posts: 28
Location: USA
|
I was able to get the reports flowing correctly by setting the userid in the MQ header to an ID that was on both systems. If I used an ID that was on the AS/400 but not on the AIX system I would get a report from the remote queue manager but not one from the local queue manager (i.e. message expired on the transmit queue).
Once I set the ID to a user id that existed in both locations then everything started to flow correctly.
The most interesting thing I found was that when I tried the id that only existed on the AS/400, if the message expired on the transmit queue locally then the report message just disappered. It was not written to the local dead letter queue. In the error file for the queue manager it looks like it saw that it was a 2035 error and it said it was going to put it on the DLQ, but no message. I thought that was interesting. But everything is working now.
Thank you everyone for your help.
Randy |
|
| Back to top |
|
|
| muralidhar |
| Posted: Fri May 24, 2002 2:41 pm Post subject: |
|
|
Acolyte
Joined: 28 Feb 2002
Posts: 50
|
Hi Randy,
When you use an user id that does't exist on your local machice, then it can't put the expired report message even on the DLQ because even DLQ is also another normal queue and needs access rights to put the message. When message expires on the local transmit queue, QMgr generates a report message and tries to deliver it to reply to queue with the id you set in your application. Since that id doesn't rights to put the message on the reply to queue it returns 2035 error code and tries to divert the message to DLQ again with the user id you set in your application. Even this will fail because of security and message is lost for ever. In our case we had to create user id with limited set of user rights on reply to queue and DLQ.
Anyhow, it's good it is working as per your requirements.
cheers,
Murali |
|
| Back to top |
|
|
| mqonnet |
| Posted: Fri May 24, 2002 4:00 pm Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Randy,
You have to have a userid on both systems, else neither you being the app nor the QM would be able to put the messages onto a queue. As you mentioned, you created the same userid on both systems and it worked. Just wanted to mention here, that you need not have the same userid, but different ones. Only thing is whatever userid you are using, it should be defined as a principal and should be added to the mqm group.
Randy/Murali,
As far as i am aware you are not quite right on this one. DLQ, even though a regular queue, is not exactly one. Even though you dont have rights the expired messages would ALWAYS go to the DLQ in the event that the message was not put the destined queue. It is the QM that puts messages on a DLQ(in this scenario, others being the MCA). And any QM MUST ALWAYS be able to put messages onto the DLQ. Hence the perception that DLQ needs special authorities is wrong, at least in this scenario.
Hope this helps.
Cheers.
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| muralidhar |
| Posted: Fri May 24, 2002 4:25 pm Post subject: |
|
|
Acolyte
Joined: 28 Feb 2002
Posts: 50
|
Kumar,
You are right that user id doesn't need to have rights on DLQ to put the messages. Thanks for correcting my mistake.
But the user id need not be added to MQM group. If the user id has authority to connect and setid permission, the message still goes to DLQ. When using activeX control, I think we also need to assing inq permission on QM.
cheers,
Murali |
|
| Back to top |
|
|
| mqonnet |
| Posted: Fri May 24, 2002 6:21 pm Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Murali,
Messages going to DLQ has NOTHING whatsoever to DO with any user and any userid. They reach DLQ because either the QM or the MCA puts the messages there, irrespective of the userid and the groups. The userid that actually tried to put the message could even be outside the mqm group and still his/her message could land up in the DLQ.
Cheers.
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| steinra |
| Posted: Fri May 24, 2002 8:18 pm Post subject: |
|
|
Apprentice
Joined: 23 May 2002
Posts: 28
Location: USA
|
Kumar,
I agree 100%. Let me restate it so I am sure I am on the same page as you.
AIX
QMGR
FRDTAX01
Local queue
FRDTAX01.AS400.REPLY
CHANNEL
FRDTAX01.BRDTAS01 ---- >
BRFTAS01.FRDTAX01 < ----
XMITQ
FRDTAX01.BRDTAS01.XMITQ
RemoteQ
AS400.REQUEST XMITQ(FRDTAX01.BRDTAS01.XMITQ)
RQMNAME(BRDTAS01) RNAME(BRDTAS01.REQUEST)
DLQ
DEFAULT.DLQ
User IDs
mqm
qmqm
AS/400
QMGR
BRDTAS01
Local queue
BRDTAS01.REQUEST
User IDs
qmqm
mqadmin (id running the job that processes the queue)
Put program runs on AIX
puts a message with the userID in header set to mqadmin
puts to remoteq AS400.REQUEST
In the first case the channel is up and running. Message expires on AS/400. A report message is sent back to FRDTAX01.AS400.REPLY.
In the second case the channel is down. Message expires on the xmitq. A report message in this case should go to the DLQ, correct? Because of the permission error (mqadmin does not exist locally).
In my situation, the second case, the report message just disappears.
If I use ID mqm then in the first case the report goes to the AS/400 DLQ.
If I use ID qmqm then everything works the way it should. I get reports back from each point the message could expire.
Thank you for your input.
Randy |
|
| Back to top |
|
|
| mqonnet |
| Posted: Sat May 25, 2002 11:40 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Randy you are right in what you put forth.
"In the second case the channel is down. Message expires on the xmitq. A report message in this case should go to the DLQ, correct? Because of the permission error (mqadmin does not exist locally).
In my situation, the second case, the report message just disappears.
"
Well, if your message expires on AIX xmitq, the expiry report, if requested must go to the Default DLQ. Default DLQ, though must be added to the QMGR attributes. Check to see if your dis qmgr displays the default deadq as the one you are expecting it to be. And you said that there is no expiry report generated or even if it is, the expired report disappears. Did you check the mqerrlogs to see what has been logged to it. Are you using only EXPIRATION REPORTS or also COA/COD. As for the userid. It has no bearing at all, at least in this context. Irrespective of which userid you use, if the messages are expired, they will land up in the default DLQ(if defined properly). I would check the error logs. Also would do a dis ql(*) curdepth before and after this experiement to see if the message made it to some other queue(accidently, can work on this later).
Hope this helps.
Cheers.
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
|
|
