Re: MQClient Case Study

2002-10-27 Thread Michael F Murphy/AZ/US/MQSolutions
What you are doing should work, however, it is not bullet proof.  Having a client "fail over" to another server is fairly easy to do as long as your application knows how to recognize a failed connection and to attempt to reconnect.  You can use a client channel table to help do this automatically

Re: WMQI os390 2.1 - Memory Question?

2002-10-27 Thread Heus, M. - SPLXM
Joe, these jobs are in fact the Agent and Execution Groups. You can correlate these through the PID. Look at the SHRLIBRGNSIZE and SHRLIBMAXPAGES in the z/OS UNIX BPXPRMxx parmlib members. Increasing the shared region size to at least 3 (300MB) will allow all generic modules for these job

WMQI os390 2.1 - Memory Question?

2002-10-27 Thread JoE JK
Hi, I did noticed on our host, the were a few jobs related to the broker QMGRBRK1/2/3 etc, had utilized a very high memory. Is this normal for those jobs to behave like this? Any materials or documents that I can refer to regarding this jobs created by the broker during the execution time? Thanks

Re: MQClient Case Study

2002-10-27 Thread Miller, Dennis
I assume your dashed lines represent some sort of redundancy with failover as a goal. Failover is never simple or easy You can get one kind of failover by programming your clients to connect to the first available qmgr. It's a sort of half failover, half load balancing approach and