| Author |
Message
|
| Henry |
 Posted: Sun May 30, 2004 10:39 pm Post subject: MQ on OS390 |
 |
|
Acolyte
Joined: 08 Oct 2003
Posts: 73
|
Hi!
I have some questions on OS390 and looking for help.
Recently, the MQ ver is upgraded from old verion MQ 2.1 to the latest version 5.3.1 on OS390. There are a lot of things new. From the q status, there is a field calling Uncomitted Msg. When we put the msg onto a application queue, it will change the status from N to Y. This may be a normal under MQ. However, at the same time, I want to get a msg from the queue. It will prompt the error 2042. the queue is set to be sharing.
However, it was not happened in the old version. I can put or get the msg when the queue is in use. Can anyone give me some advice?
Thanks!! |
|
| Back to top |
|
 |
| offshore |
| Posted: Thu Jun 03, 2004 11:35 am Post subject: |
|
|
Master
Joined: 20 Jun 2002
Posts: 222
|
Henry,
Do you all have the CSQUTIL? When you do a display on the queue what is the following set at:
1.]Permit Shared Access
2.]Default Share Option
Currently we have our set to Exclusive & Shared. You could possibly set the Permit Shared Access to Shared instead of Exclusive. This may fix you problem...
If you don't have the CSQUTIL (or MA10 support pac) installed, then issue the DIS Q(q_name) ALL. It will display something similar to this:
) SHARE DEFSOPT(EXCL ) MSGDLVSQ(
SHARE - represents the Permit Shared Access and DEFSOPT represents the Default Share Option settings.
I think your bigger problem is why is the message uncommited?
Issue the DIS THD(*) TYPE(INDOUBT) to see what, if any UOW is hanging.
Also the DIS QSTATUS(q_name) TYPE(HANDLE) ALL will show what currently has the queue open for OUTPUT or INPUT. This may also aid you in troubleshooting. |
|
| Back to top |
|
|
| Henry |
| Posted: Thu Jun 03, 2004 5:25 pm Post subject: |
|
|
Acolyte
Joined: 08 Oct 2003
Posts: 73
|
Thanks for your reply!
The queue is set to be SHARE Access and by default it is also SHARE. Your method is tried to find out which process is hanging for the queue. However, I want to know why the programme is connected to the queue will be as a uncommited msg. It prevents other applications to put or get to/from the queue. In other words, it affects the concurrency.
I am not sure it is the new feature or problem. |
|
| Back to top |
|
|
| frankdk |
| Posted: Thu Jun 10, 2004 12:38 pm Post subject: |
|
|
Novice
Joined: 10 Jun 2004
Posts: 20
Location: Copenhagen, Denmark
|
Hi
You are definitely having a share conflict here. I MQ 5.3.1 for z/OS there is two types of share.
1. Q defined as QMGRDISP(SHARED)
2. the share options mentioned in above post.
You should check the share options first. I believe you would use the CSQOREXX interface to display the queue. If you press PF11 when displaying the queue you'll see the uncommitted message indicator. You should be able to put "1" in front of the q-name and get the appilcation info ie. jobname asid and the way they've opened the queue.
regards
Frank |
|
| Back to top |
|
|
| Henry |
| Posted: Thu Jun 10, 2004 6:32 pm Post subject: |
|
|
Acolyte
Joined: 08 Oct 2003
Posts: 73
|
How could I check the queue is defined as QMGRDISP(SHARE)?
I used the PF11 to check the queue status and which programme is connecting to the queue. At the same time, I can see the uncommitted msg count. however, the get programme can't get any msg from the queue. |
|
| Back to top |
|
|
| frankdk |
| Posted: Fri Jun 11, 2004 1:56 am Post subject: |
|
|
Novice
Joined: 10 Jun 2004
Posts: 20
Location: Copenhagen, Denmark
|
Hi Henry
The messages are not release for get until they are actually committed. Is the putting app. does a rollback the will be deleted and if MQ already had delivered to a getting app. it would be in trouble.
Either you need to do regular commits in your putting app. Or maybe you could put without a syncpoint (MQPMO_NO_SYNCPOINT) that should release the messages immediately - also if the putting app. abends.
_________________
Regards,
Frank |
|
| Back to top |
|
|
|
|
