Absolutely, Brian. And I am a total advocate of designing applications to be
free of dependencies on physical aspects. I just wanted to point out that
there is a guarantee of sequential delivery, which in many 'simple' MQ
configurations (no clusters etc.) is all that you need.
Anyway, I think
In this particular problem, my advice to you all is: don't trust entirely in
what the MQ docs or the MQ consultants say about the message order. Anyone
who has huge message exchange between machines in different networks knows
that sometimes (0.1% of the cases) the arriving order is not the
Hi,
We have an application running on OS/390 and placing messages in AIX. We do
not employ any conversion in this case. This set up works just fine.
But when we ran our application program on a different S390 and AIX, the
messages that arrive in the AIX were of EBCDIC format. Why would this
Title: RE: EBCDIC to ASCII conversion
I think the most likely thing is that you had the channel set to do the conversion in the first environment. I believe that doing the conversion at MQGET time is the preferred (and recommended) method.
Conversion compares the CCSID in the MQMD with your
A midsize car would be appropriate!!! With chrome wheels of course!!
bobbee
From: Randy J Clark [EMAIL PROTECTED]
Reply-To: MQSeries List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: spam
Date: Thu, 19 Sep 2002 11:37:12 -0700
Sorry I am wrong
Well CLEVER is the word. But as one thinks of it, they bypass the
restriction of no solicitation on the LISTSERV. They just create their
own!!
bobbee
From: Randy J Clark [EMAIL PROTECTED]
Reply-To: MQSeries List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
My understanding given a couple dog-and-pony shows from IBM:
MQIAC - or My-ack is a CICS adapter for scripting micro-flow 3270
interactions on the host and exposing those interactions via MQ, TDQ, or
JCA. Many moons ago, Early Cloud had a FEPI (Front-End Programming
Interface) component for
Hello, this is the last message () in the dead.letter.queue of an AIX
cluster queue manager. I really dont understand the meaning of the reason
code X'0001. I spent yesterday's afternoon trying to solve why these
messages are going to the dead letter queue.
I hope that you could give some
Title: RE: EBCDIC to ASCII conversion
Ganapathy,
To the best of my knowledge i beleive that the channels are defined differently from your previous setup. There is a data conversion parameter on the sender channel which can convert the message before sending it to the receiving node.
Title: RE: Running MSMQ on Server Side to MQSeries on Mainframe Side usi ng a Bridge Design Question
Dennis,
Thanks for the information.
Where can I read about the CICS Bridge? Is this an add on product to
MQ Series? Is this a cost item?
My biggest problem is that we have to have the
Keith,
1) The CICS bridge will do most of this for you. I do not believe a SIL
sample has been posted on the listserver.
3) I'll come back to 2 after this one. The MSGID and CORRELID are part of
the message header. When a program puts a message into a queue it has the
option of specifing
Thanks everyone for the Linux info.
Bill C.
-Original Message-
From: Roberto Sanchez [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 20, 2002 9:20 AM
To: [EMAIL PROTECTED]
Subject: Re: MQSeries and Linux
I have 5.2 running in Suse 7.1 in a intel box.
Regards.
If you are running MQ 5.3, you will also need connector.jar. It is noted in the README
file.
Regards,
Stephen Hochman
Merrill Lynch
Middleware Technology Services
-Original Message-
From: Joshi, A (Anant) [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 20, 2002 10:46 AM
To: [EMAIL
I will be out of the office starting 09/20/2002 and will not return until 09/23/2002.
I will respond to your message when I return.
*** IMPORTANT NOTE *
The opinions expressed in this message and/or any attachments are
those of the author and
Title: Workflow DB2 deadlock
We're experiencing constant deadlock on our workflow run-time database . we use DB2. the message didn't indicate any specific action to correct it. the event log is full of such msg now - on NT, workflow 3.3.0 SP#4.
Can any DB2 expert out there give me a hint
A question from the sticks,
Within the MQSeries shutdown scripts on our AIX platform, which was
inherited, the following occurs.
An endmqm Quiesce of the qmanager is issued.
If not ended after waiting 60 seconds, a Kill of the endmqm is issued and an
endmqm Immediate is issued.
If not ended
My feeling is I have to trust the docs 100%, or not at all for anything. If
something conflicts with what the docs say, I want to get to the bottom of
it or get to the point where IBM concedes and changes the doc.
If I can't trust the doc on message order, why should I trust it on expiry,
or
Hi Stacy. How did you come to this conclusion? Is it documented somewhere?
And has your testing been successful?
Peter Potkay
IBM MQSeries Certified Specialist, Developer
[EMAIL PROTECTED]
X 77906
-Original Message-
From: Robert Broderick [mailto:[EMAIL PROTECTED]]
Sent: Friday,
got to work 5 hours ago and most of my morning has been tied up with MQ and related issues
I am sending this before I get to todays list messages, cause I would like everyone know how we shot ourselves in the foot
it is amazing how close everyone has been on this issue, and have helped me in
Title: Workflow DB2 deadlock
Our
company certified Workflow for corporate use. We encountered numerous deadlocks.
I don't have the details, but I know we worked with IBM intensively to fix the
problem. My advice would be to open a ticket with IBM. They SHOULD have the
answer by now!
Valerie
Peter,
This was one of my points from the very beginning. But, based on most
reponses, the attitude is to wear a belt and suspenders. Nothing wrong
with that, except when IBM also takes the same stance. But, given the list
of stated conditions, it is the programmer's responsibility to code to
Workflow DB2 deadlockBenjamin
This is a persistent problem in workflow see
http://www.mqseries.net/phpBB/viewtopic.php?t=4558highlight=deadlock
and
Newsgroups: ibm.software.websphere.mqworkflow
It was supposed to be fixed in V3.3.0 SP#4 you could try moving to V3.3.2
You will probably have to
Title: RE: Running MSMQ on Server Side to MQSeries on Mainframe Side usi ng a Bridge Design Question
Glen,
Thanks again for the information you provided me.
I guess I need to say something here on how we are planning on
running before I ask any further questions.
Currently, we are
Paul, All:
Please beleive me that my preference would be not to overheat this already pretty hot
thread and just shut up and not to swim against the current. However I feel all those
arguments basically calling to ignore the official Q guarantees of the message order
under some specific
Hi,
connector.jar is in the classpath.
The readme.txt refers to connection.jar which I did not find.
Probably a typo.
If I include jta.jar in classpath then I get
java.lang.NoClassDefFoundError:javax/transaction/xa/XAException
If I exclude jta.jar then I get
java.lang.UnsatisfiedLinkError: no
To reiterate:
If possible, design so that retrieval order does not matter. If not,
design so that it does not affect the outcome.
Consolidating your request to a single message is an simple and effective
way to achieve the first goal. Just be careful not to shoot yourself in the
other foot.
with the information that I have so far, each order is independent of the other
each order has a header and a trailer, which the program relies on in the decision process
the sequence in which the orders are processed is not a factor to the design folks
however, I am sure that each store,
Whenever I have used triggering on UNIX, I have made sure the application id
was in the mqm group and the mqm id had permission to write to the
application's file systems. The reason for this was because the trigger
monitor was running under mqm and all triggered apps also ran under mqm. The
I saw where some folks make suggestions about BOF's and sessions for the next conference
I would like to see one called SCIDS
and the definition be something like I ran into the last 24 hours
Applications folks who think the glass is half full
Management who thinks the glass is half empty
Well, we run a modified version of the trigger monitor under 'root' on
Unix. We adopted a standard whereby the ENVRDATA attribute of each
Unix process description is to contain the user ID we want the process
to run under. The trigger monitor's code then runs su - ENVRDATA -c
APPLICID.
So the MQ
We have two QMs attempting to communicate over an SSL channel. QM1 has
a key ring that contains its own certificate plus QM2s self signed
certificate as a trusted site certificate. QM2 has a keyring containing
ONLY its certificate. The channel definition for QM1.QM2 (QM2 is the
server) has
31 matches
Mail list logo
