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 » client connections to the mainframe

Post new topic  Reply to topic
 client connections to the mainframe « View previous topic :: View next topic » 
Author Message
KathyB
PostPosted: Wed Feb 18, 2009 6:37 am    Post subject: client connections to the mainframe Reply with quote

Apprentice

Joined: 02 Feb 2004
Posts: 30

Anyone with experience dealing with client connections to the mainframe?

I am running into a problem where the channel limit is being exceeded. It appears that the clients are not disconnecting once connected.

Is increasing the channel limit the right answer or should the client apps be disconnecting? The easy thing to do is to just increase the limit but I do not want the number to grow with no limits.

Anyone have any thoughts or experience with this?
Back to top
View user's profile Send private message
Vitor
PostPosted: Wed Feb 18, 2009 6:42 am    Post subject: Re: client connections to the mainframe Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

KathyB wrote:
should the client apps be disconnecting?


Yes they should. Same as for a queue manager on a distributed platform.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
zpat
PostPosted: Wed Feb 18, 2009 7:08 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5866
Location: UK

Absolutely they must disconnect as many times as they connect.

Overly frequent connections/disconnections are a sign of a poor design.

However it is fine to keep a connection open for a long-time if the application is designed that way.

on MQ V6 you can set an inactive disconnect interval on the client channel definition on z/OS (server conn).

MQ V7 has more controls possible, on the number of connections allowed from a given IP address.

Keep the maxchannels fairly high (we had it at 2000 in test and 8000 in production) but a growing connection count is a sign of a problem.
Back to top
View user's profile Send private message
KathyB
PostPosted: Wed Feb 18, 2009 10:51 am    Post subject: Reply with quote

Apprentice

Joined: 02 Feb 2004
Posts: 30

Thanks for the good info.

I will look at both increasing the number of active channels, the disconnect interval, and keep an eye on connection growth. Thanks!

What do you use for your inactive disconnect interval?
Back to top
View user's profile Send private message
zpat
PostPosted: Wed Feb 18, 2009 11:52 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5866
Location: UK

I never had to set one, but I would suggest 60 minutes would be OK (it won't terminate applications in a MQGET WAIT because they are legitimate).

When setting maxchannels - bear in mind that they will use virtual storage in the CHIN address space (if they are used) so keep an eye on that to make sure that you can accomodate the maxchannel value (ideally test it with a deliberately badly written application that repeatedly connects).
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » Mainframe, CICS, TXSeries » client connections to the mainframe
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.