from:"Mike Davidson"

Re: Help on Candle Management Workstation

2004-11-30 Thread Mike Davidson

The CMS Location Broker tab is there for all of the connection information for the CMS: the IP address, the remote LU, etc.

Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]

W Samuel [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
11/30/2004 06:41 AM
Please respond to MQSeries List

To:[EMAIL PROTECTED]
cc:
Subject:Help on Candle Management Workstation
Hello everyone,

I've just installed Candle Management Workstation on
my Windows machine but am having trouble
configuring this. I've never used Candle before.

The initial screen prompts for a user-id and password.
Is this referring to the MQSeries user ?
There's a tab called CMS Location Broker, what do i
add here?

Anyone done this before?

Thanks,
Samuel

___
ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

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

The information contained in this communication (including any attachments
hereto) is confidential and is intended solely for the personal and
confidential use of the individual or entity to whom it is addressed. The
information may also constitute a legally privileged confidential
communication. If the reader of this message is not the intended recipient
or an agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this communication in error and
that any review, dissemination, copying, or unauthorized use of this
information, or the taking of any action in reliance on the contents of
this information is strictly prohibited. If you have received this
communication in error, please notify us immediately by e-mail, and delete
the original message. Thank you

Re: Candle Command Center for MQSeries on mainframe

2004-11-23 Thread Mike Davidson




Amen!

Mike Davidson
TSYS MQ Tech Support
IBM Certified System Administrator - WebSphere MQ V5.3
IBM Certified Solution Designer - WebSphere MQ V5.3
[EMAIL PROTECTED]







Taras Wolansky [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
11/23/2004 11:58 AM
Please respond to MQSeries List



To:[EMAIL PROTECTED]
cc:
Subject:Candle Command Center for MQSeries on mainframe
We need to change the server to which the Candle agent on the mainframe
reports. What with the absorption of Candle into IBM, as well as personnel
changes at our end, getting information on this has proven more difficult
than expected ...


**

Confidentiality Note: This message and any attachments
may contain legally privileged and/or confidential information.
Any unauthorized disclosure, use or dissemination of this e-mail
message or its contents, either in whole or in part, is prohibited.
If you are not the intended recipient of this e-mail message,
kindly notify the sender and then destroy it.

**

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






The information contained in this communication (including any attachments
hereto) is confidential and is intended solely for the personal and
confidential use of the individual or entity to whom it is addressed.  The
information may also constitute a legally privileged confidential
communication.  If the reader of this message is not the intended recipient
or an agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this communication in error and
that any review, dissemination, copying, or unauthorized use of this
information, or the taking of any action in reliance on the contents of
this information is strictly prohibited.  If you have received this
communication in error, please notify us immediately by e-mail, and delete
the original message.  Thank you

Re: Disappearing cluster queues

2004-09-22 Thread Mike Davidson




One important point that should be made concerning the decision to go with more than 2 Full Repositories is that - out of the box MQ will only publish and subscribe cluster object information to 2 Full Repositories. Any more than 2 will require manual intervention to update the extras of any changes/additions/deletions that are taking place within the cluster.

Mike Davidson
TSYS MQ Tech Support
IBM Certified System Administrator - WebSphere MQ V5.3
IBM Certified Solution Designer - WebSphere MQ V5.3
[EMAIL PROTECTED]








Potkay, Peter M (ISD, IT) [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
09/21/2004 04:12 PM
Please respond to MQSeries List



To:[EMAIL PROTECTED]
cc:
Subject:Re: Disappearing cluster queues
If all these QMs are in 1 cluster, then all you need is 2 Full Repositories,
with manual CLUSSNDRS defined between them. Those extra Full Repositories
are just that, extra. No need for them, unless you put FR #1 and FR #2 on
servers that are both down frequently, but why would you do that?



-Original Message-
From: Tony Boggis [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 21, 2004 3:15 PM
To: [EMAIL PROTECTED]
Subject: Re: Disappearing cluster queues


So in my cluster, I have 2 groups (each group is in a separate data
center) of 12 queue managers. Each group has 2 full repos's defined,
with channels defined across groups to ensure that the cluster works as
a whole.

If I understand correctly, does this mean that on Repos-A, I have to
define a CLUSSDR to Repos-B,C  D? Similarly on Repos-B, do I have to
define a CLUSSDR to Repos-A,C  D... and so on?

tonyB.

  Original Message 
 Subject: Re: Disappearing cluster queues
 From: Wyatt, T Rob [EMAIL PROTECTED]
 Date: Mon, September 20, 2004 6:49 pm
 To: [EMAIL PROTECTED]

 Tony,

 Information flows between repositories only on explicitly defined
channels. Do all four of your repositories have explicitly defined CLUSSDRS
to each other? When your queues go missing, do they go missing on the
partial repository only? If they are in the full repositories, are they in
*ALL* of them?

 If there is a problem in the distribution of repository information, the
repositories get out of synch. The partials will reflect whichever of the
full repositories they are talking to at the moment. So if the repositories
get out of synch, the partials may change from time to time as they talk to
different fulls.

 From the manual:

http://publibfp.boulder.ibm.com/epubs/html/csqzah06/csqzah060u.htm#HDRCSQ684
1
 The CLUSSDR definitions made on the full repository queue managers are
special. All the updates exchanged by the full repositories flow exclusively
on these channels. The administrator controls the network of full
repositories explicitly. The administrator must make the CLUSSDR definitions
on full repository queue managers manually and not leave them to be
auto-defined.

 So you should have explicitly defined CLUSSDR channels from each repos to
each other repos. You should not need to create explicit defs to the leaf
nodes if the repositories are fully in synch.

 Hope that helps,
 -- T.Rob


 -Original Message-
 From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Tony
 Boggis
 Sent: Monday, September 20, 2004 9:18 PM
 To: [EMAIL PROTECTED]
 Subject: Disappearing cluster queues


 Puzzling situation...

 Environment: Solaris, WMQ 5.3 CSD05.

 I have a cluster with about 24 queue managers each on it's own host. All
 are sharing one or more queues in the cluster, eaching being unique,
 giving 200+ queues.

 Periodically cluster queues disappear on some hosts, leaving me
 getting 2085 errors, even from amqsput. Manually refreshing the cluster
 (REFRESH CLUSTER) usually does the trick. Usually.

 All my CLUSSDR/CLUSRCVR channels are configured and none are
 Binding/Retrying, etc. I have 4 full-respository managers defined, all
 are up and running.

 This is not 60+ days or anything that would obviously point to cluster
 expiration.

 tonyB.

 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

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


This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return email and delete

Re: Disappearing cluster queues

2004-09-22 Thread Mike Davidson

I pulled it straight from the MQ conference this year. Ian Vanstone (from IBM Hursley) mentioned this in one of his session on Administering WMQ Qmgr Clusters.

I also found these 3 statements in the Cluster manual:

Every queue manager in a cluster must refer to one or other of the full repositories
in order to gather information about the cluster and so build up its own partial
repository. Choose either of the repositories, because as soon as a new queue
manager is added to the cluster it immediately learns about the other repository as
well. Information about changes to a queue manager is sent directly to two
repositories.

When a queue manager sends out information about itself or requests information
about another queue manager, the information or request is sent to two full
repositories.

Having selected the queue managers to hold full repositories, you need to decide
which queue managers should link to which full repository. The CLUSSDR channel
definition links a queue manager to a full repository from which it finds out about
the other full repositories in the cluster. From then on, the queue manager sends
messages to any two full repositories, but it always tries to use the one to which it
has a CLUSSDR channel definition first.

I hope this helps.

Mike Davidson
TSYS MQ Tech Support
IBM Certified System Administrator - WebSphere MQ V5.3
IBM Certified Solution Designer - WebSphere MQ V5.3
[EMAIL PROTECTED]

David C. Partridge [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
09/22/2004 10:50 AM
Please respond to MQSeries List

To:[EMAIL PROTECTED]
cc:
Subject:Re: Disappearing cluster queues
Mike,

You said:

out of the box MQ will only publish and subscribe cluster object
information to 2 Full Repositories

can you point to where this is documented please.

Thanks
Dave

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

Re: Disappearing cluster queues

2004-09-22 Thread Mike Davidson




T. Rob,

I failed to mention that important point. The Cluster manual addresses that issue, as well:

Because all cluster information is sent to two full repositories, there might be
situations in which you want to make a second CLUSSDR channel definition. You
might do this in a cluster that has a large number of full repositories, spread over
a wide area, to control which full repositories your information is sent to.

Thanks for the clarification. :-)

Mike Davidson
TSYS MQ Tech Support
IBM Certified System Administrator - WebSphere MQ V5.3
IBM Certified Solution Designer - WebSphere MQ V5.3
[EMAIL PROTECTED]








Wyatt, T Rob [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
09/22/2004 03:20 PM
Please respond to MQSeries List



To:[EMAIL PROTECTED]
cc:
Subject:Re: Disappearing cluster queues
Peter,

The full repositories publish to as many other full repositories as they have explicit CLUSSDR definitions for but a partial publishes to only two full repositories no matter how many you have. Once the full repository receives information from a partial, it then republishes to all the other full repositories.

So the assertion that the partials only publish to two fulls is correct. So is the notion that you can have more than two full repositories and they are all in synch - assuming you have properly defined CLUSSDR channels between all the repositories.

-- T.Rob
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Potkay, Peter M (ISD, IT)
Sent: Wednesday, September 22, 2004 2:27 PM
To: [EMAIL PROTECTED]
Subject: Re: Disappearing cluster queues

Hmmm, I think all these statements were written with the assumption that you followed IBM's recommendation that you use only 2 FRs. But I can certainly see why someone would think the info only goes to 2 FRs.

I think it would go to all FRs if you had more than 2 because IBM's manuals also state you can have more than 2 FRs, and so do the Conference sessions, and nowhere in them does it say if you have 3 or more FRs, that only 2 would have the info. If FR #3 didn't have all the info, then it wouldn't be a FR.

I think you when you define the manual CLUSSNDR to one of your FRs, that FR sends back info to the new QM telling it how to make Automatic CLUSSNDRs to itself, as well as info on how to make Automatic CLUSSNDRs to every other FR it know about, whether it is just FR #2, or FR #2, #3 and #4. But the assumption is that all the FR know about each other, and the only way that can happen is if there is some route between all of them via manual CLUSSNDRs, be it AnyToAny or a Ring connection.


Not 100% sure though

-Original Message-
From: Mike Davidson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 22, 2004 12:58 PM
To: [EMAIL PROTECTED]
Subject: Re: Disappearing cluster queues


I pulled it straight from the MQ conference this year. Ian Vanstone (from IBM Hursley) mentioned this in one of his session on Administering WMQ Qmgr Clusters. 

I also found these 3 statements in the Cluster manual: 

Every queue manager in a cluster must refer to one or other of the full repositories 
in order to gather information about the cluster and so build up its own partial 
repository. Choose either of the repositories, because as soon as a new queue 
manager is added to the cluster it immediately learns about the other repository as 
well. Information about changes to a queue manager is sent directly to two 
repositories.
 
When a queue manager sends out information about itself or requests information 
about another queue manager, the information or request is sent to two full 
repositories. 
 
Having selected the queue managers to hold full repositories, you need to decide 
which queue managers should link to which full repository. The CLUSSDR channel 
definition links a queue manager to a full repository from which it finds out about 
the other full repositories in the cluster. From then on, the queue manager sends 
messages to any two full repositories, but it always tries to use the one to which it 
has a CLUSSDR channel definition first. 

I hope this helps. 

Mike Davidson
TSYS MQ Tech Support
IBM Certified System Administrator - WebSphere MQ V5.3
IBM Certified Solution Designer - WebSphere MQ V5.3
[EMAIL PROTECTED]







David C. Partridge [EMAIL PROTECTED] 
Sent by: MQSeries List [EMAIL PROTECTED] 
09/22/2004 10:50 AM 
Please respond to MQSeries List 


To:[EMAIL PROTECTED] 
cc: 
Subject:Re: Disappearing cluster queues

Mike,

You said:

out of the box MQ will only publish and subscribe cluster object
information to 2 Full Repositories

can you point to where this is documented please.

Thanks
Dave

Instructions for managing your mailing list subscription are provided in
the Listserv

Re: MMC/Any GUI for administering MQ on AIX

2004-09-09 Thread Mike Davidson

MO71 is a great tool for administering MQ. Here's the URL:

http://www-1.ibm.com/support/docview.wss?rs=203uid=swg24000142loc=en_UScs=utf-8lang=en

Mike Davidson
TSYS MQ Tech Support
IBM Certified System Administrator - WebSphere MQ V5.3
IBM Certified Solution Designer - WebSphere MQ V5.3
[EMAIL PROTECTED]

Jitender Bhatia [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
09/09/2004 08:27 AM
Please respond to MQSeries List

To:[EMAIL PROTECTED]
cc:
Subject:MMC/Any GUI for administering MQ on AIX
Hello,

I am relatively new to MQ.

I have MQ Series setup on AIX box.
Now, i want a way to administer it from my windows box by using some kind of GUI.

I have MMC on my windows box that i am able to use to administer MQ Series on my local desktop.
Can i use it to connect to MQ Series on AIX box to administer it. How ? I am not able to figure this out.

Any other ideas on what kind of UI i can use for this purpose ? A Java UI running on AIX is ok too.

Thanks

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

Re: Moving the list server?

2004-07-26 Thread Mike Davidson

I agree with James.

Mike Davidson
TSYS MQ Tech Support
IBM Certified System Administrator - WebSphere MQ V5.3
IBM Certified Solution Designer - WebSphere MQ V5.3
[EMAIL PROTECTED]

James Simms [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
07/26/2004 02:56 PM
Please respond to MQSeries List

To:[EMAIL PROTECTED]
cc:
Subject:Re: Moving the list server?
I am concerned that this will come down to a vote of a minority -- that being the case, I vote DO NOT MOVE. This ia a reliable and convenient listserver with a recent glitch that is transient and correctable with a few Delete keystrokes.
Jim
Ruzi R wrote:
I personally don't think that the move is justified at this moment... Regards, Ruzi
Kinnaird, John [EMAIL PROTECTED] wrote:
Just my 2 cents worth, I don't think I've seen anything that would justify a move, just a few annoyances, and this listserv seems to otherwise work pretty well. It didn't take me too long to hit my delete key a few times during the recent disturbance.
However, when there is a problem, it is not good if there are only two people who can moderate the discussion and one is no longer around and the other is temporarily unreachable. It's a lot to ask, but maybe there are a few who have the time and interest to become moderators. If that responsibility is shared, then there is more of a chance of someone being available to handle problems and it wouldn't be big burden on any one person. You would need something like that anyway even if you moved the list somewhere else wouldn't you?
John Kinnaird
Manager, National Operating Center
Tree of Life

MQ HFS information

2004-07-22 Thread Mike Davidson




(We're running MQ v5.3 on z/OS 1.4) 
I don't expect alot of responses on this one b/c nobody seems to know anything about this stuff, but here it goes:

I'm looking for any information/documentation I can find on the data, directories, and files contained within the MQ HFS structure under USS.

Thanks in advance.

Mike Davidson
TSYS MQ Tech Support
IBM Certified System Administrator - WebSphere MQ V5.3
IBM Certified Solution Designer - WebSphere MQ V5.3
[EMAIL PROTECTED]





The information contained in this communication (including any attachments
hereto) is confidential and is intended solely for the personal and
confidential use of the individual or entity to whom it is addressed.  The
information may also constitute a legally privileged confidential
communication.  If the reader of this message is not the intended recipient
or an agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this communication in error and
that any review, dissemination, copying, or unauthorized use of this
information, or the taking of any action in reliance on the contents of
this information is strictly prohibited.  If you have received this
communication in error, please notify us immediately by e-mail, and delete
the original message.  Thank you

MQINQ in a clustered environment

2004-05-14 Thread Mike Davidson




Setup:
- QMGR1 resides on LPAR1
- QMGR2 resides on LPAR2
- QMGR1 and QMGR2 are in cluster CLUS1
- Q1 is a clustered queue that exists on both QMGR1 and QMGR2

Scenario:
We have a CICS application (connected to QMGR1) and it needs to do an MQINQ on Q1 on QMGR2. Is this possible?

I have my doubts b/c of the fact that Q1 also exists locally on QMGR1 and I know the nature of MQ clustering causes the local instance of Q1 to have priority. (As mentioned on page 57 of the MQ Clusters manual.)

Thanks in advance.

Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]



The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed.  The information may also constitute a legally privileged confidential communication.  If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited.  If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.  Thank you

Re: Removing a dead server from an MQ cluster

2004-04-30 Thread Mike Davidson




Just remember (from the Clusters manual):

You can issue the RESET CLUSTER command only from full repository queue managers.

Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]







[EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
04/29/2004 10:32 PM
Please respond to MQSeries List



To:[EMAIL PROTECTED]
cc:
Subject:Removing a dead server from an MQ cluster
Howdy all,

I have a server (MQ2) that has been disconnected (forceably) from a cluster
and physically removed and will not be replaced. The existing queue manager
(MQ1) on the other server still thinks it is present. Can I issue a reset
cluster command on MQ1 as shown below safely:


Reset cluster('MQCLUSTER') QMNAME('MQ2') ACTION(FORCEREMOVE) QUEUES(YES)


Thanks

Sid

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





The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed.  The information may also constitute a legally privileged confidential communication.  If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited.  If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.  Thank you

Re: MQ and SSL on z/OS - RESOLVED

2004-03-31 Thread Mike Davidson

The problem ended up being that ICSF was not available on the Lpar we were testing (go Info. Sec.) - this appears to have caused the CHIN to go hunting for these directories in USS to resolve the keyring. Naturally, the CHIN didn't have the proper security rules in place for these non-existent dirs, hence the ACCESS DENIED error messages.

Thanks for all that responded...I mean...read my question. ;-)

Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]

Mike Davidson [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
03/29/2004 03:10 PM
Please respond to MQSeries List

To:[EMAIL PROTECTED]
cc:
Subject:MQ and SSL on z/OS

We are testing SSL with MQ v5.3 (put-level 0309) on z/OS 1.4 and the CHIN is spitting out some ACF2 security violations on a couple of USS directories that he appears to be trying to access (see error messages below):

CAS2312E CSQ2CHIN - ALTER ACCESS DENIED
/csq2chin$rdb
CAS2312E CSQ2CHIN - ALTER ACCESS DENIED
/TEMPRACF$csq2chin$1$694308864$0$0

The dirs mentioned don't even currently exist - Does anyone know where they're supposed to be?...where they need to be created? I checked the manuals (and Morag's document) and find no mention of any such dirs.
I've opened a PMR with IBM and haven't gotten alot of insight so far.

Thanks in advance!

Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]

The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you

MQ and SSL on z/OS

2004-03-29 Thread Mike Davidson




We are testing SSL with MQ v5.3 (put-level 0309) on z/OS 1.4 and the CHIN is spitting out some ACF2 security violations on a couple of USS directories that he appears to be trying to access (see error messages below):

CAS2312E CSQ2CHIN - ALTER  ACCESS DENIED
/csq2chin$rdb
CAS2312E CSQ2CHIN - ALTER  ACCESS DENIED 
/TEMPRACF$csq2chin$1$694308864$0$0

The dirs mentioned don't even currently exist - Does anyone know where they're supposed to be?...where they need to be created? I checked the manuals (and Morag's document) and find no mention of any such dirs.
I've opened a PMR with IBM and haven't gotten alot of insight so far.

Thanks in advance!

Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]



The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed.  The information may also constitute a legally privileged confidential communication.  If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited.  If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.  Thank you

Re: TCP/IP errors

2004-03-23 Thread Mike Davidson

Sounds like they're not hitting the right box, hence the message stating : EXRC_MQNODE_UNREACHABLE: Local Manager running on the MQSeries Node is either not running or not responding.

The firewall rules would appear to be the culprit, pointing them to a different box where there is no active qmgr.

Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]

Bharath Ram Srinivasan [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
03/23/2004 06:05 AM
Please respond to MQSeries List

To:[EMAIL PROTECTED]
cc:
Subject:Re: TCP/IP errors

Ray,

We use the default 1414 port.

We were getting the following error message when we tried accessing the
listen queue through MMF.(Nastel MQControl Explorer)

EXRC_MQNODE_UNREACHABLE: Local Manager running on the MQSeries Node is
either not running or not responding. It may also indicate a problem with
TCP/IP connectivity to the node. Corrective Action: Verify that Local
Manager is running on the target MQSeries Node. Also make sure that the
port number of the Local Manager corresponds to the Port number reported by
the Group Manager.

Following which we verified the state of our Queue Mgr. It was Active. On
confirming with our client that he was sending to the desired port, we
asked him to Ping his sender channel, which reported a TCP/IP error or the
Listener being down. But the listener was up. That's how we arrived at the
conclusion that this could be a TCP/IP error.

As for the firewall check, the client is able to ping my machine (ordinary
Ping on the CMD prompt) from his end.

Having said that, could you please help me out on how to proceed further?

Best Regards,

Bharath

Ray Tomblin
[EMAIL PROTECTED] To: [EMAIL PROTECTED]
OM cc: (bcc: bharathram.s/Polaris)
Sent by: Subject: Re: TCP/IP errors
MQSeries List
[EMAIL PROTECTED]
en.AC.AT

03/23/04 03:50
PM
Please respond
to MQSeries List

If everything is set up correctly, I would have someone put a scope on the
line
and see what happens to the message. A bad firewall rule, a misconfigured
router/switch, are a couple of
of reasons that can cause this error. Are you using the default port or
did you assign a particular port? Is
the client sending to the correct port?

Bharath Ram Srinivasan
[EMAIL PROTECTED]To:
Sent by: MQSeries List [EMAIL PROTECTED]
[EMAIL PROTECTED] cc:
Subject:
TCP/IP errors
03/23/2004 04:52 AM

Please respond to MQSeries List

Hi,

We have an issue with one of our NT Boxes. We are running WMQ 5.3 in this
machine. Our Client is trying to connect to this machine through his sender
channel. Although the listener and queue mgrs at my end are up running,
the msg doesn't reach me. The MQ error log at sender end suggests that this
might be a TCP/IP error or the listener must be down. But I am pretty sure
that the listeners are up. How do I resolve this TCP/IP error?

Alternately, if I decide to give up this Port (assuming it had some
trouble) and allocate a new port for communication how could I make sure
that this port would work before making the MQ connectivity change.

Please help me out with this.

Best Regards,

Bharath

The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have

Re: test tool allowing us to specify a msg id

2004-03-01 Thread Mike Davidson




You can't specify your own MsgID with the q program, but you can zero out MsgId before MQPUT with the -z parameter.

Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]







Adiraju, Rao [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
02/29/2004 03:28 PM
Please respond to MQSeries List


To:[EMAIL PROTECTED]
cc:
Subject:Re: test tool allowing us to specify a msg id


There is a support pack - MA01 - that is available from IBM site. It has got a program/utility q with copies messages from one source to another. So you can input a file and messages will be written to Queue. I am not sure about specifiying your own message-id through. Give a go and see whether it's fit your bill. 

Cheers

Rao Adiraju 
WebSphere MQ Specialist 
The National Bank of NZ Ltd. 
Wellington - New Zealand 
Tel: +64-4-494 4299 
Fax: +64-4-802 8509 
Mbl: +64-211-216-116 



From: Kulbir S. Thind [mailto:[EMAIL PROTECTED] 
Sent: 29 February 2004 7:07 AM
To: [EMAIL PROTECTED]
Subject: test tool allowing us to specify a msg id


Hi, 

Quick question, is there a utility supplied by IBM that will allow us to send messages to a queue specifying our own Message Id and will also be able to handle new line characters? We need to be able to supply a file and message id as parameters and want the utility to take the contents of the file and format a message and use the message id and put the message on to the queue. This should run on Windows and Sun Solaris.  

Am I asking too much? The reason it has to be an IBM tool is that IBM have passed our Vendor audits. We could quite easily develop our own, problem would be that we then need unit specifications and unit test cases for this tool, just trying to find the easy way out I guess. 

Thanks in advance, 

Kulbir. This communication is confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails.
Thank you.




The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed.  The information may also constitute a legally privileged confidential communication.  If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited.  If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.  Thank you

Clustering question regarding communications (MQ 5.3 on z/OS 1.2)

2004-01-23 Thread Mike Davidson

I've come across an issue regarding the CONNAME that is made 'public' in the CLUSRCVR definition. As you all know, the value will be stored in the repositories and used by any qmgr's joining the cluster to create an auto-defined CLUSSDR channel as needed. We have internal (inside of our firewall) qmgrs in the cluster, as well as external (outside of our firewall) qmgrs in the cluster. Here's my concern:

The IP address specified in the CONNAME of the CLUSRCVR definition needs to serve:

qmgrs inside the firewall, who use an internal un'NAT'd address

AND

qmgrs outside of the firewall who need to use an external NAT'd address

In a nutshell, I have one place to specify 2 addresses.
I know using the DNS name would be a possible remedy, however, certain external clients are reluctant to use the DNS name - they require an actual IP address.
I'm assuming someone else has run into this scenario - clustering with qmgrs in the cluster that are internal and external...

Thanks in advance.

Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]

The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you

Re: URGENT HELP NEEDED: on cluster resolution

2003-12-10 Thread Mike Davidson


Have you tried issuing the RESET command before you bring up the new instance of the full repos.? This will forcibly remove the qmgr from the cluster. Then try to add him back into the cluster on the new box. You can even specify the QMID to ensure that the old one is being removed.

Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]







Ruzi R [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
12/10/2003 10:55 AM
Please respond to MQSeries List



To:[EMAIL PROTECTED]
cc:
Subject:Re: URGENT HELP NEEDED: on cluster resolution
I went ahead and:

1-Suspended the qmgr MQFULL1
2-Deleted the clussdr on MQFULL1 (TO.MQFULL2).
3-Recreated the clussdr on MQFULL1 (TO.MQFULL2)
4-Resumed qmgr
5-Refreshed cluster
6-Display clusqmgr(*) showed only the MQFULL1 qmgr
(neither the second full rep MQFULL2 or the rest of
the cluster members)

I hope someone can help me with this.

Thanks,

Ruzi

--- Ruzi R [EMAIL PROTECTED] wrote:
 Hi all,

 We are on MQ 5.3 CSD 05 ON W2K servers and OS/390 MQ
 5.3. Last night, we replaced the 2 full
 repositories
 (on W2K machineA and machineB) of our two MQ
 clusters with the new full repositories (on W2K also
 machine1 and machine2). I had followed the steps
 stated in the cluster book to the dot (I believe) on
 how to do this task. One of the clusters is working
 without any problems. We have been having problems
 with the other cluster since this switch over. I
 get
 RC 2189 (I know what this means) when I put a
 message
 across the cluster. MQ explorer cluster (namely
 MQ2T.CLUSTER) only shows the MQFULL1 repository.

 So the set up is:

 MQFULL1 on machine1 ---  full rep
 MQFULL2 on machine 2 ---  full rep

 MQ2T on OS/390- cluster member (not fill rep)
 MQ1 on w2k- cluster member (not full rep)


 1- MQCHIN job indicates that :  Unable to get
 message
 from
 SYSTEM.CLUSTER.COMMAND.QUEUE, MQCC=2
 MQRC=2016System.cluster.repository.queue on MQ2T
 2016 . Recycling qmgr did not help.
 2- When I DISPLAY CLUSQMGR(*) in MQFULL2 it displays
 all the cluster info correctly (i.e. MQFULL1,
 MQFULL2,
 MQ2T, MQ1). However the same command issued on
 MQFULL
 shows:

 DISPLAY CLUSQMGR(*)
   1 : DISPLAY CLUSQMGR(*)
 AMQ8441: Display Cluster Queue Manager details.
  CLUSQMGR(MQFULL1)
 CLUSTER(MQ2T.CLUSTER)
  CHANNEL(TO.MQFULL1)
 AMQ8441: Display Cluster Queue Manager details.
  CLUSQMGR(SYSTEM.TEMPQMGR.machine2(1414))
  CLUSTER(MQ2T.CLUSTER)
 CHANNEL(TO.MQFULL2)

 Looks like the full repositories are not connected
 to
 each other properly.
 SYSTEM.TEMPQMGR.machine2(1414))  is supposed to
 say
 MQFULL2 instead. How can I correct this? Why is
 it
 not showing the rest of the cluster members ? Should
 I
 delete the clussdr/clusrcvr chnnels on MQFULL1 to
 MQFULL2 and redefine them? How would it impact the
 rest of the cluster?

 I would very much appreciate your help with this
 problem.

 Best regards,

 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



The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed.  The information may also constitute a legally privileged confidential communication.  If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited.  If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.  Thank you

Re: CCSID...again

2003-11-26 Thread Mike Davidson

That's exactly what we had to do. The CCSID of 37 did, indeed, fix the issue. We've had no issues as a result.

Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]

Gina McCarthy [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
11/25/2003 01:17 PM
Please respond to gimccarthy

To:[EMAIL PROTECTED]
cc:
Subject:CCSID...again
Sorry if this is getting old...

I have messages coming from outside partners through a UNIX system to OS/390. They are sending an exclamation '!' and it is coming into the MF as X'4F'. Our CCSID on the OS/390 MQ system is 500 (default). We are seeing this as a '|'. Does it have to do with the CCSID of the MF which I believe is 037? For straight character conversion, should I change the CCSID to 037?? What are the implications of doing this?

TIA

Regards
Gina McCarthy

The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you

Re: Connection or remote listener unavailable error

2003-10-21 Thread Mike Davidson

That generic message ('Connection or remote listener unavailable') is usually accompanied by a more specific Communications Protocol return code. Can you provide us with some more information concerning this return code? Is it SNA or IP? I'm assuming that you have a listener running on your machine...

Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]

Prithwiraj Basu [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
10/21/2003 10:33 AM
Please respond to MQSeries List

To:[EMAIL PROTECTED]
cc:
Subject:Connection or remote listener unavailable error
Hi All,

We have an app that has a bidirectional MQ link with another company. We
have a Unix platform on our side. The other comany operates via a
mainframe. It was recently discovered that when we upgraded our Sun
Solaris OS we blew away the MQ objects. I have recreated them and got
things to work to the point where we can send messages to the other
company. However they are unable to send mesages to us. When they try to
start their sender channel they get a 'Connection or remote listener
unavailable'. Any ideas how I can troubleshoot this? Thanks.

Prits

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

The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you

Re: Process-Start Channels

2003-10-13 Thread Mike Davidson


TrigType
Trigger (Yes)
Initq
Trigdata = Channel Name

Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]







Williams, Dave (Systems Management) [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
10/13/2003 01:34 PM
Please respond to MQSeries List



To:[EMAIL PROTECTED]
cc:
Subject:Process-Start Channels

Hello.
We're running MQS 5.3 for OS/390. We received the impression, from a class, that it's no longer necessary to have process defined to start channels in XMIT queue definitions. What parameters have to be defined in XMIT queue for triggering then? 

   More
Queue name . . . . . . . . : MQxx   
Disposition . . . . . . . . : QMGR  MQxx 
  
Trigger Definition 
  
  Trigger type . . . . . . : F F=First,E=Every,D=Depth,N=None   
  Trigger set . . . . . . : N Y=Yes,N=No 
  
  Trigger message priority : 0 0 - 9   
  Trigger depth . . . . . : 1 1 - 9   
  
  Initiation queue . . . . : 
  Process name . . . . . . :  
  Trigger data . . . . . . :   

Thanks, 
DW


The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed.  The information may also constitute a legally privileged confidential communication.  If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited.  If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.  Thank you

Re: Linking two Q Mgrs one with TCP/IP and other with SNA

2003-10-12 Thread Mike Davidson

I found in testing MQ clustering between W2K and Mainframe qmgr's w/multiple communications protocols that IP channels across the board were the way to go. If you must use SNA channels, you'll need a Channel Auto-Definition Exit (CHADEXIT) on the W2K qmgr to pass the Userid and Password attributes for APPC authorization. I got it to work like this, but it was ugly - trying to mix protocols within the clustered environment. Since I've changed all of the clustered channels to pure TCP/IP, everything's been great! You can still keep your classic channels on the host as LU62 - just make all of your clustered channels are IP.

I hope this helps. Good luck!

Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]

Harkishin Thadani [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
10/12/2003 04:03 AM
Please respond to hrthadani

To:[EMAIL PROTECTED]
cc:
Subject:Linkimg two Q Mgrs one with TCP/IP and other with SNA
[EMAIL PROTECTED]?xml:namespace prefix = o ns = urn:schemas-microsoft-com:office:office /

Dear Friends,

We are trying to set up multiple MQ Queue Managers into two clusters. Cluster 1 is made up of Queue Managers on UNIX and Windows platforms communicating with each other using TCP/IP. Cluster 2 is made up of Queue Managers running under MVS using SNA as the communication driver.

We would like to link up the two clusters. If we had TCP/IP or SNA as a common communication protocol in all the hosts, we could have linked up the two clusters either having, say one or two Queue Managers common to both the clusters or would have connected two of the Queue Managers in the two clusters directly.

However with the two clusters having different communication drivers, it appears to be difficult. The solution does not seem to be in MQSeries which is just using the message drivers based on the underlying communication protocol. The solution would have to be at the transport layer. I do not have the knowledge to be able to resolve this.

Two possible solutions which come to mind are to use TCP62 which allows SNA commands to flow over TCP/IP. Second is to use communication boxes which can convert SNA requests and messages to TCP and vice versa. Can either of this resolve the problem? What are the products available in the market place to provide the solution, if any?

Thanks and regards,

Harkishin R. Thadani

E-mail : [EMAIL PROTECTED]
Phone/fax : 612/9181 2204
Mobile : 612/412 279 251

Do you Yahoo!?
The New Yahoo! Shopping - with improved product search

The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you

Re: Cluster question - (SYSTEM.CLUSTER.REPOSITORY.QUEUE)

2003-09-08 Thread Mike Davidson


Thanks for the explanation, John.

Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]







John M Hammond [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
09/08/2003 10:34 AM
Please respond to MQSeries List



To:[EMAIL PROTECTED]
cc:
Subject:Re: Cluster question - (SYSTEM.CLUSTER.REPOSITORY.QUEUE)
I'm not IBM but I used to be

The SYSTEM.CLUSTER.REPOSITORY.QUEUE queue contains everything MQ needs to
know in order to manage clusters successfully. There will always be at
least one message on it. The top 'RFQR' message contains information
relating to the local queue manager and is usually filled with blanks.
This message is always there, even when you are not using cluster objects.

Subsequent messages relate to specific cluster objects that exists within a
cluster. As you define new objects you'll see the depth of the queue
increase. Occasionally MQ will rewrite the entire queue and compact the
data and thus reduce the number of messages. You might have a couple of
hundred messages on the queue one, day and then 3 messages on it the next -
this is normal!

The formats of these messages are all internal and (I can say from
experience) are fairly complicated. I would not recommend anybody
attempting to decode them. I was also strongly discourage anybody from
tampering with the messages on this queue. I updated the queue manually
many times in testing support tools and the results were not pretty at the
best of times.

In short:
- Messages on the queue are normal
- Don't touch them :-)

John

John M Hammond
Data Center: Middleware
Household International
100 Mittel Drive
Wood Dale, IL 60191
Phone: (630) 521-4339;





 Wood, Dan
 [EMAIL PROTECTED] To:  [EMAIL PROTECTED]
 Sent by: MQSeries   cc:
 List  Subject: Re: Cluster question - (SYSTEM.CLUSTER.REPOSITORY.QUEUE)
 [EMAIL PROTECTED]
 .AT


 09/08/2003 08:58 AM
 Please respond to
 MQSeries List






Shows how far behind I am with my listserv messages.

DONT DELETE ANYTHING and DON'T ASK QUESTIONS!

I'm surprised IBM didn't respond to your question...

Dan L Wood
AIT - Enterprise Application Integration
[EMAIL PROTECTED]
319-896-6985


 -Original Message-
 From: Mike Davidson [SMTP:[EMAIL PROTECTED]
 Sent: Wednesday, August 06, 2003 7:17 AM
 To:  [EMAIL PROTECTED]
 Subject:   Re: Cluster question - (SYSTEM.CLUSTER.REPOSITORY.QUEUE)


 Neil,

 Thanks for the response.

 I agree with you that the SYSTEM.CLUSTER.REPOSITORY.QUEUE is not the
place
 to be poking around. I was just curious as to why initially this queue
has
 a couple of base messages in there. If this is normal, I'm cool with
it.

 Mike Davidson
 TSYS MQ Tech Support
 [EMAIL PROTECTED]




Neil Casey [EMAIL PROTECTED]
 Sent by: MQSeries List [EMAIL PROTECTED]

 08/05/2003 07:56 PM

 Please respond to MQSeries List


 To:[EMAIL PROTECTED]
 cc:
 Subject:Re: Cluster question -
 (SYSTEM.CLUSTER.REPOSITORY.QUEUE)

 Mike,

 you're a brave man. The SYSTEM.CLUSTER.REPOSITORY.QUEUE is where MQ saves
 away any information which relates to clusters. Some of it is easily
 rebuilt, and some of it is pretty critical, especially if your queue
 manager is a full repository. You should always expect to find messages
on
 this queue if anything relating to clusters has been defined.

 These messages are not something that I would be deleting personally
 (unless directed by IBM support - I have had that happen once at v2.1 on
 zOS).

 MQ5.3 now has substantially more ability to manage the cluster repository
 than earlier versions, with extensions to the cluster commands. I would
 never want to play with the repository directly. It's asking for trouble.

 I can't answer the question of what the specific messages represent. We
 had
 a similar discussion recently about transmission headers on channels, and
 got the answer from IBM that internal messages formats are internal (and
 private) for a reason. If the formats are known, someone will depend on
 them, and then when IBM change them to privide new function or to fix a
 problem, someone elses code breaks. This makes IBM look bad, even though
 the third party is at fault for relying on a non-documented interface.

 Regards,
 Neil Casey.


 |-+
 | |  Mike Davidson  |
 | |  [EMAIL PROTECTED]|
 | |  M|
 | |  Sent by: MQSeries|
 | |  List   |
 | |  [EMAIL PROTECTED]|
 | |  n.AC.AT |
 | |  |
 | |  |
 | |  06/08/2003 03:40 |
 | |  Please respond to|
 | |  MQSeries List  |
 | |  |
 |-+


-
 -|
 |
 |
 |To:[EMAIL PROTECTED]
 |
 |cc:
 |
 |Subject

Re: Urgent help: Unexpected behavior in the Cluster!!!

2003-08-25 Thread Mike Davidson


I found in my testing that using the RESET command got rid of the automatically-defined channels from the DIS CLUSCHL(*) command. I tried it after reading the Queue Manager Clusters manual and, believe it or not, it worked. Here's an excerpt (p. 68):

You might use the RESET CLUSTER command if, for example, a queue manager has been deleted but still has cluster-receiver channels defined to the cluster. Instead of waiting for WebSphere MQ to remove these definitions (which it does automatically) you can issue the RESET CLUSTER command to tidy up sooner. All other queue managers in the cluster are then informed that the queue manager is no longer available.

I hope this helps.

Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]







Potkay, Peter M (PLC, IT) [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
08/25/2003 08:55 AM
Please respond to MQSeries List



To:[EMAIL PROTECTED]
cc:
Subject:Re: Urgent help: Unexpected behavior in the Cluster!!!
I would bet that the mainframe queue manager still has some automatic
CLUSSNDRs leftover from when they were pointing to QM1 and QM2. just
stopping / deleting / or modifying the manually defined ones does not do
anything to the automatic ones.

They will even continue to retry even now, hoping that the listener on QM!/@
comes back.

I know of no graceful way of eliminating Automatic CLUSSNDRs. :-( My
biggest pet peeve with clustering. The only way I know how to do it is to
completely blow away the repositories in the cluster (partial and full).
Maybe someone knows a better way???


The one thing I have learned in the past couple of weeks with clustering is
never ever just delete something. You always have to un cluster it first
(queues, channels), and then delete.



-Original Message-
From: Ruzi R [mailto:[EMAIL PROTECTED]
Sent: Monday, August 25, 2003 8:39 AM
To: [EMAIL PROTECTED]
Subject: Urgent help: Unexpected behavior in the Cluster!!!


Hi all,

The QM1 and QM2 (on W2K, MQ 5.3) were full
repositories for our cluster. I have just replaced
them (full repositories) with QMA and QMB-- removing
QM1 and QM2 from the cluster. I have done this
following the instructions given in the MQ Cluster
manual. I have done the clean-up of the obsolete
channels etc. (e.g. TO.QM1 and TO.QM2). In other
words, no cluster member has any CLUSSDR channel
pointing to the old repositiories. The old
repositories have their cluster channels deleted.
Have done REFRESH CLUSTER REPOS(YES/NO) as per the
instructions in the manual.

As we don t need QM1 and MQ2 any longer, I did endmqm
on QM1 and QM2. Stopped the listener on both. Did some
testing; everything seemd OK in the cluster.

Then I had to move on to something else

MQ2T (on OS/390 MQ 5.3) is a member in the cluster. I
had modified the procs for MQ2T to pick up the new
connames (for QMA and QMB). As part of testing, my
colleague stopped MQ2T and re-started. Apparently, on
the re-start, the event logs on the old full
repositories got flooded with messages indicating MQ2T
was trying to connect to them (at least that is what
he says.. I haven t seen the errors myself. He cleaned
up the log and saved the data somewhere but I don t
know where yet). Why would this happen as there is
nothing in the start-up procc pointing to QM1 or MQ2?
I have to find an answer to this as we have another
cluster whose full repsoitories will have to be
replaced today. He said that, as soon as he stopped
the listener on these qmgrs the errors stopped. It
just so happens that we don t need QM1 and QM2 any
longer, so I will delete them. My question is,
suppose that QM1 and QM2 were to stay as independent
queue managers (not as a cluster member) with their
listeners running obviously, how would I prevent their
logs from getting filled with messages from cluster
queue managers trying to connect?

My thinking is, because the new full repositories
will keep the info related to the old repositories for
90 days  during which time, any member qmgr
re-starting will cause this kind of error???

I would very much appreciate your input on the above
unexpected behavior the cluster.

Thanks,

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


This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return email and delete this communication and destroy all copies.

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



The information contained

Re: Urgent help: Unexpected behavior in the Cluster!!!

2003-08-25 Thread Mike Davidson


Peter - Correct, I issued the RESET command on the qmgr's that were being removed from the cluster. I've never had a scenario where the qmgr's (in this case QM1 and QM2) were already deleted from the box altogether.

Ruzi - As strange as it sounds, try recreating QM1 and QM2 and just run the ALTER QMGR REPOS() command. Then run the RESET CLUSTER() QMNAME(QM1/QM2) ACTION(FORCEREMOVE) QUEUES(YES/NO) command. Then run ALTER QMGR REPOS(' '). Then see what DIS CLUSQMGR on the mainframe returns. And, finally, delete QM1 and QM2 if no longer needed.

(Essentially, you'd be introducing QM1 and QM2 back into the cluster as full repositories, running the RESET command to try and rid yourself of the auto-defined chl's, and backing the qmgr's out of the cluster.)

Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]
706.644.9501







Potkay, Peter M (PLC, IT) [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
08/25/2003 10:05 AM
Please respond to MQSeries List



To:[EMAIL PROTECTED]
cc:
Subject:Re: Urgent help: Unexpected behavior in the Cluster!!!
So you would issue this command from the QM where other QMS are still trying to send stuff to. In Ruzi's case, the old QM1 and QM2 queue managers, right? This would tell all other QMs in the cluster to delete any automatic CLUSSNDRs to QM1 or QM2?


What do you do in the case where perhaps QM1 and QM2 were already deleted? Is there any official way in this case? Perhaps issuing REFRESH CLUSTER REPOS(YES) on the QM that had the bad automatic CLUSSNDRs would flush them out? In Ruzi's case, the mainframe QM? (Sorry Ruzi, from your original post it was not clear if you issued this command on the mainframe or not).



-Original Message-
From: Mike Davidson [mailto:[EMAIL PROTECTED]
Sent: Monday, August 25, 2003 9:48 AM
To: [EMAIL PROTECTED]
Subject: Re: Urgent help: Unexpected behavior in the Cluster!!!


I found in my testing that using the RESET command got rid of the automatically-defined channels from the DIS CLUSCHL(*) command. I tried it after reading the Queue Manager Clusters manual and, believe it or not, it worked. Here's an excerpt (p. 68): 

You might use the RESET CLUSTER command if, for example, a queue manager has been deleted but still has cluster-receiver channels defined to the cluster. Instead of waiting for WebSphere MQ to remove these definitions (which it does automatically) you can issue the RESET CLUSTER command to tidy up sooner. All other queue managers in the cluster are then informed that the queue manager is no longer available.

I hope this helps. 

Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]






Potkay, Peter M (PLC, IT) [EMAIL PROTECTED] 
Sent by: MQSeries List [EMAIL PROTECTED] 
08/25/2003 08:55 AM 
Please respond to MQSeries List 


To:[EMAIL PROTECTED] 
cc: 
Subject:Re: Urgent help: Unexpected behavior in the Cluster!!!

I would bet that the mainframe queue manager still has some automatic
CLUSSNDRs leftover from when they were pointing to QM1 and QM2. just
stopping / deleting / or modifying the manually defined ones does not do
anything to the automatic ones.

They will even continue to retry even now, hoping that the listener on QM!/@
comes back.

I know of no graceful way of eliminating Automatic CLUSSNDRs. :-( My
biggest pet peeve with clustering. The only way I know how to do it is to
completely blow away the repositories in the cluster (partial and full).
Maybe someone knows a better way???


The one thing I have learned in the past couple of weeks with clustering is
never ever just delete something. You always have to un cluster it first
(queues, channels), and then delete.



-Original Message-
From: Ruzi R [mailto:[EMAIL PROTECTED]
Sent: Monday, August 25, 2003 8:39 AM
To: [EMAIL PROTECTED]
Subject: Urgent help: Unexpected behavior in the Cluster!!!


Hi all,

The QM1 and QM2 (on W2K, MQ 5.3) were full
repositories for our cluster. I have just replaced
them (full repositories) with QMA and QMB-- removing
QM1 and QM2 from the cluster. I have done this
following the instructions given in the MQ Cluster
manual. I have done the clean-up of the obsolete
channels etc. (e.g. TO.QM1 and TO.QM2). In other
words, no cluster member has any CLUSSDR channel
pointing to the old repositiories. The old
repositories have their cluster channels deleted.
Have done REFRESH CLUSTER REPOS(YES/NO) as per the
instructions in the manual.

As we don t need QM1 and MQ2 any longer, I did endmqm
on QM1 and QM2. Stopped the listener on both. Did some
testing; everything seemd OK in the cluster.

Then I had to move on to something else

MQ2T (on OS/390 MQ 5.3) is a member in the cluster. I
had modified the procs for MQ2T to pick up the new
connames (for QMA and QMB). As part of testing, my
colleague stopped MQ2T and re-started. Apparently, on
the re-start, the event logs on the old full
repositories got flooded with messages indicating MQ2T
was trying to connect

Re: Urgent help: Unexpected behavior in the Cluster!!!

2003-08-25 Thread Mike Davidson


Glad it worked!

Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]







Ruzi R [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
08/25/2003 11:03 AM
Please respond to MQSeries List



To:[EMAIL PROTECTED]
cc:
Subject:Re: Urgent help: Unexpected behavior in the Cluster!!!
Thanks, Mike! This did it!. I just did not think that
it would benecessary to issue this command as I was
doing the removal of the full-rep gracefully.

Ruzi
--- Mike Davidson [EMAIL PROTECTED] wrote:
 I found in my testing that using the RESET command
 got rid of the
 automatically-defined channels from the DIS
 CLUSCHL(*) command. I tried it
 after reading the Queue Manager Clusters manual
 and, believe it or not,
 it worked. Here's an excerpt (p. 68):

 You might use the RESET CLUSTER command if, for
 example, a queue manager
 has been deleted but still has cluster-receiver
 channels defined to the
 cluster. Instead of waiting for WebSphere MQ to
 remove these definitions
 (which it does automatically) you can issue the
 RESET CLUSTER command to
 tidy up sooner. All other queue managers in the
 cluster are then informed
 that the queue manager is no longer available.

 I hope this helps.

 Mike Davidson
 TSYS MQ Tech Support
 [EMAIL PROTECTED]





 Potkay, Peter M (PLC, IT)
 [EMAIL PROTECTED]
 Sent by: MQSeries List [EMAIL PROTECTED]
 08/25/2003 08:55 AM
 Please respond to MQSeries List



 To:   [EMAIL PROTECTED]
 cc:
 Subject:Re: Urgent help: Unexpected
 behavior in the Cluster!!!
 I would bet that the mainframe queue manager still
 has some automatic
 CLUSSNDRs leftover from when they were pointing to
 QM1 and QM2. just
 stopping / deleting / or modifying the manually
 defined ones does not do
 anything to the automatic ones.

 They will even continue to retry even now, hoping
 that the listener on
 QM!/@
 comes back.

 I know of no graceful way of eliminating Automatic
 CLUSSNDRs. :-( My
 biggest pet peeve with clustering. The only way I
 know how to do it is to
 completely blow away the repositories in the cluster
 (partial and full).
 Maybe someone knows a better way???


 The one thing I have learned in the past couple of
 weeks with clustering
 is
 never ever just delete something. You always have to
 un cluster it first
 (queues, channels), and then delete.



 -Original Message-
 From: Ruzi R [mailto:[EMAIL PROTECTED]
 Sent: Monday, August 25, 2003 8:39 AM
 To: [EMAIL PROTECTED]
 Subject: Urgent help: Unexpected behavior in the
 Cluster!!!


 Hi all,

 The QM1 and QM2 (on W2K, MQ 5.3) were full
 repositories for our cluster. I have just replaced
 them (full repositories) with QMA and QMB--
 removing
 QM1 and QM2 from the cluster. I have done this
 following the instructions given in the MQ Cluster
 manual. I have done the clean-up of the obsolete
 channels etc. (e.g. TO.QM1 and TO.QM2). In other
 words, no cluster member has any CLUSSDR channel
 pointing to the old repositiories. The old
 repositories have their cluster channels deleted.
 Have done REFRESH CLUSTER REPOS(YES/NO) as per the
 instructions in the manual.

 As we don t need QM1 and MQ2 any longer, I did
 endmqm
 on QM1 and QM2. Stopped the listener on both. Did
 some
 testing; everything seemd OK in the cluster.

 Then I had to move on to something else

 MQ2T (on OS/390 MQ 5.3) is a member in the cluster.
 I
 had modified the procs for MQ2T to pick up the new
 connames (for QMA and QMB). As part of testing, my
 colleague stopped MQ2T and re-started. Apparently,
 on
 the re-start, the event logs on the old full
 repositories got flooded with messages indicating
 MQ2T
 was trying to connect to them (at least that is what
 he says.. I haven t seen the errors myself. He
 cleaned
 up the log and saved the data somewhere but I don t
 know where yet). Why would this happen as there is
 nothing in the start-up procc pointing to QM1 or
 MQ2?
 I have to find an answer to this as we have another
 cluster whose full repsoitories will have to be
 replaced today. He said that, as soon as he stopped
 the listener on these qmgrs the errors stopped. It
 just so happens that we don t need QM1 and QM2 any
 longer, so I will delete them. My question is,
 suppose that QM1 and QM2 were to stay as independent
 queue managers (not as a cluster member) with their
 listeners running obviously, how would I prevent
 their
 logs from getting filled with messages from cluster
 queue managers trying to connect?

 My thinking is, because the new full repositories
 will keep the info related to the old repositories
 for
 90 days  during which time, any member qmgr
 re-starting will cause this kind of error???

 I would very much appreciate your input on the above
 unexpected behavior the cluster.

 Thanks,

 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


 This communication

Re: Urgent help: Unexpected behavior in the Cluster!!!

2003-08-25 Thread Mike Davidson


I've done it before on both. My logic being that I wanted both full repositories to be rid of the rogue auto-defined channels and not knowing for sure if running the RESET command on one full repository would cause MQ to let the other full repository know of the change/deletion.

Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]







Potkay, Peter M (PLC, IT) [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
08/25/2003 01:23 PM
Please respond to MQSeries List



To:[EMAIL PROTECTED]
cc:
Subject:Re: Urgent help: Unexpected behavior in the Cluster!!!
Mike/Ruzi, do you know if you have to issue the command on both your full
repositories? Or will one be enough?


-Original Message-
From: Ruzi R [mailto:[EMAIL PROTECTED]
Sent: Monday, August 25, 2003 11:36 AM
To: [EMAIL PROTECTED]
Subject: Re: Urgent help: Unexpected behavior in the Cluster!!!


Thanks everyone who has responded.The problem has been
resolved.

Just to answer Peter's question: As I said in my
original email, I had done REFRESH CLUSTER
REPOS(YES/NO) -- including the new repositories.
However, the mainframe did not like the REPOS parm. So
I issued it without the REPOS. The qmgrs on other
platforms still showed the CLUSSDrs to the old
repositories when issued DISPLAY CLUSQMGR(*), after
the REFRESH CLUSTER REPOS(YES) was issued.

Anyway, the problem has been resolved by issuing RESET
CLUSTER QMNAME(QM1/QM2) ACTION(FORCEREMOVE)
QUEUES(YES) command on the new full repositories. I
did not think that this command would be necessary as
I removed the full repositories and the cluster
channels gracefully (i.e. as per the steps indicated
in the Cluster manual).

Thanks,

Ruzi



--- Potkay, Peter M (PLC, IT)
[EMAIL PROTECTED] wrote:
 So you would issue this command from the QM where
 other QMS are still trying
 to send stuff to. In Ruzi's case, the old QM1 and
 QM2 queue managers, right?
 This would tell all other QMs in the cluster to
 delete any automatic
 CLUSSNDRs to QM1 or QM2?


 What do you do in the case where perhaps QM1 and QM2
 were already deleted?
 Is there any official way in this case? Perhaps
 issuing REFRESH CLUSTER
 REPOS(YES) on the QM that had the bad automatic
 CLUSSNDRs would flush them
 out? In Ruzi's case, the mainframe QM? (Sorry Ruzi,
 from your original post
 it was not clear if you issued this command on the
 mainframe or not).




 -Original Message-
 From: Mike Davidson [mailto:[EMAIL PROTECTED]
 Sent: Monday, August 25, 2003 9:48 AM
 To: [EMAIL PROTECTED]
 Subject: Re: Urgent help: Unexpected behavior in the
 Cluster!!!



 I found in my testing that using the RESET command
 got rid of the
 automatically-defined channels from the DIS
 CLUSCHL(*) command. I tried it
 after reading the Queue Manager Clusters manual
 and, believe it or not, it
 worked. Here's an excerpt (p. 68):

 You might use the RESET CLUSTER command if, for
 example, a queue manager
 has been deleted but still has cluster-receiver
 channels defined to the
 cluster. Instead of waiting for WebSphere MQ to
 remove these definitions
 (which it does automatically) you can issue the
 RESET CLUSTER command to
 tidy up sooner. All other queue managers in the
 cluster are then informed
 that the queue manager is no longer available.

 I hope this helps.

 Mike Davidson
 TSYS MQ Tech Support
 [EMAIL PROTECTED]




 Potkay, Peter M (PLC, IT)
 [EMAIL PROTECTED]
 Sent by: MQSeries List [EMAIL PROTECTED]


 08/25/2003 08:55 AM


 Please respond to MQSeries List




 To:[EMAIL PROTECTED]
 cc:
 Subject:Re: Urgent help: Unexpected
 behavior in the
 Cluster!!!

 I would bet that the mainframe queue manager still
 has some automatic
 CLUSSNDRs leftover from when they were pointing to
 QM1 and QM2. just
 stopping / deleting / or modifying the manually
 defined ones does not do
 anything to the automatic ones.

 They will even continue to retry even now, hoping
 that the listener on QM!/@
 comes back.

 I know of no graceful way of eliminating Automatic
 CLUSSNDRs. :-( My
 biggest pet peeve with clustering. The only way I
 know how to do it is to
 completely blow away the repositories in the cluster
 (partial and full).
 Maybe someone knows a better way???


 The one thing I have learned in the past couple of
 weeks with clustering is
 never ever just delete something. You always have to
 un cluster it first
 (queues, channels), and then delete.



 -Original Message-
 From: Ruzi R [mailto:[EMAIL PROTECTED]
 Sent: Monday, August 25, 2003 8:39 AM
 To: [EMAIL PROTECTED]
 Subject: Urgent help: Unexpected behavior in the
 Cluster!!!


 Hi all,

 The QM1 and QM2 (on W2K, MQ 5.3) were full
 repositories for our cluster. I have just replaced
 them (full repositories) with QMA and QMB--
 removing
 QM1 and QM2 from the cluster. I have done this
 following the instructions given in the MQ Cluster
 manual. I have done the clean-up of the obsolete
 channels etc. (e.g. TO.QM1 and TO.QM2). In other

Cluster question - (SYSTEM.CLUSTER.REPOSITORY.QUEUE)

2003-08-14 Thread Mike Davidson


Hello all,

(MQ5.3 on z/OS) -

I wanted to check with y'all on something. Upon setting up a cluster from scratch, when I look in my SYSTEM.CLUSTER.REPOSITORY.QUEUE I see two messages. I was expecting this queue to be empty. I got curious and stopped my CHIN started task and emptied out the queue and brought the CHIN back up only to see those two msgs appear again. One message is simply nulls and spaces (seems harmless) and the other has RFQR in the first four bytes followed by nulls and spaces??? I was wondering if these msgs are supposed to be there or if something fishy is going on

T I A

Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]
The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed.  The information may also constitute a legally privileged confidential communication.  If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited.  If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.  Thank you

Re: Handling messages on DLQ using JMS

2003-06-25 Thread Mike Davidson


Why don't you use the dead-letter-handler to route the messages to a queue that triggers your Java application to process the messages appropriately?

...Just a thought...

Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]







Sumeet Khosla [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
06/25/2003 02:05 AM
Please respond to MQSeries List



To:[EMAIL PROTECTED]
cc:
Subject:Handling messages on DLQ using JMS
Hi all,

We are communicating from one QM to another (server to server). While doing so, some messages are ending up on the DLQ of source QM. Now the issue is that how can we handle the messages arriving on the DLQ using JMS and not DLQ Handler. We tried associating a JMS MessageListener with the DLQ but that does not work. We got errors as MQJMS1034 and MQJMS1022.

Any pointers on this would be highly appreciated.

Thanks  Regards,
Sumeet

Long and Short Retry Dilemma/Question???

2003-05-30 Thread Mike Davidson


What is the general consensus for settings of the Long and Short Retry Interval/Count attributes. I apologize if this has been discussed before, and I'm sure it has been. We are currently running 5.3 on z/OS. The defaults for these attributes are as follows: 

Short Retry Interval: 60 seconds
Short Retry Count:10
Long Retry Interval:1200 seconds
Long Retry Count:9

Historically, we've taken the defaults - but lately we've had some issues come up that have prompted us to revisit these attribute settings.

Here are some thoughts:
If a sender channel goes into retry (let's say b/c of network problems) and it's still not resolved after 10 minutes and the channel is into its Long Retry and a client (business client, not an MQ Client) has to wait for 20 minutes for the next retry - that seems kind of long to wait. We were considering maybe changing it to 10 minutes.
Obviously this adds some overhead - but it kind of seems worth the sacrifice. I know that if I'm on the other end of a channel and I resolve the network issue, I'm not going to want to wait 20 minutes for the sender to retry - especially if this is a production issue.
Also, would it be worth it to increase the Short Retry interval to 2 minutes for a Count of 20? Thus, giving more time for the issue to be resolved before the Long Retry kicks in.

Just wondering what some of your thoughts were on this issue.

Thanks.

Mike Davidson
TSYS WebSphere MQ Technical Support
[EMAIL PROTECTED]

Re: MQ and Firewalls

2003-04-02 Thread Mike Davidson

Michelle,

You could place your ALTER CHANNEL commands in one of the System Initialization Parameters (INP1 or INP2) so that they get executed upon startup of the qmgr, but you'd probably want to remove the commands after startup. Otherwise they would be executed the next time the qmgr came up, as well.

Mike Davidson
TSYS MQSeries Tech Support
[EMAIL PROTECTED]

Michelle Russell [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
04/02/2003 04:16 AM
Please respond to MQSeries List

To:[EMAIL PROTECTED]
cc:
Subject:MQ and Firewalls
We are in the process of implementing a new firewall and the IP address
will change for certain MQ Subsystem channels.
I am wondering if there is a global way of changing the channel IP address
instead of waiting till MQ loads and the channels fail and then changing
the address manually per channel.?

Regards
Michelle

This email and any attachments are confidential. They may
contain privileged information and are intended for the
named addressee(s) only. They must not be distributed
without our consent. If you are not the intended recipient,
please notify us immediately and do not disclose, distribute
or retain this email or any part of it. Unless expressly stated,
opinions in this email are those of the individual sender
and not N Brown Group plc or any of its subsidiaries.
You must take full responsibility for virus checking this
email and any attachments.

Please note that the content of this email or any of its
attachments may contain data that falls within the scope
of the Data Protection Acts and that you must ensure that
any handling or processing of such data by you is fully
compliant with the terms and provisions of the Data
Protection Act 1984 and 1998.

N Brown Group plc. Registered office: 53 Dale Street,
Manchester, M60 6ES. Registered in England No.814103.

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

Old School RUNMQLSR

2003-01-16 Thread Mike Davidson


I've always started my MQ listeners (on Windows) via the command prompt - mainly b/c I learned on version 5.0. I recently upgraded this W2K machine to WMQ 5.3 and I continue to start the listeners this way - however, I'm noticing something different now. With previous versions, the listener window would give little status messages as things would happen concerning the listener program (such as: Channel program started.). I thought that to be pretty useful at times. With 5.3, there are no longer any of these messages showing up in the listener command prompt window. No big deal, really. I just was wondering what has happened, or what am I doing wrong. I checked out the syntax in the manual to see if there was some new parameter(s) that needed to be typed in, but I found nothing mentioning this feature.

Just curious.

Mike Davidson
TSYS MQSeries Tech Support
[EMAIL PROTECTED]

Re: Old School RUNMQLSR

2003-01-16 Thread Mike Davidson


Yep...I know about those. I just thought it was neat how they would show up in the actual Listener window. Is this 'functionality' no longer there.
Not trying to be picky - just curious.

Mike Davidson
TSYS MQSeries Tech Support
[EMAIL PROTECTED]







Peter Heggie [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
01/16/2003 08:44 AM
Please respond to MQSeries List



To:[EMAIL PROTECTED]
cc:
Subject:Re: Old School RUNMQLSR
You do get 'channel started' messages in the W2K event log..




From: Mike Davidson [EMAIL PROTECTED] on 01/16/2003 08:14 AM

Please respond to MQSeries List [EMAIL PROTECTED]

To:  [EMAIL PROTECTED]
cc:

Subject: Old School RUNMQLSR


I've always started my MQ listeners (on Windows) via the command prompt -
mainly b/c I learned on version 5.0. I recently upgraded this W2K machine
to WMQ 5.3 and I continue to start the listeners this way - however, I'm
noticing something different now. With previous versions, the listener
window would give little status messages as things would happen concerning
the listener program (such as: Channel program started.). I thought that
to be pretty useful at times. With 5.3, there are no longer any of these
messages showing up in the listener command prompt window. No big deal,
really. I just was wondering what has happened, or what am I doing wrong. I
checked out the syntax in the manual to see if there was some new
parameter(s) that needed to be typed in, but I found nothing mentioning
this feature.

Just curious.

Mike Davidson
TSYS MQSeries Tech Support
[EMAIL PROTECTED]

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

Re: Old School RUNMQLSR

2003-01-16 Thread Mike Davidson


Thanks, Paul.

Mike Davidson
TSYS MQSeries Tech Support
[EMAIL PROTECTED]







Paul Clarke [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
01/16/2003 11:15 AM
Please respond to MQSeries List



To:[EMAIL PROTECTED]
cc:
Subject:Re: Old School RUNMQLSR
I've always started my MQ listeners (on Windows) via the command prompt -
mainly b/c I learned on version 5.0. I recently upgraded this W2K machine
to WMQ 5.3 and I continue to start
the listeners this way - however, I'm noticing something different now.
With previous versions, the listener window would give little status
messages as things would happen concerning the
listener program (such as: Channel program started.). I thought that to
be pretty useful at times. With 5.3, there are no longer any of these
messages showing up in the listener
command prompt window. No big deal, really. I just was wondering what has
happened, or what am I doing wrong. I checked out the syntax in the manual
to see if there was some new parameter(s) that needed to be typed in, but
I found nothing mentioning this feature.

Just curious.

Mike Davidson

Hi Mike,

MQ 5.3 has changed to use what we call channel pools. Essentially when an
inbound channel connects to a listener, MQ passes the connection to one of
a pool of processes rather than just start a thread inside the listener.
Consequently the channel actually now runs inside a background process
(AMQRMPPA) which does not have a console window. We made this change for
scaleability reasons. In 5.2 it is possible to run out of per process
resource (ie. maximum number of threads) when you start many connections
into your listener. In 5.3, since this restriction is removed, you can now
keep on connecting channels until you run out of some system wide resource
which is fixable by buying a bigger machine (:-) though not always).

As mentioned before the channel still writes the channel start message, it
just goes to the event log (on Windows) and the AMQERR01.LOG file.

Cheers,
P.

Paul G Clarke
WebSphere MQ Development
IBM Hursley

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

Re: MQ Visual Edit beta v0.3.7

2002-11-19 Thread Mike Davidson

I tried to link to the site so I could download the beta version and it looks like the site is down

Roger Lacroix [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
11/18/2002 04:55 PM
Please respond to MQSeries List

To:[EMAIL PROTECTED]
cc:
Subject:Re: MQ Visual Edit beta v0.3.7
Hi,

There is documentation - all be it, it may not be very robust.

Click on Help - Help
Goto Chapter 3, section Adding a Queue Manager Access Profile

The only between adding a distributed queue manager and a mainframe queue
manager is that select the appropriate radio button value (just under queue
manager name).

Information that you will need:
1) MQ object names are case sensitive e.g. MQA1 is not the same as mqa1
2) For Channel Name, you can use SYSTEM.DEF.SVRCONN
3) You will need to know the IP # of the LPAR that has your queue manager.
4) You need to know the port that the listener is listening for the mainframe
queue manager that you are connecting to.

Note: To access a mainframe queue manager you MUST have CAF installed on the
mainframe.

later
Roger Lacroix
Capitalware Inc.

Quoting Kamal, Ahmed (ITD) [EMAIL PROTECTED]:

Hi
I tried your MQ Visual edit. There is no example or documentation how
to open a queue on a remote queue manager on OS/390 .

Thanks

Ahmed

-Original Message-
From: Roger Lacroix [mailto:[EMAIL PROTECTED]]
Sent: Sunday, November 17, 2002 11:44 PM
To: [EMAIL PROTECTED]
Subject: MQ Visual Edit beta v0.3.7

All:

I have released the next beta v0.3.7 of MQ Visual Edit.

The following enhancements / fixes have been made:
- Added code to support Clear Queue functionality.
- Enhanced the Open Queue Dialog panel to add a drop-down box for the queue
name field. Now the 10 previously inputted queue names will be saved.
- Updated docs (English only)

You can download MQ Visual Edit at:
http://www.capitalware.biz/beta.html

Note: This is an on-going project, so please send comments and / or
complaints to me.

Also, this beta will last for 11 weeks (end of January) because of
Christmas.

later
Roger Lacroix
Enterprise Architect
Capitalware Inc.
http://www.capitalware.biz

IBM Certified Specialist - MQSeries
IBM Certified Developer - MQSeries
IBM Certified Solutions Expert - MQSeries

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

Re: how to cleanly removed a crampy cluster on NT/2k?

2002-07-15 Thread Mike Davidson


I've seen this problem before (in the MQ310 course labs, believe it or not). In class, we cleared out the SYSTEM.CLUSTER.REPOSITORY.QUEUE and that got rid of any 'remnants'.

Mike Davidson
TSYS MQSeries Tech Support
[EMAIL PROTECTED]







Järgen Pedersen [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
07/12/2002 10:28 AM
Please respond to MQSeries List



To:[EMAIL PROTECTED]
cc:
Subject:Re: how to cleanly removed a crampy cluster on NT/2k?
Normally it requres that you make your qmgr repostory qmgr for that qluster
too (using a Namelist), then you can use RESET CLUSTER
and when reset cluster is done, and you see that it's claen, chenage your
repository settings back.
That approach is working fine for me It has been discussed previous.

I hope it will help you cleaning up. ;o)

Best regards

Joergen H. Pedersen
Systemprogrammer
WM-data SDC
[EMAIL PROTECTED]

IBM Certified MQSeries Specialist
IBM Certified MQSeries Solutions Expert

Please apply this disclaimer to the above message - the opinions are mine
and certainly not necessarily those of my employer.






Quigley, Robert [EMAIL PROTECTED]@AKH-Wien.AC.AT on 12-07-2002
15:20:46

Please respond to MQSeries List [EMAIL PROTECTED]

Sent by:  MQSeries List [EMAIL PROTECTED]


To:  [EMAIL PROTECTED]
cc:
Subject:  Re: how to cleanly removed a crampy cluster on NT/2k?



They should go away after 90 days.  You could try RESET CLUSTER
(clusterName) QMNAME(yourQMgrName) ACTION(FORCEREMOVE) on a repository q
mgr.

-Rob Quigley
Perot Systems
-Original Message-
From: Benjamin Zhou [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 11, 2002 11:29 AM
To: [EMAIL PROTECTED]
Subject: how to cleanly removed a crampy cluster on NT/2k?



Hi all,

after repeatedly encountering problems with clustering on NT/2k, we decided
to get rid of it and use distributed queuing instead.

I followed all the steps in the manual to remove qmgrs from the cluster,
and did everything from command line. The resulting objects are clean.

But I keep getting error messages from windows eventlog saying the
following:

Channel program 'TO_QM_BROKER' started.

Channel not defined remotely.
There is no definition of channel 'TO_QM_BROKER' at the remote location.
Add an appropriate definition to the remote hosts list of defined channels
and retry the operation.

Channel 'TO_QM_BROKER' not found.
The requested operation failed because the program could not find a
definition of channel 'TO_QM_BROKER'.
Check that the name is specified correctly and the channel definition is
available.

Channel program ended abnormally.
Channel program 'TO_QM_BROKER' ended abnormally.
Look at previous error messages for channel program 'TO_QM_BROKER' in the
error files to determine the cause of the failure.

...

There is absolutely not such a channel, I deleted them one by one. Where
else are such objects registered in MQ? Can they be cleanly removed? I
can't afford recreating the queue managers, too many people are using them.

This is definitely bad bugs in the clustering mechanism, does anyone from
IBM happen to know when the bug fix will be released? Several times, a
newly created cluster worked fine in the evening, but stops working the
next morning.

I appreciate any hint on solving this problem or get around it.

thanks a lot,

Benjamin Zhou
Princeton Financial




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

Re: Remote Admin

2002-05-16 Thread Mike Davidson


The Support Pac is MO71:

http://www-3.ibm.com/software/ts/mqseries/txppacs/txpm2.html

Mike Davidson
TSYS MQSeries Tech Support
[EMAIL PROTECTED]







Pete Moir [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
05/16/2002 08:49 AM
Please respond to MQSeries List



To:[EMAIL PROTECTED]
cc:
Subject:Remote Admin
Hi,

apologies if this is going over old ground, I am only an occasional
subscriber (and only an occasional MQer), but I couldn't quite find what I
wanted on the archive.

We want to use MQExplorer on NT to administer queue managers on remote
systems I believe I can do this for remote queue managers running on most
platforms (UNIX etc) but not OS/390.

However I seem to remember there was a product which allowed you to remotely
administer OS/390 queue managers in this way. Does anyone know of it ?


thanks,
Pete.


_
Notice to recipient:
This e-mail is meant for only the intended recipient of the transmission,
and may be a communication privileged by law. If you received this e-mail in
error, any review, use, dissemination, distribution, or copying of this
e-mail is strictly prohibited.

When addressed to our clients any opinions or advice contained in this
internet e-mail are subject to the terms and conditions expressed in any
applicable governing terms of business or client engagement letter issued by
Bank of America.

Both Bank of America, N.A and Banc of America Securities Limited are
regulated by The Financial Services Authority.
_

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

Re: Help on Candle Management Workstation

Re: Candle Command Center for MQSeries on mainframe

Re: Disappearing cluster queues

Re: Disappearing cluster queues

Re: Disappearing cluster queues

Re: MMC/Any GUI for administering MQ on AIX

Re: Moving the list server?

MQ HFS information

MQINQ in a clustered environment

Re: Removing a dead server from an MQ cluster

Re: MQ and SSL on z/OS - RESOLVED

MQ and SSL on z/OS

Re: TCP/IP errors

Re: test tool allowing us to specify a msg id

Clustering question regarding communications (MQ 5.3 on z/OS 1.2)

Re: URGENT HELP NEEDED: on cluster resolution

Re: CCSID...again

Re: Connection or remote listener unavailable error

Re: Process-Start Channels

Re: Linking two Q Mgrs one with TCP/IP and other with SNA

Re: Cluster question - (SYSTEM.CLUSTER.REPOSITORY.QUEUE)

Re: Urgent help: Unexpected behavior in the Cluster!!!

Re: Urgent help: Unexpected behavior in the Cluster!!!

Re: Urgent help: Unexpected behavior in the Cluster!!!

Re: Urgent help: Unexpected behavior in the Cluster!!!

Cluster question - (SYSTEM.CLUSTER.REPOSITORY.QUEUE)

Re: Handling messages on DLQ using JMS

Long and Short Retry Dilemma/Question???

Re: MQ and Firewalls

Old School RUNMQLSR

Re: Old School RUNMQLSR

Re: Old School RUNMQLSR

Re: MQ Visual Edit beta v0.3.7

Re: how to cleanly removed a crampy cluster on NT/2k?

Re: Remote Admin

35 matches

Site Navigation

Mail list logo

Footer information