Jones, Dan -- OOTO, Friday, 16 Jan PTO; Monday, 19 Jan Holiday
I will be out of the office starting 01/16/2004 and will not return until 01/20/2004. Calls on problems involving MQSeries or MQSI should be directed to the ING Solutions Center at 800.790.2978. Calls on problems involving MQSeries or MQSI should be directed to the ING Solutions Center at 800.790.2978. All other inquiries should be directed as follows: MQSeries - Contact Mamta Mehra at 612.342.3574 MQSI - Contact Ken Hill at 860.723.9059 All others - John Vondrachek at 612.342.3600 Thanks, Dan Jones 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
Yongky Limawan is out of the office.
I will be out of the office starting 19/01/2004 and will not return until 03/02/2004. Please forward the message to group id RHO.IT.CS.FCS for urgent attention. -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. 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
Moving WMQI Config Manager
Hi everyone, I've got a scenario as follows: Windows Box W1 hosts the configmgr for Broker B1 on Unix box A1. There are message flows , message sets already deployed on B1. The requirement now is : - To delete the config mgr on W1. - Create a new config mgr on box W2 that will act as the config mgr for B1. What would be the procedure for this? Has anyone done this before? Thanks WS Yahoo! Messenger - Communicate instantly...Ping your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html 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
Problem committing messages
Our Java application is reading multiple entries in Oracle. Each record is placed in an MQSeries message object. When four messages are created, written and committed the commit fails. When three messages are created, written to the queue and committed the commit succeeds. In our case, the messages are 20 MB in size. We have checked the logging and it is linear and we have plenty of disk space. We have checked the MQSeries objects and confirmed they can handle messages this size. I know there is a max uncommitted message count, is the some other parameters that I need to be aware of that covers max uncommitted data such that 70+MB of uncommitted messages fail but 60MB of uncommitted messages succeeds. 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: Problem committing messages
Is there some file size limit controlled by the OS? Is there a message on the qmgr error log? Nick -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Jeff A Tressler Sent: Monday, January 19, 2004 1:35 PM To: [EMAIL PROTECTED] Subject: Problem committing messages Our Java application is reading multiple entries in Oracle. Each record is placed in an MQSeries message object. When four messages are created, written and committed the commit fails. When three messages are created, written to the queue and committed the commit succeeds. In our case, the messages are 20 MB in size. We have checked the logging and it is linear and we have plenty of disk space. We have checked the MQSeries objects and confirmed they can handle messages this size. I know there is a max uncommitted message count, is the some other parameters that I need to be aware of that covers max uncommitted data such that 70+MB of uncommitted messages fail but 60MB of uncommitted messages succeeds. 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 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: Image backup of a Full Repository QM. Then a restore. Uh-oh
Peter,
What is the right way to get QM2FULL to get itself
up to date
REFRESH CLUSTER(CLUSTER1) REPOS(NO) did not do it.
You would have to use REPOS(YES) on QM2FULL after
altering it so that it is not a full rep. The steps
are:
1- Alter QM2FULL REPOS(' ')
2- REFRESH CLUSTER(CLUSTER1) REPOS(YES)
3- Alter QM2FULL REPOS(CLUSTER1)
Regards,
Ruzi
--- Potkay, Peter M (PLC, IT)
[EMAIL PROTECTED] wrote:
The REFRESH command does not accomplish what I need.
I guess I will see what
IBM says. I'll post there answer.
Kumar gave me this idea. What do you guys think?
1.) Start the QM back up after the image restore.
2.) Alter the QM to be a partial repository.
(Cluster now has only 1 full
repository)
3.) Remove the QM from the cluster.
4.) Reintroduce the QM to the cluster as a full
repository.
Would reintroducing this QM again as a new full
repository work, and cause
the other full repository to push everything over?
Or would I corrupt the
cluster with duplicate entries for that QM, even
though the QMID stayed the
same?
-Original Message-
From: John Scott [mailto:[EMAIL PROTECTED]
Sent: Friday, January 16, 2004 3:37 AM
To: [EMAIL PROTECTED]
Subject: Re: Image backup of a Full Repository QM.
Then a restore. Uh-oh
I hear what you are saying and your theory sounds
fine, however, the Queue
Manager Clusters manual in Chapter 7 says the
following on recovering a
Queue Manager:
Recovering a queue manager
To recover a queue manager in a cluster, restore the
queue manager from a
linear log. (See the WebSphere MQ System
Administration Guide for details)
If you have to restore from a point-in-time backup,
issue the REFRESH
CLUSTER command on the restored queue manager for
all clusters in which the
queue manager participates.
There is no need to issue the REFRESH CLUSTER
command on any other queue
manager.
So if yo do this and it does not work, then it would
seem about the right
time to call IBM support to find out why it doesn't
work.
Regards
John Scott
IBM Certified Specialist - MQSeries
Argos Ltd
-Original Message-
From: Potkay, Peter M (PLC, IT)
[mailto:[EMAIL PROTECTED]
Sent: 15 January 2004 13:24
To: [EMAIL PROTECTED]
Subject: Re: Image backup of a Full Repository QM.
Then a restore. Uh-oh
In the cluster manual, they do talk about fixing a
QM that was restored from
an image backup. But in the example, they only deal
with a QM that was, is
and will be a partial repository. The refresh
command works fine in this
case, since all it does it is PUSH out all its info
to the full
repositories, and then learns about other queues in
the cluster on an
as-need-to-know basis from the fulls.
A full repository needs to PULL in info from the
other full repository in
this case, so that it knows everything. The problem
I was having was that
puts were failing because the QM did not know about
the other new queues in
the cluster, and being a full repository itself, it
considered itself the
definitive source. If I don't know about, it must
not be true!!! It did
not even bother checking with the other full.
I don't see how issuing that command, even after
making it a partial and
using the repos yes option, would give me what I
want.
Consider a cluster with 1000 partial repositories
and 2 full. If I made a
new QM that is a partial and issued the REFRESH
command, even with repos
YES, that new QM would not suck in all the info for
all 1000 QMs held in the
full repositories. It would only push out its own
info to the fulls. And it
would only get new info on queues on those 1000
other QMs as it needed them.
I need a particular QM (QM2FULL) to suck in ALL the
info from another QM's
full repository (QM1FULL). The refresh command does
not do that. It pushes
info our rather than pulling info in.
Its almost as if I need a SYNC type command, to tell
one QM to get all the
Full repository info from another QM.
I had hoped that QM2FULL would connect and sync with
QM1FULL when I brought
it back up, but it did not.
I guess it almost makes sense that it didn't. Full
repositories do not
constantly talk to each other for no reason. They
just update each other
when there is new info to share. When QM2FULL was
restored, QM1FULL just saw
that event as his buddy coming back up, not a new QM
that needed to be told
everything.
Since QM2FULL was the exact QM, why would QM1FULL
need to push everything
over again? How would QM1FULL know that QM2FULL was
out of sync? Maybe
QM1FULL was out of sync. And how would it even know
how long it has been out
of communication with its partner QM? Maybe it was
only 1 second, or 1 week.
These questions make me believe that the full
repositories do not keep
pulsing info back and forth. And why perhaps a SYNC
from QM1 to QM2 type
command is needed for Full Repositories?
-Original Message-
From: John Scott [mailto:[EMAIL PROTECTED]
Sent:
SYSTEM.JMS.REPORT.QUEUE -- Question
Hi All, Does anyone knows what message is put on SYSTEM.JMS.REPORT.QUEUE ?? We are using WMQ 5.3 with csd4 along with WMQI2.1, predominantly our applications are pub/sub based, with all durable subscriptions. Till recently the depth of report queue used to be 0, but since last one week messages are piling on this queue and the current depth has reached 3500. Although right now none of our applications are facing problems because of this, but we are not sure what could be the reason behind so many messages being piled up on the report queue. Any pointers will help. Thanks Gaurav 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: Problem committing messages
Jeff, You should have the MQ systems administrator check out the Log options for the queue manager. It sounds like either you log files are not large enough (specified as a number of 4K pages) or you do not have enough log files (primary) to handle the large messages. It is not only a matter of free disk space, but the actual log file specifications for the queue manager and just how much space can be utilized for logging purposes. You did not specify your environment, but in a case like Windows you can file these options within the Properties for the queue manager. Jeff A Tressler wrote: Our Java application is reading multiple entries in Oracle. Each record is placed in an MQSeries message object. When four messages are created, written and committed the commit fails. When three messages are created, written to the queue and committed the commit succeeds. In our case, the messages are 20 MB in size. We have checked the logging and it is linear and we have plenty of disk space. We have checked the MQSeries objects and confirmed they can handle messages this size. I know there is a max uncommitted message count, is the some other parameters that I need to be aware of that covers max uncommitted data such that 70+MB of uncommitted messages fail but 60MB of uncommitted messages succeeds. 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 -- Regards, Thomas DunlapChief Technology Officer[EMAIL PROTECTED] Themis, Inc.http://www.themisinc.com1 (800) 756-3000 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: SYSTEM.JMS.REPORT.QUEUE -- Question
This may help. http://www-306.ibm.com/software/integration/mqfamily/library/manuals99/csqza w/csqzaw2l.htm Nick -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Mittal, Gaurav Sent: Monday, January 19, 2004 2:42 PM To: [EMAIL PROTECTED] Subject: SYSTEM.JMS.REPORT.QUEUE -- Question Hi All, Does anyone knows what message is put on SYSTEM.JMS.REPORT.QUEUE ?? We are using WMQ 5.3 with csd4 along with WMQI2.1, predominantly our applications are pub/sub based, with all durable subscriptions. Till recently the depth of report queue used to be 0, but since last one week messages are piling on this queue and the current depth has reached 3500. Although right now none of our applications are facing problems because of this, but we are not sure what could be the reason behind so many messages being piled up on the report queue. Any pointers will help. Thanks Gaurav 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
Re: AMQ6150 MQSeries semaphore is busy
It is possible that your system is running on the edge as far as resources (in this case semaphores) are concerned. You might want to start gathering statistics as far as resource usage is concerned and begin to make a case for regen'ing the kernel and increasing your systems resources (shared memory segments, semaphores, etc.). When you upgrade to MQ 5.3 it will most likely exacerbate the situation since it uses more resources. Cheers... Jim Nuckolls Karthikeyan, T. (Karthikeyan) wrote: Hi all, On HP-UX MQ 5.2, I'm getting the following error. Please explain this error message and give the solution. AMQ6150: MQSeries semaphore is busy. EXPLANATION: MQSeries was unable to acquire a semaphore within the normal timeout period of 0 minutes. ACTION: MQSeries will continue to wait for access. If the situation does not resolve itself and you suspect that your system is locked then investigate the process which owns the semaphore. The PID of this process will be documented in the accompanying FFST. thanks karthik ** PLEASE NOTE: The above email address has recently changed from a previous naming standard -- if this does not match your records, please update them to use this new name in future email addressed to this individual. This message and any attachments are intended for the individual or entity named above. If you are not the intended recipient, please do not forward, copy, print, use or disclose this communication to others; also please notify the sender by replying to this message, and then delete it from your system. The Timken Company ** 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
Any change management tools out their for WMQ objects
Title: Any change management tools out their for WMQ objects Hi We have embarked on a standardisation path of queue names across various platforms and unfortunately WebSphere MQ doesn't provide any functionality to RENAME the queue (it would have been handy to have this facility). I have been told that, only course of action I have is to UNLOAD, DELETE, DEFINE and LOAD for each local queue - preserving triggering information, process details, user-data, appl-data etc.. So be it, but are there any change management tools that can make our life easy. Thanks in advance Rao Adiraju MQSeries Specialist The National Bank of NZ Ltd. Tel: +64-4-494 4299 Fax: +64-4-802 8509 Mbl: +64-211-216-116 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.
Re: Any change management tools out their for WMQ objects
** Note: This e-mail is subject to the disclaimer contained at the bottom of this message. ** : The 'saveqmgr' supportpac is the best tool for what you want to do. : The information transmitted in this message and attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited. If you have received this in error, please contact the sender and delete this e-mail and associated material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files, with the permission of the sender. This message has been scanned for viruses and cleared by MailMarshal. : 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
