ile. +61 414 615 334
Bill Anderson
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
TA.AERO> cc:
Sent by: MQSeries Subject: Program Design Question
List
Bill,
Why not trigger the get application, allow it to
perform mqgets with a tuned timeout, say 5-10 secs. -
all the while doing mqput1s per inbound message? Will
this application ever do a put without an input from a
get? Are there any unit of work considerations?
Chris
--- Bill Anderson <[E
Situation:
A client application is required to open two queues for each and every
customer using its service. One open on the queue it receives messages from
(MQGET) and one open on the queue it writes messages back to the customer
on (MQPUT). The get is done with an unlimited wait, which if memor
will do what
I expect.
Darren
-Original Message-
From: Jim Ford [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 23 December 2003 10:08 AM
Subject: Re: Triggering Design Question
I think that I'll use a combination of a few suggestions. I'll:
1. Define the Solaris queue to trigger
.CANON.COM>cc:
Sent by: MQSeries List Subject: Re: Triggering
Design Question
<[EMAIL PROTECTED]>
12/22/2003 02:01 PM
Please respond to MQSeries
t you have in
mind. You may want to "externalize" the name of the qremote in trigdata
for additional flexibility.
Regards
dennis
-Original Message-
From: Jim Ford [mailto:[EMAIL PROTECTED]
Sent: Monday, December 22, 2003 10:41 AM
To: [EMAIL PROTECTED]
Subject: Triggering Des
/2003 02:26 PM
Please respond to "MQSeries
List"
To:
[EMAIL PROTECTED]
cc:
Subject:
Re: Triggering Design Question
How would I use COA?
Randy J Clark
<[EMAIL
our shop's standard for interacting with job schedulers.
Jim Ford
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
OM> cc:
Sent by: Subject:
List Subject: Triggering Design Question
<[EMAIL PROTECTED]
.AT>
12/22/03 01:40 PM
Please respond to
MQSeries List
I got an interesti
[EMAIL PROTECTED]
.CANON.COM>cc:
Sent by: MQSeries List Subject: Re: Triggering
Design Question
<[EMAIL PROTECTED]>
12/22/2003 01:08 PM
How would I use COA?
Randy J Clark
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
HONDA.COM> cc:
Sent by: MQSeriesSubject: Re: Triggering Design Qu
gering Design Question
List
<[EMAIL PROTECTED]
N.AC.AT>
12/22/2003 10:40
AM
Please respond to
MQSeries List
I got an interesting trigge
[EMAIL PROTECTED]
OM> cc:
Sent by: Subject: Triggering Design Question
MQSeries List
<[EMAIL PROTECTED]
en.AC.AT>
12/22/2003 01:
duler.
Naturally you will need the attachment facility on the OS390
bobbee
From: Jim Ford <[EMAIL PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Triggering Design Question
Date: Mon, 22 Dec 2003 12:40:51 -0600
I got an interesting trigge
p to OS/390, where our trigger
monitor would process it and demand in the job. But as soon as I got going
on it I remembered condition 8 for triggering. That is, in order to
generate a trigger message the initq queue must be opened for input. And
that's impossible in this design.
Ho
T.Rob
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, November 10, 2003 4:47 PM
To: [EMAIL PROTECTED]
Subject: Re: Triggering across New Cluster not working - Design
Suggestion
G'Day T. Rob,
A sequence number is encoded in the data file, when the client
ome up with as there are so many
clever people on this list.
Sid
-Original Message-
From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 11 November 2003 4:54 AM
To: [EMAIL PROTECTED]
Subject: Re: Triggering across New Cluster not working - Design
Suggestion
You are
, or if it failed and
your GETs/PUTs were backed out.
-- T.Rob
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, November 07, 2003 5:47 PM
To: [EMAIL PROTECTED]
Subject: Triggering across New Cluster not working - Design Suggestion
Yep, everyone'
PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Triggering across New Cluster not working - Design Suggestion
Date: Sun, 9 Nov 2003 12:05:24 -0500
Man I wish we could white board this!
Are you saying that the process that needs to be trigge
er 08, 2003 7:30 PM
To: [EMAIL PROTECTED]
Subject: Re: Triggering across New Cluster not working - Design
Suggestion
Robert and Peter (and anyone else who is interested).
You are kind of on the right track, some definitions:
A "site" is some remote internet connected location, ie a Ho
Bob,
I don't use reply queues as such, but you are basically on the right track.
Sid
-Original Message-
From: Robert Broderick [mailto:[EMAIL PROTECTED]
Sent: Sunday, 9 November 2003 4:18 AM
To: [EMAIL PROTECTED]
Subject: Re: Triggering across New Cluster not working - Design
Sugge
Managed
solutions ) has no real Linux support despite what they say in their add's.
-Original Message-
From: Pavel Tolkachev [mailto:[EMAIL PROTECTED]
Sent: Sunday, 9 November 2003 6:40 AM
To: [EMAIL PROTECTED]
Subject: Re: Triggering across New Cluster not working - Design
Suggest
PROTECTED]
Sent by: MQSeriescc:
List Subject: Re: Triggering across New
Cluster not working - Design Suggestion
<[EMAIL PROTECTED]
n.AC.AT>
11/07/2003 11:4
TED]
Subject: Re: Triggering across New Cluster not working - Design Suggestion
Date: Sat, 8 Nov 2003 14:43:54 +1000
"can you restate your actual problem from an application perspective?"
Peter, In a nut shell
I have 600+ clients that connect into our queue manager to transfer
encrypted m
on
naming convention.
That's about it:)
Sid
-Original Message-
From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]
Sent: Saturday, 8 November 2003 2:30 PM
To: [EMAIL PROTECTED]
Subject: Re: Triggering across New Cluster not working - Design
Suggestion
Sid, can you restate
: Triggering across New Cluster not working - Design
Suggestion
Isn't this one of the intentions of clustering. To do work load and to some
degree failover balancing. If you have more than one server where the
message are designed to be routed to you solve your problem of scaling. If
one of the destin
ne doesn't
build a house. At least you have determined the pit falls of your design at
an early stage. With some re-thought and pinging ideas off the LISTSERV you
will eventually come up with a system that can take a punch or two.
Father Bobbee
From: [EMAIL PROTECTED]
Reply-To: MQSeri
Yep, everyone's comments are valid... I re-read the Queue Manger Cluster
manual again last night and found a one liner on the limitation of MQGET
just a single line ( and not a mention in any of the other manuals as far as
I can see so far).
I find this a serious limitation for my design
[SMTP:[EMAIL PROTECTED]
> Sent: Thursday, July 31, 2003 7:31 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Design Review - custom trigger monitor vs triggered program
>
> Pavel
>
> Maybe I'm just being a little think here, but I'm not understanding how
> rem
y 30, 2003 10:46 AM|
| | Please respond to MQSeries List |
| | |
|-+--->
>|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
Interesting thought...but then we're not triggering applications any more and we
really don't want the native trigger monitor in the fray. The original design amounts
to an attempt to trigger-start a trigger monitor. Cannot do.
> -Original Message-
> From: [EMAIL
gt;
07/30/2003 08:17 AM
Please respond to MQSeries List
To: [EMAIL PROTECTED]
cc:
Subject: Re: Design Review - custom trigger monitor vs triggered program
Thanks Don!
I thought I was the only one and so was keeping the embarassed silence :-
To: [EMAIL PROTECTED]
<[EMAIL PROTECTED]cc:
RIMEUR.COM> Subject: Re: Design Review - custom
trigger monitor vs triggered program
Sent by: MQSeries
List
<[E
OTECTED]cc:
RIMEUR.COM> Subject: Re: Design Review - custom
trigger monitor vs triggered program
Sent by: MQSeries
List
<[EMAIL PROTECTED]
.AC.AT>
Sent by: MQSeries Subject: Re: Design Review - custom
trigger monitor vs triggered program
List
<[EMAIL PROTECTED]
n.AC.AT>
07/30/2003 08:43
AM
;venal" is possibly arguable (I'd go for deadly myself).
Dave
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Pavel
Tolkachev
Sent: 30 July 2003 14:18
To: [EMAIL PROTECTED]
Subject: Re: Design Review - custom trigger monitor vs triggered program
Th
OM> cc:
Sent by: MQSeries Subject: Re: Design Review - custom
trigger monitor vs triggered program
List
<[EMAIL PROTECTED]
n.AC.AT>
PROTECTED]
-Original Message-
From: Heggie, Peter [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 11:17 AM
To: [EMAIL PROTECTED]
Subject: Design Review - custom trigger monitor vs triggered program
Hello all - would appreciate your responses on this one.
We have someone who wants to use a cust
AM
To: [EMAIL PROTECTED]
Subject: Re: Design Review - custom trigger monitor vs triggered program
Oh NO It's the "Consultants are always right" syndrone. (Even when
they are wrong.) This is giving me a bad name!!! (More than I usually do
for myself). This looks like a jo
(sorry I couldn't resist!!)
bobbee
From: "Heggie, Peter" <[EMAIL PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Design Review - custom trigger monitor vs triggered program
Date: Tue, 29 Jul 2003 15:01:01 -0400
Sorry for blan
it will not work (see also dennis post). the design
is definitly wrong.
that should be strong enough to change it.
regards
stefan
-Ursprungliche Nachricht-
Von: Heggie, Peter [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 29. Juli 2003 21:01
An: [EMAIL PROTECTED]
Betreff: Re: Design
PROTECTED]
Subject: Re: Design Review - custom trigger monitor vs triggered program
Peter,
what is your design rationale for having multiple initiation queues?
Stefan
>From: "Heggie, Peter" <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL
Peter Heggie
(315) 428 - 3193
-Original Message-
From: Stefan Sievert [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 2:51 PM
To: [EMAIL PROTECTED]
Subject: Re: Design Review - custom trigger monitor vs triggered program
Peter,
what is your design rationale for having multiple
Sorry about the blank response(s); I seem to have fat fingers today.
First, assuming your design would work, I cannot tell that it accomplishes anything
useful. What is your customer's aim?
You said>
Because program XYZ has the init queue open, MQ will not invoke another instance of
Peter,
what is your design rationale for having multiple initiation queues?
Stefan
From: "Heggie, Peter" <[EMAIL PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Design Review - custom trigger monitor vs triggered program
Date: Tue
t the design was to call for more
trigger monitors (to monitor other initiation queues..). The
recommendation was to set the application queue triggering to EVERY, but
I think FIRST would be better.
And Stefan, thank you also, I agree that triggering while already
triggered does not make sense, and so
> -Original Message-
> From: Heggie, Peter [SMTP:[EMAIL PROTECTED]
> Sent: Tuesday, July 29, 2003 8:17 AM
> To: [EMAIL PROTECTED]
> Subject: Design Review - custom trigger monitor vs triggered program
>
> Hello all - would appreciate your responses on t
To: [EMAIL PROTECTED]
NGRID.COM> cc:
Sent by: MQSeriesSubject: Design Review - custom
trigger monitor vs triggered program
List
<[EMAIL PROTECTED]
n.AC.AT>
er monitor.
Regards, Stefan
-Ursprungliche Nachricht-
Von: Heggie, Peter [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 29. Juli 2003 17:17
An: [EMAIL PROTECTED]
Betreff: Design Review - custom trigger monitor vs triggered program
Hello all - would appreciate your responses on this one.
We ha
Hello all - would appreciate your responses on this one.
We have someone who wants to use a custom trigger monitor to both read
the init queue message and process the application queue message. It
would be a long running process, on AIX, that waits forever (loops) on
the init queue. When a message
nt that is usually used or recommended by IBM
to capture all configuration details of various Mq objects like the MQ objects like
queue managers, cluster info ,queues processdef etc, especially for complex design and
setup.
May be something similar to the one in intercomm , but that is only for ch
Hi ,
Is there a standard format for a document that is usually used or recommended by IBM to capture all configuration details of various Mq objects like the MQ objects like queue managers, cluster info ,queues processdef etc, especially for complex design and setup.
May be something similar to
ied Developer - WMQI (MQSeries v5.2)
781-363-3474 http://www.ICnowledge.com
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Instructions for managing your mailing list subscription are pr
TIm A
[EMAIL PROTECTED]
.AU To: [EMAIL PROTECTED]
Sent by: MQSeriescc:
List Subject: Need feedback on Design idea
<[EMAIL P
Title: Message
Howdy
all,
I need to implement
a server application that routes decrypted data to (one of) a range of
queues (there could be 100's of target queues).
The remote clients
will be sending data (encrypted) to a single queue. The decryption application
is triggered to collect f
ed to me by its officials
> than to the one signed by Verisign or similar that I
> received bundled with my browser. Very much IMHO, of
> course.
>
> Hope this will help,
> Pavel
>
>
>
>
>
>
> Vitaliy Ilyin
>
I want to weigh into this discussion with a couple of practices that we
use that have worked well for us.
(1) We use multiple queue managers on a server because we run
multiple environments on a server. We tend to put our production and
training environments on the same server and our deve
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re
HOO.COM> cc:
Sent by: MQSeriesSubject: Re: MQ Design Query # Repost
List
<[EMAIL PROTECTED]
n.AC.AT>
07/17/2003 01:13
AM
Hi Neil,
Thank you for your reply
1 The question is: if you interact with the external
clients/vendors is it enough to have the self-signed
certificates or would it be required (and a good
practise) to go to the external CA?
Thanks,
Vitaliy
__
Do you Yahoo!?
SBC
Pavel,
Thank you for your reply. It's not the first time by
the way ;-).
Now,
2) Yes, you see I guess I didn't phrase my question
correctly/specifically enough. I was asking not about
CAs (even though they are also called certificate
management systems) but about the way you would manage
100s or
ionable MQ infrastructure design
Try to debug a service oriented at 3:00AM when all you got is a queue name
to go on and your critical financial start-of-day application is getting a
bad data enima and your application SME has had enough of his/her crappy job
and busted the batteries out of their beepe
The PC term is now PUREST!!! (hahahahahaha)
From: Rick Tsujimoto <[EMAIL PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Questionable MQ infrastructure design
Date: Tue, 15 Jul 2003 12:17:14 -0400
tsk tsk tsk...just l
ucture design
List
<[EMAIL PROTECTED]
.AC.AT>
07/15/2003 12:00
PM
Please respond to
MQSeries List
Aliases!! YuckWhat a depl
Aliases!! YuckWhat a deplorable thing!!
From: Rick Tsujimoto <[EMAIL PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Questionable MQ infrastructure design
Date: Tue, 15 Jul 2003 09:24:24 -0400
Isn't that why
eeffe, Michael
Sent: Tuesday, July 15, 2003 9:29 AM
To: [EMAIL PROTECTED]
Subject: Re: Questionable MQ infrastructure design
Thanks to everybody for the ideas on this - I wasn't aware that you could
use parallel channels and xmitqs.
The documents we are processing are similar to Jim's. The
little guy - hence the +70MB range,
although most are <5MB). We didn't have much leeway with the back-end
system, the original design called for FTPing a directory of documents and
images to our server, however the assured delivery of MQ seemed like a good
fit since this was a fee based ser
y: MQSeries Subject: Re: Questionable MQ
infrastructure design
List
<[EMAIL PROTECTED]
.AC.AT>
07/15/2003 07:09
AM
Please respond to
MQSer
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
AHOO.COM>cc:
Sent by: Subject: Re: Questionable MQ
infrastructure design
MQSeries List
<[EMAIL PR
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
HOO.COM> cc:
Sent by: MQSeriesSubject: Re: MQ Design Query # Repost
List
<[EMAIL PROTEC
Before I zip up my lips are you eating Beet Borscht and watching TV
T?
ZPPP!
From: Vitaliy Ilyin <[EMAIL PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: MQ Design Query # Repost
Date: Mon, 14 Jul 2
ooned with the
process of figuring out what the problem. And also from experience it isn't
the MSTER of names that will take the heat for the application /
infrasturcture not working.
We do a better job if we design and NAME system that are a little less
abstract and a lot more realistic. I know
>you need a personal certificate (MQ does not seem to use Server type
>certificates at all).
Hmmm I accept that it will work with a Verisign Class 1 certificate.
The question is how much trust you are prepared to put in a certificate
where the process of identification is only "does the reque
|
| Subject: Re: MQ Design Query # Repost
|
>--|
Dear colleges,
HI
I have couple questi
Dear colleges,
HI
I have couple questions for you (after 3 Gin ad
Tonics);-), B-lo-o-o-be-e-e, you keep quite this time,
please.
1) Did anyone have any experiences with managing large
number of SSL certificates: both client-side and
server-side?
2) Is there any vendor's produ
quot;O'Keeffe, Michael" <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 07/14/2003
09:25:45 PM
Please respond to MQSeries List <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Re: MQ Design Query
a. Yes. You don't
ECTED]
> Sent: 14 July 2003 12:15
> To: [EMAIL PROTECTED]
> Subject: Re: Questionable MQ infrastructure design
>
>
> The Queue name I push when we a developing
> infrastructure is
> SendingApp.ReceivingApp.AnythingYouWant
>
> Channels are generic-ly Sender.Receiver with
&g
I find it intriguing how similar people think and
what's even more intersting is that IT IS difficult to
think out of the box.
We MQ people seem to think from the MQ perspective. If
you take one step back (or aside) you would agree that
even though from MQ perspective it makes sense to send
small d
etc.
"Kelly, Steve"
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
EQUEST.COM> cc:
Sent by: MQSeries Subject: Re: Questionable MQ
infrastructure design
PROTECTED]
Sent: 14 July 2003 16:34
To: [EMAIL PROTECTED]
Subject: Re: Questionable MQ infrastructure design
Here's another twist to this QM subject: what about a system which sends
varying messages over MQ? Most messages are simple 2k request-reply, but
when a customer requests a document
astructure design
The Queue name I push when we a developing infrastructure is
SendingApp.ReceivingApp.AnythingYouWant
Channels are generic-ly Sender.Receiver with variations considered for
multiple QMGRS on the same box and testing cyclye (eg SandBox, Dev, SIT,
UAT, QA
I assume that when you say "document" you mean something like an IDOC?
Using MQ for data this big can give you all sorts of problems, but one thing
you can do is to use multiple channels with different TQs etc, so that your
large messages don't block the small guys. I don't think you need to go
4, 2003 4:52 AM
To: [EMAIL PROTECTED]
Subject: MQ Design Query
Hi all,
We have the following design requirement to be satisfied between NT &
OS/390.
Application running on Windows NT performing a MQGET from a queue in
windows/NT & needs
to update a DB2 database in OS/390. The whole
ect: Re: Questionable MQ
infrastructure design
<[EMAIL PROTECTED]
AT>
07/14/2003 11:34 AM
Please respond to
MQSeries List
Here's another twist to this QM subject: what ab
riority for the document messages?
-Mike
-Original Message-
From: Vitaliy Ilyin [mailto:[EMAIL PROTECTED]
Sent: Friday, July 11, 2003 6:10 PM
To: [EMAIL PROTECTED]
Subject: Re: Questionable MQ infrastructure design
I've seen a lot of responses to thisone which is
actually very ineres
)
bobbee
From: [EMAIL PROTECTED]
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Questionable MQ infrastructure design
Date: Sun, 13 Jul 2003 18:01:36 +1000
Hi,
We have a similar name scheme for channels except much shorter S
Hi all,
We have the following design requirement to be satisfied between NT & OS/390.
Application running on Windows NT performing a MQGET from a queue in windows/NT &
needs
to update a DB2 database in OS/390. The whole operations needs to be performed in a
single unit of work (i.e
infrastructure design
Hi all,
For an integration project I have been asked to adopt an MQ naming standard
that reflects a very unusual approach in MQ-based integration. I have never
seen this approach before and have serious concerns in adopting any of it.
Key in the design is the use of separate
ll,
> For an integration project I have been asked to
> adopt an MQ naming standard
> that reflects a very unusual approach in MQ-based
> integration. I have never
> seen this approach before and have serious concerns
> in adopting any of it.
>
> Key in the design is the use of s
ou
unless you change your naming convention to more L
mikhail malamud
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
.NET>cc:
Sent by: MQSeriesSubject: Re: Questionable
MAIL PROTECTED]
> Subject: Questionable MQ infrastructure design
>
> Hi all,
> For an integration project I have been asked to adopt an MQ naming standard
> that reflects a very unusual approach in MQ-based integration. I have never
> seen this approach before and have seriou
PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Thursday, July 10, 2003 8:31 AM
To: [EMAIL PROTECTED]
Subject: Re: Questionable MQ infrastructure design
First off, channel names are restricted to 20 characters, not 48 like all
other MQ object names. Having so many queue managers on a single machine
|
| cc:
|
| Subject: Questionable MQ infrastructure design
|
>--|
Hi all,
be on the same host. This is
hardly justifiable over head.
- Original Message -
From: "Armand ten Dam" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 09, 2003 8:58 PM
Subject: Questionable MQ infrastructure design
| Hi all,
| For an integration pr
icult than it needs to be. Are
they trying to insure job security for the person that builds this??? ;-).
-Original Message-
From: Armand ten Dam [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2003 8:58 PM
To: [EMAIL PROTECTED]
Subject: Questionable MQ infrastructure design
H
Hi all,
For an integration project I have been asked to adopt an MQ naming standard
that reflects a very unusual approach in MQ-based integration. I have never
seen this approach before and have serious concerns in adopting any of it.
Key in the design is the use of separate queue managers for
Hi,
Has anyone seen any object modeling or data modeling tools or methodologies
that incorporate or support MQSeries or MQSI?
I have seen UML symbols for queues, but nothing automated. It would be
feasible to go from a MQ network diagram to runmqsc commands just as some
data modeling tools go fr
Yes, use a compute node to set destination, route to label and label nodes.
Regards
Tim A
vinay_tiwari
cc:
Sent by: MQSeriesSubject: Message Flow design Issue
List
| cc:
|
| Subject: Message Flow
Hi,
I have
an application which updated 12 different databases based on a field in the
request xml.I get one xml as an input message to the system and
then]
I have
to split various blocks baised on location tags into 12 separate message and
then route them to 12 different oracle databases
1 - 100 of 115 matches
Mail list logo
