Re: Questions about Shared Queues - Help!!!

2003-06-20 Thread Richard Santilli
Tom,

We've implemented shared queues last November into Production.  It sounds
like you will have to eliminate the application that has the affinity to
run in one specific region.  We ran across the same problem.  We converted
our files to RLS and made them available across three LPARS each one
running a queue manager that belongs to our production QSG.  We also
implemented CPSM for CICS.  CPSM routes the MQ transactions which are
triggering a CICS program.

What queue's do you have in the CF?  Do you have the INIT and DATA queues
in the CF?  Also, are you using shared channels between your distributed
queue managers and your QSG on the mainframe?

In order for your environment to work each LPAR should have an exact clone
of CICS regions needed to process your MQ work.

If you have more questions you can contact me directly.

[EMAIL PROTECTED]
440.395.0698

I hope this helps.

Rich Santilli
MQ Solutions Expert
Progressive Insurance




  Thomas Lane
  [EMAIL PROTECTED] To:  [EMAIL PROTECTED]
  COM cc:
  Sent by: Subject: Questions about Shared Queues 
- Help!!!
  MQSeries List
  [EMAIL PROTECTED]
  en.AC.AT


  06/20/2003 07:31
  AM
  Please respond
  to MQSeries List






I would appreciate any ideas about this issue we are having with Shared
queues:

Let me first setup the question and later I will explain the reason we have
a requirement that apparently cannot be support by MQ Series.

We have implemented shared queues across two Mainframe Queue Managers.
Lets call them P3 and P7.  Our configuration is primarily a Unix based
middleware communicating to the Mainframe based two queue managers(P3 and
P7).  On the Mainframe we have two regions(mostly duplicated applications,
except one application that has region affinity(can only process in one
region).  Also, our mainframe regions are limited to reading from one queue
manager(I was told this is an IBM limitation).  Because of this, the
mainframe region that  has the application that must process in that region
only, can only read from one queue manager thus the readers are only
running on the one queue managerlets say the P3 queue manager.

Now here comes the issue.  Our Unix middleware handles request messages
coming from the front end.  The middleware also detects whether the
mainframe queue readers are up and running by inquiring for open input
count(handles) on a queue.  If our Unix Middleware connects to the same
queue manager that the P3(region affinity) application connects to it works
fine.  Because the readers are local to the queue manager in question.
However, we have two queue managers that Unix middleware uses.  When the
Unix middleware inquires for open input count for the shared queue and the
queue manager is P7(meaning not the queue manager where the MF readers are
running for the shared queue) it gets an open input count(mainframe
readers) of 0.  Thus the Unix middleware cannot determine if there is some
process in the mainframe to read the queues.  In this case we will not send
messages because we don't want the messages to stale out.

The way our infrastructure is set up it it(will) be extremely undesirable
and counter-productive to have a  single point of failure(just one queue
manager).

Does anyone have any suggestions on how we can get past this issue while
still having two queue managers?  If so, I would greatly appreciate it!

Thanks in advance,


 Thomas Lane
Senior Manager, Unix Development - Middleware
Pershing Technology Group
East Brunswick, NJ
Phone: 732-565-8289

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
 Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive


Unsubscribe

2003-06-18 Thread Richard Santilli
Richard Santilli

===
This email/fax message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information.  Any unauthorized
review, use, disclosure or distribution of this email/fax is prohibited.
If
you are not the intended recipient, please contact the sender by email/fax
and destroy all paper and electronic copies of the original message.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
 Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive