| Author |
Message
|
| gpklos |
 Posted: Tue Mar 21, 2006 7:50 pm Post subject: Will Keep alive on ZOS help this problem? |
 |
|
Centurion
Joined: 24 May 2002
Posts: 108
|
We have a client application running on Windows which connects to a zos queue manager to get messages off a queue. This program does a get with wait and when it gets messages it goes off to update sql. After so much time the get/wait ends and the subroutine ends. All of the MQ code looks pretty good. What is happening is when you get info on the queue it shows numerous OPEN INPUTS. At the time of the open inputs there is at most one physical connection from the client. If I look at the channel status there are many ServerConns active, even with only one physical connection. The program does show some 2009 errors. Now the mainframe is currently set up with MQ TCPKEEP = NO, and tcpip on the mainframe has no KEEPALIVE set. I was thinking since there is no keep alive and the client does a get/wait and does sql updates, is it possible the channel is ending quickly without the keep alive, and when the program comes back from the sql update the connection is gone, and the mainframe is left to think the queue is still open for input.
Will putting a keep alive value on the Serverconn channel on the mainframe help this situation out?
Or am I way off with my line of thinking?
Thanks,
Gary |
|
| Back to top |
|
 |
| WBI_user |
| Posted: Tue Mar 21, 2006 8:34 pm Post subject: |
|
|
Partisan
Joined: 07 Aug 2001
Posts: 386
|
The number of "open for input count" is the number of times the MQOPEN call is issued to the queue for Input. Please conform the logic of your MQ client application. Is it like
1. MQCONN - connect to ZOS Qmgr
2. MQOPEN - open the queue for Input
3. MQGET with wait to wait for message
4. Start some sql processing after it received the message
5. End SQL processing
6. MQGET with wait again for the next message
:
7. MQCLOSE the queue
8. MQDISC - disconnect from the Qmgr.
If that is the case and everything is running fien, then there should be only one MQOPEN for INPUT count.
If there is more, there must be some error recovery going on.
YOu said there are 2009 errors (connection broken). Please check the retry logic for RC2009. This needs recnnect and reopen of the Queues. If this recovery happen without a previous closing of the queue, the open for Input count will increase. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Mar 22, 2006 4:07 am Post subject: Re: Will Keep alive on ZOS help this problem? |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| gpklos wrote: |
| If I look at the channel status there are many ServerConns active, even with only one physical connection. |
Consider each Active SVRCONN and separate physical connection.
If the client has a connection to the QM and the q, and the connection is severed, the QM is not going to just kill the channel on you. It will keep it open. The QM looks and waits for MQ calls. Just cause you haven't sent one in the last second or last week doesn't mean you are thru and won't send another QM call in the next second. This is EXACTLY what KeepAlive is suited for. It will check those TCP connections every KeepAliveInterval, and if it sees the other side, the client side, no longer has a valid socket, it will kill it and the orphaned SRVCONN will be cleaned up.
Read up on Heartbeats for the SRVCONN channels as well. HBs will come into play during the MQGET with wait. I think the z/OS QM has to be at version 6.0 to take advantage of that.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| gpklos |
| Posted: Wed Mar 22, 2006 5:21 am Post subject: RE: Will Keep alive on ZOS help this problem? |
|
|
Centurion
Joined: 24 May 2002
Posts: 108
|
Thanks for the responses. Like I said as far as I know the logic being used is similar to the logic
1. MQCONN - connect to ZOS Qmgr
2. MQOPEN - open the queue for Input
3. MQGET with wait to wait for message
4. Start some sql processing after it received the message
5. End SQL processing
6. MQGET with wait again for the next message
:
7. MQCLOSE the queue
8. MQDISC - disconnect from the Qmgr.
I'm not sure what you meant by recovery logic. Did you mean application program recovery logic to deal with the 2009, or some other MQ recovery. My thought is that the queue is open, then they get the 2009, now they reconnect and reopen the queue, so now there are 2 open inputs. If this keeps happening then the count will go up.
Now from what Peter was saying, it sounds as though the Keepalive interval will help me some? Correct Peter?
Thanks for all of your help guys,
It is much appreciated,
Gary |
|
| Back to top |
|
|
| javagate |
| Posted: Wed Mar 22, 2006 5:41 am Post subject: |
|
|
Disciple
Joined: 15 Nov 2004
Posts: 159
|
btw...
What ver of MQ are you using on z/OS?
What is ADOPTMCA=, ADOPTCHK= SET to?
We had a lot of connection problems then made these changes and they went away.
TCPKEEP=YES
ADOPTMCA=YES
ADOPTCHK=ALL
_________________
WebSphere Application Server 7.0 z/OS &
MQ 6.0. I work with WebSphere in the real world not in some IBM lab. |
|
| Back to top |
|
|
| WBI_user |
| Posted: Wed Mar 22, 2006 6:21 am Post subject: |
|
|
Partisan
Joined: 07 Aug 2001
Posts: 386
|
I mean recovery in general. I have seen miss behave program simply retry without doing closing or disconnect. The fact that you have many active connection indicates that MQCONNs were issued (assume that you have only one client). A client application is not like the server application. If the server application died, MQ will do the clean up. In a client situation, MQ does not know that the client has gone because they are not on the same box and hence these orphan connections are left behind. In some situation where the connection is broken, the application has no choice but to reconnect, then we have to rely on keepalive and Adopt MCA to help to do the cleanup. But if you have one of those miss behave application that blindly reconnect when there is RC that it cannot handle, then what you are doing at the system admin level is just to hide the problem.
You should investigate both the application and the set up of your MQ configurations as suggested in the other replies. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Mar 22, 2006 4:52 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The Adopt* settings are good to have for other reasons, but do not apply to SVRCONN channels.
gpklos,
Yes KeepAlive will help you if the problem is orphaned SVRCONN channels. We set KeepAlive to 15 minutes and it works as designed. If your version of MQ on z/OS is current enough, then also use Heartbeats on the SVRCONN / CLNTCONN channels. They only flow during an MQGET with Wait for MQ CLients, but typically it is correct to set HB much lower than Keep Alive. We use 30 seconds.
Keep Alive will clean up orphaned connections at x minutes, unless the connection orphaned during a Get With Wait, in which case HB will jump in and save the day sooner.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| gpklos |
| Posted: Thu Mar 23, 2006 8:59 am Post subject: Will Keep alive on ZOS help this problem? |
|
|
Centurion
Joined: 24 May 2002
Posts: 108
|
Again thanks to all your responses. I'm going to implement some form of keep alive on ZOS at this point. I have to turn on TCPIP KEEPALIVE, which is currently set to 0 (not sure why). I guess I could use one more clarification. Since the keepalive actually sends a packet to a socket to see if it is there, that also keeps the socket active longer because even a keep alive packet would still be considered activity on a connection? Correct?
Gary |
|
| Back to top |
|
|
|
|
