Re: Cluster Base Q cannot be resolved (RC 2082)!
Hi Neil,
Excellent! Thanks for the pointer! Not to use the qmr
name in the Open is in the guidelines that have had
put together for the developers. But it never occurred
to me that they might be using qmgr name in the Open
in this particular case. Yes, the application is
probably using it, I was told. I cannot look at their
code. I have been told that Smalltalk binding
involves getting a Queue Manager connection, and
passing that connection to the Open operation.
Therefore QMAlias would not work (as they would have
to connect to this QMAlias first, as part of their
start-up proc in their ini file ).This will take
them some time to investigate as the developer of the
app is gone. I will post my findings/resolution.
Thanks again,
Ruzi
--- Neil Casey <[EMAIL PROTECTED]> wrote:
> Hi Ruzi,
>
> check to see that the application MQOD which is
> opened for output does not
> contain a queue manager name.
>
> If the application puts the local queue manager name
> (QM1 in your case)
> into this field, it stops cluster name resolution
> from working properly. Of
> course the 'q' program and amqsputc don't do this,
> so they will work.
>
> If your application forces a non-blank queue manager
> name (at my site we
> use Roma which enforces a non-blank QM name in MQOD
> on MQOPEN), then you
> can get around this by creating a dummy queue
> manager alias.
>
> That is, you:
> DEFINE QR(CLUSTER.QM) DESCR('Cluster QM Alias to map
> to blank QM name')
> (There are no other parameters required)
>
> on QM1. Your client app which specifies CLUSTER.QM
> as the QM name on the Q
> open will now resolve to a cluster queue as the QM
> name is mapped by the
> QMAlias to spaces.
>
> As an alternative to this, you can create the QR
> (CLUSTER.QM) as a cluster
> visible q on the QM(s) with the target queue. The
> resolution will then go
> via the alias, instead of resolving the queue name.
>
> Regards,
>
> Neil Casey.
>
>
> |-+>
> | | Ruzi R |
> | | <[EMAIL PROTECTED]|
> | | M> |
> | | Sent by: MQSeries|
> | | List |
> | | <[EMAIL PROTECTED]|
> | | n.AC.AT> |
> | ||
> | ||
> | | 25/02/2004 09:43 |
> | | Please respond to|
> | | MQSeries List|
> | ||
> |-+>
>
>
>----------------------|
> |
>
>|
> | To: [EMAIL PROTECTED]
>
>|
> | cc:
>
>|
> | Subject: Cluster Base Q cannot be
> resolved (RC 2082)!
>|
>
>
>--|
>
>
>
>
> Something mind boggling (to me at least We are on
> MQ
> server 5.3 CDS03 (unfortunately), on Windows2000.
> MQCLient 5.2 on Windosw2000.
>
> QM1 and and QM2 are in the same cluster. QM3 is
> outside the cluster and is connected to QM1.
>
> Scenario 1: Alias queue (not cluster) on QM1:
> QM1.ALIAS (base queue QM2.BASE).
> Local cluster queue on QM2: QM2.BASE
>
> Scenario 1: Remote queue (not cluster) on QM1:
> QM3.REMOTE ( with RName= QM3.LOCAL,
> RQMName= QM3)).
> Local queue on QM3: QM3.LOCAL
>
> We have a Smalltalk application running on
> developer s machine (with MQClient). The
> application
> has no problem putting a message to the remote
> queue
> QM3.REMOTE shown in the scenario 2 (i.e. the message
> gets across to QM3). Needles to say, the app can put
> a
> message to a local queue without any problems.
>
> However, when it tries to put a message to QM1.ALIAS
> it gets a RC 2082 (MQRC_UNKNOWN_ALIAS_BASE_Q). The
> developer can successfully put a message to
> QM1.ALIAS
> queue by using q.exe or amqsputc or a VB program
> successfully. This tells me that there is no problem
> with the cluster q name resolution. But, how come
> the
> Smalltalk app is trying to open this alias queue for
> Output the "cluster base Q" cannot be resolved.
> Anyone had this problem before? I was assured that
> the
> application is not opening it for Input (apart from
> opening it for output). Because if it did, it would
> have failed in scenario 1 too (as the remote queue
> cannot be opend for Inpu
Re: Cluster Base Q cannot be resolved (RC 2082)!
Hi Ruzi,
check to see that the application MQOD which is opened for output does not
contain a queue manager name.
If the application puts the local queue manager name (QM1 in your case)
into this field, it stops cluster name resolution from working properly. Of
course the 'q' program and amqsputc don't do this, so they will work.
If your application forces a non-blank queue manager name (at my site we
use Roma which enforces a non-blank QM name in MQOD on MQOPEN), then you
can get around this by creating a dummy queue manager alias.
That is, you:
DEFINE QR(CLUSTER.QM) DESCR('Cluster QM Alias to map to blank QM name')
(There are no other parameters required)
on QM1. Your client app which specifies CLUSTER.QM as the QM name on the Q
open will now resolve to a cluster queue as the QM name is mapped by the
QMAlias to spaces.
As an alternative to this, you can create the QR (CLUSTER.QM) as a cluster
visible q on the QM(s) with the target queue. The resolution will then go
via the alias, instead of resolving the queue name.
Regards,
Neil Casey.
|-+>
| | Ruzi R |
| | <[EMAIL PROTECTED]|
| | M> |
| | Sent by: MQSeries|
| | List |
| | <[EMAIL PROTECTED]|
| | n.AC.AT> |
| ||
| ||
| | 25/02/2004 09:43 |
| | Please respond to|
| | MQSeries List|
| ||
|-+>
>--|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Cluster Base Q cannot be resolved (RC 2082)!
|
>--|
Something mind boggling (to me at least We are on MQ
server 5.3 CDS03 (unfortunately), on Windows2000.
MQCLient 5.2 on Windosw2000.
QM1 and and QM2 are in the same cluster. QM3 is
outside the cluster and is connected to QM1.
Scenario 1: Alias queue (not cluster) on QM1:
QM1.ALIAS (base queue QM2.BASE).
Local cluster queue on QM2: QM2.BASE
Scenario 1: Remote queue (not cluster) on QM1:
QM3.REMOTE ( with RName= QM3.LOCAL,
RQMName= QM3)).
Local queue on QM3: QM3.LOCAL
We have a Smalltalk application running on
developer s machine (with MQClient). The application
has no problem putting a message to the remote queue
QM3.REMOTE shown in the scenario 2 (i.e. the message
gets across to QM3). Needles to say, the app can put a
message to a local queue without any problems.
However, when it tries to put a message to QM1.ALIAS
it gets a RC 2082 (MQRC_UNKNOWN_ALIAS_BASE_Q). The
developer can successfully put a message to QM1.ALIAS
queue by using q.exe or amqsputc or a VB program
successfully. This tells me that there is no problem
with the cluster q name resolution. But, how come the
Smalltalk app is trying to open this alias queue for
Output the "cluster base Q" cannot be resolved.
Anyone had this problem before? I was assured that the
application is not opening it for Input (apart from
opening it for output). Because if it did, it would
have failed in scenario 1 too (as the remote queue
cannot be opend for Input).
So to summarize: how come an app can put a message to
remote and local queues successfully but NOT to an
alias queue whose base Q is defined as cluster? Other
apps have no problem with this same alias queue
though.
Any suggestions would be much appreciated.
Ruzi
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
Cluster Base Q cannot be resolved (RC 2082)!
Something mind boggling (to me at least We are on MQ server 5.3 CDS03 (unfortunately), on Windows2000. MQCLient 5.2 on Windosw2000. QM1 and and QM2 are in the same cluster. QM3 is outside the cluster and is connected to QM1. Scenario 1: Alias queue (not cluster) on QM1: QM1.ALIAS (base queue QM2.BASE). Local cluster queue on QM2: QM2.BASE Scenario 1: Remote queue (not cluster) on QM1: QM3.REMOTE ( with RName= QM3.LOCAL, RQMName= QM3)). Local queue on QM3: QM3.LOCAL We have a Smalltalk application running on developer s machine (with MQClient). The application has no problem putting a message to the remote queue QM3.REMOTE shown in the scenario 2 (i.e. the message gets across to QM3). Needles to say, the app can put a message to a local queue without any problems. However, when it tries to put a message to QM1.ALIAS it gets a RC 2082 (MQRC_UNKNOWN_ALIAS_BASE_Q). The developer can successfully put a message to QM1.ALIAS queue by using q.exe or amqsputc or a VB program successfully. This tells me that there is no problem with the cluster q name resolution. But, how come the Smalltalk app is trying to open this alias queue for Output the "cluster base Q" cannot be resolved. Anyone had this problem before? I was assured that the application is not opening it for Input (apart from opening it for output). Because if it did, it would have failed in scenario 1 too (as the remote queue cannot be opend for Input). So to summarize: how come an app can put a message to remote and local queues successfully but NOT to an alias queue whose base Q is defined as cluster? Other apps have no problem with this same alias queue though. Any suggestions would be much appreciated. Ruzi 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
