Stefan
There are 2 aspects to this
1. Design for the correct sequence
2. Expected behaviour of MQSeries
If messages have to be processed in a particular sequence then coding has to
be done to ensure this. Out of the box MQ will not guarantee this. The
previously documented behaviour and restric
The CICS bridge support pack is an excellent implementation of a Service
Initiation Layer. Source code isn't provided, but 5 times out of 10 it will
do the job right out of the box. If not, the manual is pretty revealing
about the SIL design and a good model to get you started.
I am a huge advo
Stefan,
The original poster made that claim, not me. As far as what you're position
is, I concur. The network is not a factor. The messages will get there as
sent. As for MQ, it depends on whether or not the stated conditions are met
or not.
- Original Message -
From: "Stefan Sievert
Are you talking about the MQ adapter kernel - MQAK?
Just to put my five cents in on the acronym soup ;) !
Maika
--- "Brian S. Crabtree" <[EMAIL PROTECTED]> wrote:
> Narayan
>
> MQIAC is MQSeries Integrator Agent for CICS
>
http://www-3.ibm.com/software/ts/mqseries/integrator/mqiac/
>
> Even IBM
Rick,
I don't know if I have put together all the pieces of this thread correctly,
but my idea after that (and before that) is still that the physical network
is no constraint at all. I look at it from the MCA perspective: the sending
MCA doesn't even send message 2 if the receiver has received me
**
Note: This e-mail is subject to the disclaimer contained at the bottom
of this message.
**
:
GC34-6076-00 Product Overview?rather sparse on deta
Title: RE: Running MSMQ on Server Side to MQSeries on Mainframe Side using a Bridge Design Question
Glen:
Thank you very much for the information.
I would like to ask you a few follow-up questions:
1) Do you know if there has ever been any sample code posted on this
site regarding wha
Peter,
Functionally, rcvr channels are a subset of rqstr channels. If you are on
the inbound side, rqstrs give you the ability to start sdr/svr channels on
the remote node, which you cannot do with a rcvr. If you are on the
outbound side and start your sdr/svr channel you cannot distinguish bet
Narayan
MQIAC is MQSeries Integrator Agent for CICS
http://www-3.ibm.com/software/ts/mqseries/integrator/mqiac/
Even IBM doesnt seem to have documentation for this
Brian S. Crabtree
EAI Consultant
- Original Message -
From: "Narayan K Vemuri" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
When last I installed MQ on a Windows platform, there were several warnings
about the MQ id needing to query the domain account details for UserIDs.
This sounds like what you are describing. The MQ explorer had the following
information that may be relevant.
-- T.Rob
Windows 2000 domain with no
I think it is MQIAC - MQ Series Integrator. I was looking for some links or
documentation on this.
Regards
Narayan
From: "Brian S. Crabtree" <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 09/19/2002
02:29 PM AST
Please respond to "MQSeries List" <[EMAIL PROTECTED]>
Sent by: "MQSeries List" <[
Keith,
in short you have described the shortcommings of trigger type every.
if you change to trigger first, and run your current transaction, what you
would get is a single transaction for each message. but the transactions
would be effectively single threaded, and you have the possiblily of a
>Paul, I think this subject would be a good one for a seminar at the next
>Tech Conference.
Peter,
Judging by the interest it gets I think you might be right. However, I
can't see a session just on message ordering makling it through the
selection criteria. We could have a devoted session but on
jokes on me
finally found out that MSMQ has a sub title --- Bill Gates
maybe I won't spend all my time in the CICS sessions at the next Tech Conference
Dave Adam
Supervalu Home Office
Project Specialist
(952) 828-4736
[EMAIL PROTECTED]
Success is a Journey, not a Destination
>Hello All,
>My understanding is that TCP guarantees the order of bytes. For all and
every message and between messsages. As soon as a single >channel does not
open more than one simultaneous connections between same nodes -- which it
cannot do, if I am not mistaken.
>My understanding is that th
I agree with bobbee's thinking. One of the first things I tell the customer
is that MQ doesn't guarantee order out of the box in all cases, so lets
design this app to not rely on message order. If it turns out we do need
message order, there are programming ways to accomplish it. And if still we
n
Teriffic thread...
The two-queue approach is a good way to assure you don't start processing a
group of messages until all the messages in the group have been SENT. But it
does not assure that all have arrived. It assures that headers can be
processed before data. But it does not assure that head
Title: RE: retrieve order
Peter;
Bobbee is right in his response to your post. This is an issue that has
been discussed many times. Even though it is not explicitly stated
in any IBM documentation, if you ask the people who really know the internals of MQSeries, they will say:
" ... the or
Title: Running MSMQ on Server Side to MQSeries on Mainframe Side using a Bridge Design Question
I am currently trying to design a new application for MQ running MSMQ on the Server Side
and MQSeries on the Mainframe Side using a Bridge to communicate in between.
Let's say that I am writing qu
I must say we send 100's of 1000's of messages each day from an os/390 qmgr
to an RS6000 AIX qmgr and we have never experienced a message not arriving
in the 'sent sequence'. We have only have a single apps active and sending
to a queue. We never have multiple apps active and sending to the same
Paul Clarke, since you are less than 100 miles away, how would you like to drop by when you have some spare time, there are great eating places at the Mall of America, and if you can bring Chris Frank and Bob Tilton with you
this thread has been right on, even with the excerpts from the manuals
Sorry I am wrong on all accounts... Bad memory Nastel not Reconda and
Reconda has agent to pull email addresses
BUT I still think this would be a clever way to innocently get your
marketing information published - All marketing types feel free to utilize
this method but please send a small mone
Narayan
You need to give more detail but I suspect that you are asking about the
wrong product for this listserver.
MQAC is the name of the NT service for the Virtual MSMQ Server
Brian S. Crabtree
EAI Consultant
- Original Message -
From: "Narayan K Vemuri" <[EMAIL PROTECTED]>
To: <[EM
I think it was Nastel, not Reconda, that recently released the free demo
that caused "discussions" here.
Peter Potkay
IBM MQSeries Certified Specialist, Developer
[EMAIL PROTECTED]
X 77906
-Original Message-
From: Randy J Clark [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 19, 2
I get
that one too. Maybe once a month.
-Original Message-From: Dave Adam
[mailto:[EMAIL PROTECTED]]Sent: Thursday, September 19,
2002 12:50 PMTo: [EMAIL PROTECTED]Subject:
spamI just
signed up for this list yesterday since our MQ guy is no longer here
when I returned to my
I don't know.but as long as I have been in MQ, there was always the
spoken rule that no matter what you did, don't rely on the order. If you
start with that premis, then you can architect/code effectively AND with the
notion that some day some genious will come along and change your network
co
The presentations in Arlington, VA on Oct. 8 have been postponed. The new
date will be posted when set and confirmed.
The Presentations scheduled for Exton, PA are confirmed for Oct. 10. Please
see the post titled 'Delaware Valley Area NON-SALES WebSphere-Business
Integration Event - Oct. 10th,
The presentations in Waltham, MA on Oct. 2 have been postponed. The new
date will be posted when set and confirmed.
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/MQSeri
I was informed, by an person there who will remain nameless UNLESS HE SENDS
ME GOBS OF MONEY, that Reconda has an agent that runs against the digest
pulling EMAIL addresses for blanket advertisement. You got hit with it.
bobbee
>From: Dave Adam <[EMAIL P
I hate to say it but the devil in me and my nature makes me believe this
could be VERY clever way to get your companies marketing information out
while looking somewhat innocent and sparing yourself the wrath of this
list. This particular company has already felt the wrath of this list as
it rela
Hi All,
I am not sure if the above is spelled right but am sure that it is pronounced M
- Quack.
How is it different from the existing MQ workflows and if there is any
documentation
for the same.
Thanks alot in anticipation.
Regards
Narayan
Instructions for managing your mailing list subscript
Is Message Grouping available on MQSeries Version 5.3 platform z/OS?
Thanks.
-Original Message-
From: Paul Clarke [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 19, 2002 6:58 AM
To: [EMAIL PROTECTED]
Subject: Re: retrieve order
> If what you say is true, then IBM has to update it
Dave,
I personally don't think I have received that type of email, but there
are occasions when vendors including IBM becomes a little unethical and
sends product information to people on the List Server. Most individuals
on the List Server frown upon this type of marketing.
The List Server
I just signed up for this list yesterday since our MQ guy is no longer here
when I returned to my cubical world today I had the following message and was wondering if it is normal to get this stuff from this list
Dave,
I wanted to send you a personal invitation to our upcoming Webinar and in
Hello Peter,
I agree with your interpretation of "paths". wrt your question, I think you can easily
get 1,2,A,3,B,C,4 but it can be still considered "in right order" from my point of
view. Because the put order between messages 2 and A is not strictly defined so the
one can always claim the ge
Hello All,
My understanding is that TCP guarantees the order of bytes. For all and every message
and between messsages. As soon as a single channel does not open more than one
simultaneous connections between same nodes -- which it cannot do, if I am not
mistaken.
My understanding is that the
Jack,
Your rant is not misdirected. I certainly can appreciate it. But, I think
it's well understood that when data traverses a network, such as the
internet, the packets can take a variable number of routes. But, I also
believe that the MCA's ensure each other, e.g. syncpoints, that what was
There was no 3.x. You might be able to get the 2.x version from Willow
working under iBSC.
===
Bruce Olsen
System Integration Strategy and Architecture
Email: [EMAIL PROTECTED]
Phone: (727) 898-8851
Mobile: (727) 421-0865
Fax: (507) 262-1567
-Original Message-
From: MQSeries
I think it boils down to how you interpret the following line:
> For remote queuing, the configuration is such that there can only be one
> path from the application making the put request, through its queue
> manager, through intercommunication, to the destination queue manager and
> the target q
I think that the point " For remote queuing, the configuration is such that
there can only be one
path from the application making the put request, through its queue
manager, through intercommunication, to the destination queue manager and
the target queue." explains the proble. With TCP/IP netwo
Paul,
Thanks. I was wondering when IBM would speak up. I just wanted to make
sure I wasn't going crazy with my understanding of the stated requirements
for sequential retrieval.
Paul Clarke
cc:
Sent by:
Here's what the MQ Intercommunication Guide has to say:
[quote]
If an application puts a sequence of messages to the same destination queue,
those messages can be retrieved in sequence by a single application with a
sequence of MQGET operations, if the following conditions are met:
(1) All of the
We're hung up on the horns of semantics again
IBM claims (and delivers) sequential retrieval of messages "from the queue, in the
order in which they arrived...". (My words, not IBM legalese technical writing). In
other words, by default it's a FIFO (first-in-first-out) queue. There are NO
qua
The issue is does IBM need to update their doc? It makes no mention of the
physical network as a constraint in order to retrieve messages
sequentially.
RIBEIRO Paulo
JorgeTo: [EMAIL PROTECTED]
> If what you say is true, then IBM has to update its claim about
sequential
> retrieval. No where in that claims does it make exceptions due to the
> physical network. I would have thought that TCP/IP would reassemble the
> packets in their proper order regardless how they traversed the network
Rick, I think that the part below says that if they end up taking different
paths then the order can't be guaranteed:
> For remote queuing, the configuration is such that there can only be one
> path from the application making the put request, through its queue
> manager, through intercommunicat
Rebecca,
The assumption is that the requirements set by IBM are met. See extract
from IBM doc below.
"Bullock,
Rebecca (CSC)" To: [EMAIL PROTECTED]
<[EMAIL PROTECTED] cc:
G>
Please don't forget that TCP/IP networks are based on dynamic paths. If you
send msg-1,2,3, the message 1 and 3 can arrive in 10 seconds, and message 2
can take 10 hours to arrive. It is obvious that if MQ receives the message 3
before message 2, it will make it available. For the specific problem
Hi There,
Will MQSeries 2.x or 3.x work with Linux?
Thanks
Bill C.
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
Not if they don't take the same path -- Rebecca
-Original Message-
From: Rick Tsujimoto [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 19, 2002 12:09 PM
To: [EMAIL PROTECTED]
Subject: Re: retrieve order
Brian,
If the user sends msg-1, 2, 3 and gets 1, 3, 2 doesn't that conflict w
Brian,
If the user sends msg-1, 2, 3 and gets 1, 3, 2 doesn't that conflict with
the IBM doc's claim for sequential retrieval?
"Brian S.
Crabtree"To: [EMAIL PROTECTED]
Subject: Re: retriev
Rick
What you quoted doesnt conflict with what Dave said
- Original Message -
From: "Rick Tsujimoto" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 19, 2002 9:59 AM
Subject: Re: retrieve order
> Dave,
>
> If what you say is true, then IBM has to update its claim
Doesn't this say something about the physical path:
For remote queuing, the configuration is such that there can only be one
path from the application making the put request, through its queue
manager, through intercommunication, to the destination queue manager and
the target queue.
>From: Ri
Hi Stacey,
>> If I program this as a non-CICS program it works
>>fine.
Check to see if you are linking the correct stubs for
CICS.
Regards,
Ruzi
--- Patrick Scheffel <[EMAIL PROTECTED]>
wrote:
> I am on an older versions of TXSeries/MQSeries and
> using c instead of
> COBOL. Have you connecti
This is apparently a problem with TX 5.0. You are supposed to be able to
allow a 2018 and processing will continue as normal. We are going to try
that this afternoon.
Thank you for all you help.
Stacy
Instructions for managing your mailing list subscription are provided in
the Listserv Genera
I will be out of the office starting September 19, 2002 and will not return
until September 20, 2002.
I'm out of the office this afternoon. I'll get back to you first thing
tomorrow.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide availa
I am on an older versions of TXSeries/MQSeries and using c instead of
COBOL. Have you connection TXSeries to MQSeries with earlier version?
With C you do need to perform a connect to MQSeries from a TXSeries
program. Did you recompile and relink your XA switch file for MQSeries?
I past upgrade
thanks for the next question to ask
I will find out what part MS MSMQ plays in our environment
by the way we are ZOS 1.3 and MQ ver 1 on the mainframe
we are ver 5 of MQ on the client
Dave Adam
Supervalu Home Office
Project Specialist
(952) 828-4736
[EMAIL PROTECTED]
Success is a Journey, no
I like simple approaches and will keep this one in mind
not a bad way to approach something if there is not a system controlled piece
Dave Adam
Supervalu Home Office
Project Specialist
(952) 828-4736
[EMAIL PROTECTED]
Success is a Journey, not a Destination
"Falatko, Jerry (CAP, PTL)" <[
Dave,
If what you say is true, then IBM has to update its claim about sequential
retrieval. No where in that claims does it make exceptions due to the
physical network. I would have thought that TCP/IP would reassemble the
packets in their proper order regardless how they traversed the network.
Since
you cannot use the grouping feature, you can use an alternative solution, based
on the Msg Id/Correl ID values of the messages. You can search for some posts in
this forum where you have all the solution completely
described.
Paulo
-Original Message-From: Dave Adam
[mailto:
Dave,
We had
a similar situation.
To get
around it we used an effective, albeit rather in-elegant
solution.
We now
use two Queues:
a Trigger Queue and
a Data Queue
Basically, we send all of our pieces of data as messages to
our Data Queue.
Then
we send a summary message (including cou
I've already spoken with IBM on this, and was told that since MQ5.3 was a
major revision, and all the updates to documentation were merged into the
appropriate books, there is no separate Release Guide. The reference is an
error in the Quick Beginnings Guide. I still have a PMR open with them on
Dave,
This is an indication that you are sending across a "dynamically routed"
network, like the Internet.
Since congestion may cause the messages to take different path through the
network, they may
arrive in the receiving system in a different order.
This is the purpose of Messages Groups
we have a system that sent a message
header
data
data
trailer
and came into the mainframe program as
header
data
trailer
data
is this a common thing,
or should the receiving program be intelligent enough to figure out what should have been
oh, by the way, some times they say they get duplic
Stefan,
I always thought and was told that that little guy is the one that moves the
pointer in the log every 1000 messages, or when it can. I did not read this
I was told this. So don't load your gun if I'm wrong!!
bee-oh-dubble-bee-dubble-eegghh
>From: Stefan Sievert
Stacy,
Somebody had mentioned this in a prior reply. Under normal OS390 CICS there
is no such thing as a HCONN. (CICS handles the connection to the MQSeries
manager and you access that through the CIC adapter) If you specify one in
the executing program it comes back zero valued as I believe you a
hi joe..
Check if your Inet deamon is running fine on
the HP box and if there is a normal established
TCP/IP connection between these 2 boxes.
Also worth noting would be the parameters on the
firewall if any with regard to the connection
timeout parameters etc.
Just a few thoughts from whatev
68 matches
Mail list logo
