We are using MQSeries 5.2, JMS (5.2) and MQSI (2.1) to build a
publish-subscribe framework.
The subscriptions are durable, and continue to exist after our applications
have died (to ensure messages on the subscribed topic keep flowing even if
my subscriber is not running).
The problem we are havi
I have verified that when I give it an interval of 6000 that the tran ends
after 60 seconds.
But even if my interval was higher than I had intended, that wouldn't
explain why the CPU time
goes up during the wait.
I believe that Jim Ford has hit the nail on the head in saying 'blame the
developer'
Janet,
Stefan raises a good point. Remember that the timeout interval for MQGET is
measured in milliseconds (thousands of a second) and not second or minutes.
PErhaps your timeout value needs to be multiplied by 1,000 or some such other
order of magnitude.
Let us know what the answer is.
Dave
My two cents worth in this discussion, If I may.
I am a string proponent of using different queue manager names for production
and test systems. This provides you with absolute protection from
inadvertently sending test data into your production system.
Case in point: A client once brought in
I suppose your wife is a dentist ?
robertbroderick@ To: [EMAIL PROTECTED]
HOTMAIL.COM cc:
Sent by: Subject: Re: looking a gift horse in
the mouth!
MQSERIES@akh-wi
Bruce,
I'm not sure who you think might flame you, but it definitely won't be me. I
understand that not all internet connections are created equal, etc., however I tried
to make MQSeries.net as accommodating as possible. There are minimal graphics, and
people with dialup tell me it's still pr
I agree, but let's make the subject line Mutually exclusive for those that
don't have good filtering software (ie MQ and MQSI would get hit when
filtering for MQ). The platform and other potential info like NT JMS or
2000 XML would be helpful in drilling down to the thread that one wants to
see.
has anyone else seen this error when
trying to add a rule, or update an existing rule (using NNSY Rules GUI, V5.6) --
the first time works fine, but the second and subsequent times give me this
informative dialog box.. it only fails after I add a subscription..
(the env. is MQSI V2.
Watch it Murthy, we use your software here and purchase order renewals are
comming up
bee-oh-dubble-bee-dubble-egh
>From: Suntosh Murthy <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: How about a sep
A very good point is made here fo descriptive subject lines. So as the chief
architect here, (did I just hear the sound of breaking glass??) I would say
we start any subject line with MQ or MQSI or MQWF. This would solve the
problem. BUT(you knew this was comming) being a traffic cop only allo
Why could you not just subscribe to all three lists then. Having three
lists would allow flexibility and would allow you to subscribe to all 3 and
others 1, 2 or 3.
Robert Broderick <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on
06/25/2002 05:25:24 AM
Please respond to MQSeries List <[EMAIL PROTECT
Plase! I agree
Mike Kelly <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 06/25/2002 01:15:44 AM
Please respond to MQSeries List <[EMAIL PROTECTED]>
Sent by:MQSeries List <[EMAIL PROTECTED]>
To:[EMAIL PROTECTED]
cc:
Subject:How about a separate list for MQSI/WMQI?
It would benef
My wife did the same thing to me
>From: "Beinert, William" <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: looking a gift horse in the mouth!
>Date: Tue, 25 Jun 2002 10:39:15 -0400
>
>You can tell a horse's age by the wear on it's teeth...
... I agree -- mqseries.net has separate threads by product type which are very
specific (and very useful) -- we use the ListServer for higher level questions, then
mqseries.net to drill down into
more specific areas...
-Original Message-
From: Brandon Duncan [mailto:[EMAIL PROTECTED]]
www.mqseries.net is fine if you're connected all the time, and you're
willing to work at the speed of internet page updates. I'm sure to get
flamed here, but IMHO, www.mqseries.net is of limited worth because of the
limitations to user community (many people don't have high speed internet),
and i
I'm not sure if it explains your experience, but unlike batch, the CICS
adapter simulates get w/wait. Remember, the adapter pools 8-or-so qmgr
connections that it shares among all CICS programs. The adapter cannot
afford to tie up any of those connections with a bona-fide get w/wait.
> -Origi
Please disregard the reply I made regarding
MQSeries and XP. It had nothing to do with any of that and was meant for a
buddy of mine (concerning ATI’s next gen video technology).
Hahahah! SWEEET!!! Remember when my father said we didn't need more than 16
bit color? LOL! Too funny.
I wonder when we will have 256 bit color?
---
Robert Martin ([EMAIL PROTECTED])
Design Engineer
SISCO Inc,
6605 19 1/2 Mile Road
Sterling Heights, MI 48
I can't help but notice people mentioning the need for separate lists,
and the ability to look at the discussions in a threaded format. If
people are looking to avoid discussions outside of their particular
field of interest, why not use www.MQSeries.net rather than the
ListServ? The various categ
Wow, some people seem to have lots of free time.
-Original Message-
From: Robert Broderick [mailto:[EMAIL PROTECTED]]
Sent: Tue 6/25/2002 8:32 AM
To: [EMAIL PROTECTED]
Cc:
Subject: Re: How about a separate list for MQSI/WMQI?
>From an old horse trader ... more correctly, you can tell a horse's age by
the length and angle of its teeth, especially the front incisors ... hence
the expression "long in the tooth" being equated with old age.
Richard W. Braznell
MQ Series Solutions Expert
IBM Global Services, Strategic Middl
In order to determine what you don't want to read you need to have a useful subject line. The way things stand right now, there's now clear way to determine whether a message is related to a particular product unless the author kindly and thoughtfully added it in there. You have to admit, some of
re: usenet -- GOOD point taken!
"Beinert,
William" To: [EMAIL PROTECTED]
Subject: Re: How about a separate list
for MQSI/WMQI?
Sent by:
MQSeri
At 09:38 AM 6/25/2002 -0400, [EMAIL PROTECTED] wrote:
>I believe, when purchasing a horse you would check its health by verifying
>its teeth were in good shape.
Perfectly true! Which is why the expression refers to a "gift" horse --
ie, one you *don't* pay for! This list is provided for free --
not to beat a dead horse, but 'some' horse traders have a well deserved
reputation.. you also look at the teeth to get a good indication of its age
because sometimes thats the only way to know.. I could tell you stories..
but that would be cross-posting..
From: [EMAIL PROTECTED] on 06/25/2002
You can set the database, compute and mqoutput nodes to transaction
mode=commit, which commits work immediately. I haven't tested this, but if
you are looping through a compute node with a propogate it should send the
record on to the other nodes which will process and commit the changes
immediate
We had an interesting problem yesterday, and it was caused by how these two
obscure parameters were set on a receiver channel.
What happened is that we had an application on a remote qmgr that was
sending "bad" messages to an MQSI queue. One of our admins put-disabled the
queue on the MQSI machin
Yes, let's keep them all together.
Ruzi
--- Robert Broderick <[EMAIL PROTECTED]>
wrote:
> You've been silently elected!!!
>
> OH wait!! I don't have time to do that.
>
> I was only suggesting!!
>
> I have to do this for free in my spare time
>
> Wait I never meant to volunteer.
>
You can tell a horse's age by the wear on it's teeth...
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 25, 2002 9:38 AM
To: [EMAIL PROTECTED]
Subject: looking a gift horse in the mouth!
I believe, when purchasing a horse you would check its hea
Echoing this list to Usenet would result in major amounts of SPAM being
directed to posters.
IBM-MAIN suffers from this, and takes much administration to ameliorate.
Keeping MQSI, Workflow and MQ together makes a lot of sense to me, since the
underlying technology is MQ.
Many mail clients, even
Does anyone know how one would go about getting this LIST into a usenet
newsgroup feed? I know one of the CICS LISTSERV peers is out there, but it
might be helpful if one could read this list as a threaded discussion.
Then you could read only the threads you're interested in.
Bill,
I probably should have explained a little further
Cluster queue managers communicate using the UUID to uniquely identify
specific queue managers. If you were to simply delete the old queue
manager and recreate the new one they will have different UUIDs and
therefore cluster communicat
Paulo,
I am already doing that. I wanted to automate so that in the event that I am
unavailable to check the Event Viewer the logs will not fill the disk.
I am not well versed in Perl, so I was hoping someone had added the hooks to
check the Windows registry for LogPath and LogType.
Thank you.
I agree with Bobbee. Why not set up an agent in your e-mail program that sends the messages to different folders?
Glen Shubert
Robert Broderick <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>
06/25/2002 08:25 AM
Please respond to MQSeries List
To: [E
I believe, when purchasing a horse you would check its health by verifying
its teeth were in good shape.
robertbroderick@ To: [EMAIL PROTECTED]
HOTMAIL.COM cc:
Sent by: Subject: Re: How
CSD #4 on V5.2 provides an API crossing Exit. We can use this exit to
examine all call to MQ. There's a BEFORE phase and AFTER phase. That is,
We can examine and alter the GET criteria during the BEFORE phase, and
Change the data content during the AFTER phase.
If, during the AFTER phase of an
I believe it goes
like this...
Channels:
MaxChannels=xxx
Frank
-Original Message-From: Chan, John X
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, June 25, 2002 8:21
AMTo: [EMAIL PROTECTED]Subject: increase max
channel definition
does
any one recall the masthead on m
I agree. Keeping the information concentrated to a single list makes it
easier to monitor and interact.
robertbroderick@ To: [EMAIL PROTECTED]
HOTMAIL.COM cc:
Sent by: Subject: Re: How
>does any one recall the masthead on mqs.ini that I need to change to
increase the max number of channel definitions ?
>JC
You need to change the QM.INI file not MQS.INI
Add the lines
Channels:
MaxChannels = 5000
or similar.
Cheers,
P.
Paul G Clarke
WebSphere MQ Development
IBM Hursley
There is a Queue Manager ID associated with QM, and if you just suspend the
old one and connect the new one, those IDs will not match and disorder and
chaos will intrude into your world...
You need to make sure the cluster has completely forgotten that the old QM
has ever existed.
Bill
-Orig
I suspect one of the problems with separate lists is that too many of the
issues will need to be cross-posted to get an adequate answer thus
generating even more messages for those interested in all three topics.
-Original Message-
From: Francois Van der Merwe1 [mailto:[EMAIL PROTECTED]]
I think John's point is that if you are not patient and don't wait until
your changes have been shuttled around the entire cluster (depending on how
many repositories you have) before re-adding the new one, you could have the
two events (leaving and joining) running into each other in the reposito
You've been silently elected!!!
OH wait!! I don't have time to do that.
I was only suggesting!!
I have to do this for free in my spare time
Wait I never meant to volunteer.
Now you get the picture. Whoever is running the list is probably doing it
out of the goodness of his/he
You've been silently elected!!!
OH wait!! I don't have time to do that.
I was only suggesting!!
I have to do this for free in my spare time
Wait I never meant to volunteer.
Now you get the picture. Whoever is running the list is probably doing it
out of the goodness of his/he
We have not experienced this in any of our 30+ qmgrs and CICS regions. I would ensure that you have a reasonable wait interval on the get (specified in milliseconds).
Glen Shubert
"Dye, Janet E" <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>
06/24/2002 05:24 PM
Please respo
Lets face it. Many of us are interconnected to MQSI thru MQ, and also
WorkFlow. MAny of the problems are related. Also being the BIG Websphere MQ
family why would you want to seperate them. I am both MQ and MQSI Cert. I
prefer to have all those discussions here. It would be a pain to bounce back
a
does
any one recall the masthead on mqs.ini that I need to change to increase the max
number of channel definitions ?
JC
I agree with Mike. If you want to see all three, just read all of them or
route your incoming email to one folder.
Francois van der Merwe
Mike Kelly
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
>
Re-sending as not sure this reached the list!
Steve
MQ of itself is a messaging product. For managed (audit, status tracking,
integrity and re-start recovery etc) file transfers USING MQ you would want to
consider using a third party product of
I don't know anything about the MS62 update, but you can use the the Windows Event
Viewer to check that last log file that you can delete. It's not an automatic
solution, but it can solves the problem when the log is gettint huge.
Cheers,
Paulo
-Original Message-
From: Bill Seng [mail
Firstly, don't forget to restart your queue manager after adding the resource to the
QM. I suppose that you correctely created the resource manager.
You have also to put the jdbcdb2.dll file in the PATH.
The reason code returned by your application isn't in the MQ Docs because (and I don't
know
The main reason is the fact that all of them belong to the same family -
i.e. the MQ Family.. and moreover a lot of issues that are faced in SI/WF
are also related to base MQ as well, or they can be traced to base MQ... so
this makes it all the more important to have them all on the same list.
th
Yup,
I with Mike.There
should really be separate list for SI and Workflow.
Regards,
Anand Jammi
- Original Message -
From:
Mike Kelly
To: [EMAIL PROTECTED]
Sent: Tuesday, June 25, 2002 1:45
PM
Subject: How about a separate list for
MQSI/WMQI?
It would ben
It would benefit me a lot to have the MQ list of questions/issues separated from SI and WorkFlow. Does anyone else agree? Who would we need to speak to? What was the reason for only maintaining one list?
Regards,
Mike
Hi,
we have a channel security exit for client authentication with userid and
password against RACF on z/OS. It works fine, but we encountered the
following problem. If the authenticated user is not allowed to connect to
the queue manager via RACF MQCONN class, the access is nevertheless granted.
55 matches
Mail list logo
