Re: Use channel exits or not?

2004-03-23 Thread Potkay, Peter M (PLC, IT)



Is
this something that you will need always from this point forward, or is this a
one time deal just to get an idea?
 
If all
you want to know is how long name resolution takes place on the MQ Hub this one
time, I would do the following:
 
Do
this off hours.
Create
a new channel into the Hub, and a new channel out of the
hub.
STOP
the channel into the Hub.
Preload the XMIT queue feeding the channel into the Hub with 100,000
persistent messages of an average size for your shop.
Record
the time and start the channel. When the last message finally resolves thru the
hub and the depth hits 100,000 on the other side, record the
time.
 
Subtract the 2 times, and divide by 100,000. Your answer is the average
time that a message took to get through the hub.
 
 
Sorry
if I keep shying away from answering your exit questions. One I don't know the
first thing about exits, and 2, if there is a simple, not so glamorous way to
get an answer, why not? :-)
 
 
 

  -Original Message-From: Kulbir S. Thind
  [mailto:[EMAIL PROTECTED]Sent: Tuesday, March 23, 2004 12:51
  PMTo: [EMAIL PROTECTED]Subject: Re: Use channel
  exits or not?Gentlemen,
  A few points: 
  
The timings are captured on the hub and there is
only a single hub so we shouldn't have any issues.  
We want to use circular logs as they are easier
to maintain.  
By "shared channel exit" I'm suggesting that we
have a channel exit created and make a physical copy of it for each channel
instance that we have.  Is this approach going to give us better
performance and be safer?  Does it require more resources rather than
having a single channel exit (i.e. dll) that is used by all channel
instances?Cheers,
  Kulbir. 
  


  
  "Rick Tsujimoto"
<[EMAIL PROTECTED]> Sent by: "MQSeries List"
<[EMAIL PROTECTED]>
23-Mar-2004 15:04 Please respond to "MQSeries List"
<[EMAIL PROTECTED]> 
                       
                  To:      
 MQSERIES    
        cc:                 Subject:  
     Re: Use channel exits or
  not?If the timings
  are captured on different boxes, and the machine clocks arenot
  synchronized, then you could have some interesting
  results."David
  C.Partridge"                 To:
       [EMAIL PROTECTED]<[EMAIL PROTECTED]  
        cc:RIMEUR.COM>          
       Subject: Re: Use channel exits or not?Sent by:
  MQSeriesList<[EMAIL PROTECTED].AC.AT>
  03/23/2004 08:23AMPlease respond
  toMQSeries List Additional comments:Acquire
  the storage for you structure at MQXR_INIT time, and store thepointer in
  MQCXP.ExitUserArea.Make sure that you
  release the storage and clear the pointer at
  MQXR_TERMtime.Do whatever processing
  you need at MQXR_MSG time (you'll probably want toknow whether the message
  is inbound or outbound on the channel - look atMQCD.ChannelType to
  determine what type of channel this is.DaveInstructions for managing
  your mailing list subscription are provided inthe Listserv General Users
  Guide available at http://www.lsoft.comArchive:
  http://vm.akh-wien.ac.at/MQSeries.archiveInstructions for managing your mailing list subscription are
  provided inthe Listserv General Users Guide available at
  http://www.lsoft.comArchive:
  http://vm.akh-wien.ac.at/MQSeries.archive


This communication, including attachments, is for the exclusive use of 
addressee and may contain proprietary, confidential or privileged 
information. If you are not the intended recipient, any use, copying, 
disclosure, dissemination or distribution is strictly prohibited. If 
you are not the intended recipient, please notify the sender 
immediately by return email and delete this communication and destroy all copies.




Re: Use channel exits or not?

2004-03-23 Thread Kulbir S. Thind

Gentlemen, 

A few points:


The timings are captured on the hub and there
is only a single hub so we shouldn't have any issues.  
We want to use circular logs as they are
easier to maintain.  
By "shared channel exit" I'm suggesting
that we have a channel exit created and make a physical copy of it for
each channel instance that we have.  Is this approach going to give
us better performance and be safer?  Does it require more resources
rather than having a single channel exit (i.e. dll) that is used by all
channel instances?
Cheers,

Kulbir.








"Rick Tsujimoto" <[EMAIL PROTECTED]>

Sent by: "MQSeries List" <[EMAIL PROTECTED]>
23-Mar-2004 15:04
Please respond to "MQSeries List"
<[EMAIL PROTECTED]>
        
         
              

        To:
       MQSERIES

        cc:
       
        Subject:
       Re: Use channel exits or not?


If the timings are captured on different boxes, and
the machine clocks are
not synchronized, then you could have some interesting results.




"David C.
Partridge"                
To:      [EMAIL PROTECTED]
<[EMAIL PROTECTED]         cc:
RIMEUR.COM>                Subject:
Re: Use channel exits or not?
Sent by: MQSeries
List
<[EMAIL PROTECTED]
.AC.AT>


03/23/2004 08:23
AM
Please respond to
MQSeries List





Additional comments:

Acquire the storage for you structure at MQXR_INIT
time, and store the
pointer in MQCXP.ExitUserArea.

Make sure that you release the storage and clear the
pointer at MQXR_TERM
time.

Do whatever processing you need at MQXR_MSG time (you'll
probably want to
know whether the message is inbound or outbound on the channel - look at
MQCD.ChannelType to determine what type of channel this is.

Dave

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: Use channel exits or not?

2004-03-23 Thread David C. Partridge
Indeed so! :-)

Dave

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: Use channel exits or not?

2004-03-23 Thread Rick Tsujimoto
If the timings are captured on different boxes, and the machine clocks are
not synchronized, then you could have some interesting results.




  "David C.
  Partridge" To:  [EMAIL PROTECTED]
  <[EMAIL PROTECTED] cc:
  RIMEUR.COM>    Subject: Re: Use channel exits or not?
  Sent by: MQSeries
  List
  <[EMAIL PROTECTED]
  .AC.AT>


  03/23/2004 08:23
  AM
  Please respond to
  MQSeries List





Additional comments:

Acquire the storage for you structure at MQXR_INIT time, and store the
pointer in MQCXP.ExitUserArea.

Make sure that you release the storage and clear the pointer at MQXR_TERM
time.

Do whatever processing you need at MQXR_MSG time (you'll probably want to
know whether the message is inbound or outbound on the channel - look at
MQCD.ChannelType to determine what type of channel this is.

Dave

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: Use channel exits or not? [Deutsche Boerse Systems:Virus checked]

2004-03-23 Thread Stefan . Raabe

Kulbir, 

my exit is on os/390, its written in assembler and the number of channels it is used in is about 20, so i am afraid
i have to stop giving hints at this point because your environment differs too much (and i am not a unix guru).
Using an exit in 600 channels (or 200) could maybe be a mess. i also do not understand what you mean by
"shared channel exit" . if you put in a channel exit, it is used by each mca, but every mca has its own data... ?!?
or do you want to create the same program with a different name for each channel ?!?

hard to recommend anything for me. i would try to go for an "offline" solution, like using linear logs which are analyzed
later i know there are some third party log tools around.

Regards, Stefan







"Kulbir S. Thind" <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>
23.03.2004 12:31
Please respond to MQSeries List

        
        To:        [EMAIL PROTECTED]
        cc:        (bcc: Stefan Raabe/DBS/GDB)
        Subject:        Re: Use channel exits or not? [Deutsche Boerse Systems:Virus              checked] [Deutsche Boerse Systems:Virus checked]

.



Stefan, 

We will be developing on Windows and using this in production on Sun Solaris.   

Also, would you share the same channel exit across channels or have separate instances on each channel?  We may have up to 600 channels in total connected to 3 queue managers on the hub.  We're worried about sharing a channel exit across so many instances and ensuring that the handles do not get mixed up with one another.  Are we better off just having multiple instances of the same channel exit or should we go for a shared channel exit?  What is safer, better for performance?  Also, does having multiple channel exits effect resource requirements? 

Thanks for your assistance, 

Kulbir. 





[EMAIL PROTECTED] 

Sent by: "MQSeries List" <[EMAIL PROTECTED]> 
23-Mar-2004 10:52 
Please respond to "MQSeries List" <[EMAIL PROTECTED]> 
        
                        

        To:        MQSERIES 

        cc:         
        Subject:        Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked] [Deutsche Boerse Systems:Virus checked]




Kulbir,   

persistent messages are in the log, so log analysis may still be an approach, but (again) hard to implement. 

using the applidentity data to match incoming and outgoing message will work, but you must be sure it is not used anywhere else in the application and 
you must be sure the value you put in there is unique. 

if the exit is written properly there should be no data loss.  if the exit is in error in most cases the 
channel terminates or does not start. 

you can also tune your exit e.g. by keeping your workarea (allocate at channel start, free at channel end, keep and 
pass address in exituserarea) to minimize performance impact (depending on OS and programming language). 

in my statistic exit, i also set a bit if i detect an error during processing (e.g. channel statistic queue full), and - if 
called again - i check this bit first. if previous error, i leave the exit immediate. this will result in the loss of 
my statistic data, but the error will not impact message flow. 

what operating system is used for the hub? 

regards, stefan 







"Kulbir S. Thind" <[EMAIL PROTECTED]> 
Sent by: MQSeries List <[EMAIL PROTECTED]> 

23.03.2004 11:03 
Please respond to MQSeries List 
          
        To:        [EMAIL PROTECTED] 
        cc:        (bcc: Stefan Raabe/DBS/GDB) 
        Subject:        Re: Use channel exits or not? [Deutsche Boerse Systems:Virus              checked] [Deutsche Boerse Systems:Virus checked] 
.




Stefan, 

Thanks for the response.  Unfortunately because of the validated environment we work in (Pharmaceutical regulations) we need to use persistent messages no matter what approach we take.  We will match the incoming messages with the outgoing messages by using the ApplIdentityData field in the MQMD, we cannot use the MsgId field and CorrelId fields as the MsgId field is definitely being used by the applications and the CorrelId field may be already being used or can be used in the future.  The channel exit will modify the incoming message to allocate a value for the ApplIdentityData field, I believe if you code the channel exit correctly you can ensure you have no message loss, do you agree? 

Cheers, 

Kulbir. 



  



[EMAIL PROTECTED] 

Sent by: "MQSeries List" <[EMAIL PROTECTED]>   

23-Mar-2004 09:32 
Please respond to "MQSeries List" <[EMAIL PROTECTED]>   
        
                        

       To:        MQSERIES 

       cc:         
       Subject:        Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked]





Kulbir, 

are the messages persistent? mayby a log analysis could be an approach (just an idea, but i think 
this well be hard to implement be

Re: Use channel exits or not?

2004-03-23 Thread David C. Partridge
Each instance of a channel exit can hang any structures (or control blocks)
that it needs to maintain state across invocations in MQCXP.ExitUserArea
(store a pointer in here).   You can store in this structure any hconn (n.b.
you'll get MQRC_ALREADY_CONNECTED when you do the MQCONN, so just remember
that you DO NOT do an MQDISC in this case) and any hobj's that you need (for
writing to your audit queue e.g.).

Therefore each instance of a channel exit is isolated from other instances
even in a threaded channel model as in MQ 5.3 using the shared channel
agent - just make sure your code is naturally re-entrant and don't store
stuff between invocations anywhere but in the control block you store the
pointer to in MQCXP.ExitUserArea (put another way don't use static variables
or expect stack variables to hang around).

Cheers
Dave Partridge

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: Use channel exits or not?

2004-03-23 Thread David C. Partridge
Additional comments:

Acquire the storage for you structure at MQXR_INIT time, and store the
pointer in MQCXP.ExitUserArea.

Make sure that you release the storage and clear the pointer at MQXR_TERM
time.

Do whatever processing you need at MQXR_MSG time (you'll probably want to
know whether the message is inbound or outbound on the channel - look at
MQCD.ChannelType to determine what type of channel this is.

Dave

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: Use channel exits or not? [Deutsche Boerse Systems:Virus checked] [Deutsche Boerse Systems:Virus checked]

2004-03-23 Thread Kulbir S. Thind

Stefan,

We will be developing on Windows and using
this in production on Sun Solaris.  

Also, would you share the same channel exit
across channels or have separate instances on each channel?  We may
have up to 600 channels in total connected to 3 queue managers on the hub.
 We're worried about sharing a channel exit across so many instances
and ensuring that the handles do not get mixed up with one another.  Are
we better off just having multiple instances of the same channel exit or
should we go for a shared channel exit?  What is safer, better for
performance?  Also, does having multiple channel exits effect resource
requirements?

Thanks for your assistance,

Kulbir.






[EMAIL PROTECTED]

Sent by: "MQSeries List" <[EMAIL PROTECTED]>
23-Mar-2004 10:52
Please respond to "MQSeries List"
<[EMAIL PROTECTED]>
        
         
              

        To:
       MQSERIES

        cc:
       
        Subject:
       Re: Use channel exits or not? [Deutsche
Boerse Systems:Virus checked] [Deutsche Boerse Systems:Virus checked]



Kulbir,  

persistent messages are in the log, so log analysis may
still be an approach, but (again) hard to implement.


using the applidentity data to match incoming and outgoing
message will work, but you must be sure it is not used anywhere else in
the application and 
you must be sure the value you put in there is unique.


if the exit is written properly there should be no data
loss.  if the exit is in error in most cases the

channel terminates or does not start.


you can also tune your exit e.g. by keeping your workarea
(allocate at channel start, free at channel end, keep and

pass address in exituserarea) to minimize performance
impact (depending on OS and programming language).


in my statistic exit, i also set a bit if i detect an
error during processing (e.g. channel statistic queue full), and - if

called again - i check this bit first. if previous error,
i leave the exit immediate. this will result in the loss of
my statistic data, but the error will not impact message
flow. 

what operating system is used for the hub?


regards, stefan 








"Kulbir S. Thind" <[EMAIL PROTECTED]>

Sent by: MQSeries List <[EMAIL PROTECTED]>


23.03.2004 11:03
Please respond to MQSeries List 

         
        To:        [EMAIL PROTECTED]

        cc:        (bcc:
Stefan Raabe/DBS/GDB) 
        Subject:      
 Re: Use channel exits or not? [Deutsche Boerse Systems:Virus  
           checked] [Deutsche Boerse Systems:Virus
checked] 
.



Stefan, 

Thanks for the response.  Unfortunately because of
the validated environment we work in (Pharmaceutical regulations) we need
to use persistent messages no matter what approach we take.  We will
match the incoming messages with the outgoing messages by using the ApplIdentityData
field in the MQMD, we cannot use the MsgId field and CorrelId fields as
the MsgId field is definitely being used by the applications and the CorrelId
field may be already being used or can be used in the future.  The
channel exit will modify the incoming message to allocate a value for the
ApplIdentityData field, I believe if you code the channel exit correctly
you can ensure you have no message loss, do you agree?


Cheers, 

Kulbir. 



 



[EMAIL PROTECTED]


Sent by: "MQSeries List" <[EMAIL PROTECTED]>
 

23-Mar-2004 09:32 
Please respond to "MQSeries List" <[EMAIL PROTECTED]>
 
        
               
       

       To:        MQSERIES


       cc:        

       Subject:      
 Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked]




Kulbir, 

are the messages persistent? mayby a log analysis could
be an approach (just an idea, but i think 
this well be hard to implement because log details are
not known to the "normal" mq users). 

i use a channel exit in a similiar situation, i wanted
to be able to see what messages 
(target queue, target queuemanager) are passing the channels
that are connected to 
a gateway queuemanager (sending and receiving ends).

i do not record the messages itself, but take some values
(target queue, target 
qmgr,  channel name, put time, application name,
...)  to build a statistic message 
which is put into a statistic queue. thisqueue is triggered
by depth and copied 
to a flat file by a small REXX procedure (all on os/390).

analyzing the statistic messages in the flat file i am
able to see what messages   
passed the gateway, i am also able to compute the time
a message takes 
from creation (put time of the message) till passing the
gateway queuemanager 
(put time of the statistic message).

the statistic messages are non persistent, to minimise
performance impact. 

no matter what kind of measuring you will implement, it
will cost you some performance anyway. 
i prefer the exit solution because i do not have to touch
the application, and - if written  
properly  - there should be no message loss, because

Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked] [Deutsche Boerse Systems:Virus checked]

2004-03-23 Thread Stefan . Raabe

Kulbir, 

persistent messages are in the log, so log analysis may still be an approach, but (again) hard to implement.

using the applidentity data to match incoming and outgoing message will work, but you must be sure it is not used anywhere else in the application and
you must be sure the value you put in there is unique.

if the exit is written properly there should be no data loss.  if the exit is in error in most cases the
channel terminates or does not start.

you can also tune your exit e.g. by keeping your workarea (allocate at channel start, free at channel end, keep and
pass address in exituserarea) to minimize performance impact (depending on OS and programming language).

in my statistic exit, i also set a bit if i detect an error during processing (e.g. channel statistic queue full), and - if
called again - i check this bit first. if previous error, i leave the exit immediate. this will result in the loss of
my statistic data, but the error will not impact message flow.

what operating system is used for the hub?

regards, stefan








"Kulbir S. Thind" <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>
23.03.2004 11:03
Please respond to MQSeries List

        
        To:        [EMAIL PROTECTED]
        cc:        (bcc: Stefan Raabe/DBS/GDB)
        Subject:        Re: Use channel exits or not? [Deutsche Boerse Systems:Virus              checked] [Deutsche Boerse Systems:Virus checked]

.



Stefan, 

Thanks for the response.  Unfortunately because of the validated environment we work in (Pharmaceutical regulations) we need to use persistent messages no matter what approach we take.  We will match the incoming messages with the outgoing messages by using the ApplIdentityData field in the MQMD, we cannot use the MsgId field and CorrelId fields as the MsgId field is definitely being used by the applications and the CorrelId field may be already being used or can be used in the future.  The channel exit will modify the incoming message to allocate a value for the ApplIdentityData field, I believe if you code the channel exit correctly you can ensure you have no message loss, do you agree? 

Cheers, 

Kulbir. 







[EMAIL PROTECTED] 

Sent by: "MQSeries List" <[EMAIL PROTECTED]> 
23-Mar-2004 09:32 
Please respond to "MQSeries List" <[EMAIL PROTECTED]> 
        
                        

        To:        MQSERIES 

        cc:         
        Subject:        Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked]




Kulbir, 

are the messages persistent? mayby a log analysis could be an approach (just an idea, but i think 
this well be hard to implement because log details are not known to the "normal" mq users). 

i use a channel exit in a similiar situation, i wanted to be able to see what messages 
(target queue, target queuemanager) are passing the channels that are connected to 
a gateway queuemanager (sending and receiving ends). 
i do not record the messages itself, but take some values (target queue, target 
qmgr,  channel name, put time, application name, ...)  to build a statistic message 
which is put into a statistic queue. thisqueue is triggered by depth and copied 
to a flat file by a small REXX procedure (all on os/390). 
analyzing the statistic messages in the flat file i am able to see what messages   
passed the gateway, i am also able to compute the time a message takes 
from creation (put time of the message) till passing the gateway queuemanager 
(put time of the statistic message). 
the statistic messages are non persistent, to minimise performance impact. 

no matter what kind of measuring you will implement, it will cost you some performance anyway. 
i prefer the exit solution because i do not have to touch the application, and - if written 
properly  - there should be no message loss, because you do not manipulate the 
message data, just get some values and leave the message as it is. 

Whats the plattform for the Hub? if you use a channel exit, how will you match the incoming and 
outgoing message (will they have the same MSGID , same message data, ?!?) 

Regards, Stefan 







"Kulbir S. Thind" <[EMAIL PROTECTED]> 
Sent by: MQSeries List <[EMAIL PROTECTED]> 

22.03.2004 23:33 
Please respond to MQSeries List 
          
        To:        [EMAIL PROTECTED] 
        cc:        (bcc: Stefan Raabe/DBS/GDB) 
        Subject:        Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked] 
.




Hi Peter, 

Thanks for this but I'm afraid that may be the question was not clear enough.  We have existing applications that will connect to a new broker.  We wanted to implement channel exits on the broker for the receiving channels from the applications and the sending channels to the applications, this was so we could record how long the messages are taking to get processed in the WBI MB flows on the hub.  We have a constraint on us that w

Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked]

2004-03-23 Thread Kulbir S. Thind

Stefan,

Thanks for the response.  Unfortunately
because of the validated environment we work in (Pharmaceutical regulations)
we need to use persistent messages no matter what approach we take.  We
will match the incoming messages with the outgoing messages by using the
ApplIdentityData field in the MQMD, we cannot use the MsgId field and CorrelId
fields as the MsgId field is definitely being used by the applications
and the CorrelId field may be already being used or can be used in the
future.  The channel exit will modify the incoming message to allocate
a value for the ApplIdentityData field, I believe if you code the channel
exit correctly you can ensure you have no message loss, do you agree?

Cheers,

Kulbir.








[EMAIL PROTECTED]

Sent by: "MQSeries List" <[EMAIL PROTECTED]>
23-Mar-2004 09:32
Please respond to "MQSeries List"
<[EMAIL PROTECTED]>
        
         
              

        To:
       MQSERIES

        cc:
       
        Subject:
       Re: Use channel exits or not? [Deutsche
Boerse Systems:Virus checked]



Kulbir, 

are the messages persistent? mayby a log analysis could
be an approach (just an idea, but i think 
this well be hard to implement because log details are
not known to the "normal" mq users). 

i use a channel exit in a similiar situation, i wanted
to be able to see what messages 
(target queue, target queuemanager) are passing the channels
that are connected to 
a gateway queuemanager (sending and receiving ends).

i do not record the messages itself, but take some values
(target queue, target 
qmgr,  channel name, put time, application name,
...)  to build a statistic message 
which is put into a statistic queue. thisqueue is triggered
by depth and copied 
to a flat file by a small REXX procedure (all on os/390).

analyzing the statistic messages in the flat file i am
able to see what messages  
passed the gateway, i am also able to compute the time
a message takes
from creation (put time of the message) till passing the
gateway queuemanager 
(put time of the statistic message).

the statistic messages are non persistent, to minimise
performance impact. 

no matter what kind of measuring you will implement, it
will cost you some performance anyway. 
i prefer the exit solution because i do not have to touch
the application, and - if written 
properly  - there should be no message loss, because
you do not manipulate the 
message data, just get some values and leave the message
as it is. 

Whats the plattform for the Hub? if you use a channel
exit, how will you match the incoming and 
outgoing message (will they have the same MSGID , same
message data, ?!?) 

Regards, Stefan








"Kulbir S. Thind" <[EMAIL PROTECTED]>

Sent by: MQSeries List <[EMAIL PROTECTED]>


22.03.2004 23:33
Please respond to MQSeries List 

         
        To:        [EMAIL PROTECTED]

        cc:        (bcc:
Stefan Raabe/DBS/GDB) 
        Subject:      
 Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked]

.



Hi Peter, 

Thanks for this but I'm afraid that may be the question
was not clear enough.  We have existing applications that will connect
to a new broker.  We wanted to implement channel exits on the broker
for the receiving channels from the applications and the sending channels
to the applications, this was so we could record how long the messages
are taking to get processed in the WBI MB flows on the hub.  We have
a constraint on us that we are not allowed to change the application platforms
or deploy new applications on to them. 

We wanted to use channel exits as it meant no change to
the flows that we are migrating over and we believed the channel exits
would give us the best performance.  The channel exits would also
give us a more accurate timing as it would take into account the time in
the flows as well as time on the MQSeries queues on the hub.  However,
we were put off by a couple of statements that were made:
 


this will degrade channel performance
 
an error in the exit could cause message loss


The alternatives to the channel exit design given our
constraints are:  

Use a message get MQ exit  
Use a stand-alone program  
Add a metrics node into the message flow.



The main problems with the above approaches are that they
will not give us a true indication of the amount of time the messages have
spent in a hub.  My other concerns are that the alternative approaches
will not provide better performance than using channel exits.
 I would like to get peoples views on the two negative comments regarding
use of channel exits and advise on what they would do and why to achieve
what we want to do. 



Cheers, 



Kulbir. 




 



"Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]>


Sent by: "MQSeries List" <[EMAIL PROTECTED]>
 

22-Mar-2004 19:23 
Please respond to "MQSeries List" <[EMAIL PROTECTED]>
 
        
               
       

  

Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked]

2004-03-23 Thread Stefan . Raabe

Kulbir,

are the messages persistent? mayby a log analysis could be an approach (just an idea, but i think
this well be hard to implement because log details are not known to the "normal" mq users).

i use a channel exit in a similiar situation, i wanted to be able to see what messages
(target queue, target queuemanager) are passing the channels that are connected to
a gateway queuemanager (sending and receiving ends).
i do not record the messages itself, but take some values (target queue, target
qmgr,  channel name, put time, application name, ...)  to build a statistic message
which is put into a statistic queue. thisqueue is triggered by depth and copied
to a flat file by a small REXX procedure (all on os/390).
analyzing the statistic messages in the flat file i am able to see what messages 
passed the gateway, i am also able to compute the time a message takes
from creation (put time of the message) till passing the gateway queuemanager
(put time of the statistic message).
the statistic messages are non persistent, to minimise performance impact.

no matter what kind of measuring you will implement, it will cost you some performance anyway.
i prefer the exit solution because i do not have to touch the application, and - if written
properly  - there should be no message loss, because you do not manipulate the
message data, just get some values and leave the message as it is.

Whats the plattform for the Hub? if you use a channel exit, how will you match the incoming and
outgoing message (will they have the same MSGID , same message data, ?!?)

Regards, Stefan








"Kulbir S. Thind" <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>
22.03.2004 23:33
Please respond to MQSeries List

        
        To:        [EMAIL PROTECTED]
        cc:        (bcc: Stefan Raabe/DBS/GDB)
        Subject:        Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked]

.



Hi Peter, 

Thanks for this but I'm afraid that may be the question was not clear enough.  We have existing applications that will connect to a new broker.  We wanted to implement channel exits on the broker for the receiving channels from the applications and the sending channels to the applications, this was so we could record how long the messages are taking to get processed in the WBI MB flows on the hub.  We have a constraint on us that we are not allowed to change the application platforms or deploy new applications on to them. 

We wanted to use channel exits as it meant no change to the flows that we are migrating over and we believed the channel exits would give us the best performance.  The channel exits would also give us a more accurate timing as it would take into account the time in the flows as well as time on the MQSeries queues on the hub.  However, we were put off by a couple of statements that were made: 

this will degrade channel performance 
an error in the exit could cause message loss

The alternatives to the channel exit design given our constraints are: 

Use a message get MQ exit 
Use a stand-alone program 
Add a metrics node into the message flow.


The main problems with the above approaches are that they will not give us a true indication of the amount of time the messages have spent in a hub.  My other concerns are that the alternative approaches will not provide better performance than using channel exits.  I would like to get peoples views on the two negative comments regarding use of channel exits and advise on what they would do and why to achieve what we want to do. 

Cheers, 

Kulbir. 






"Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> 

Sent by: "MQSeries List" <[EMAIL PROTECTED]> 
22-Mar-2004 19:23 
Please respond to "MQSeries List" <[EMAIL PROTECTED]> 
        
                        

        To:        MQSERIES 

        cc:         
        Subject:        Re: Use channel exits or not?




Application connects to QMSpoke1. 
QMSpoke1 hosts a RemoteQueueA, pointing at RemoteQueueB, which lives on QMHub. 
RemoteQueueB on QMHub points back at LocalQueue1 on SpokeQM1. 
  
  
Application connects to QMSpoke1, and Opens RemoteQueueA for putting, and opens LocalQueue1 for getting. 
Put a message into RemoteQueueA. 
Record the time. 
Application immediatly MQGets from LocalQueue1. 
Record the time. 
  
Subtract the two times, and you have the amount of time a message takes to get thru the hub. Yes it includes time spent on the channels, but that is relevant. Put both QMs on the same box, and have your channels already running to eliminate these variables as much as possible. 
  
  
Do the test again by changing RemoteQueueA to point right to LocalQueue1 to see what a difference there is if you eliminate the channel/HUB hops. 
  
  
  
  
-Original Message- 
From: Kulbir S. Thind [mailto:[EMAIL PROTECTED] 
Sent: Monday, March 22, 2004 2:00 PM 
To: [EMAIL PROTECTED] 
Subject: Use channel exi

Re: Use channel exits or not?

2004-03-22 Thread Kulbir S. Thind

Hi Peter,

Thanks for this but I'm afraid that may be
the question was not clear enough.  We have existing applications
that will connect to a new broker.  We wanted to implement channel
exits on the broker for the receiving channels from the applications and
the sending channels to the applications, this was so we could record how
long the messages are taking to get processed in the WBI MB flows on the
hub.  We have a constraint on us that we are not allowed to change
the application platforms or deploy new applications on to them.

We wanted to use channel exits as it meant
no change to the flows that we are migrating over and we believed the channel
exits would give us the best performance.  The channel exits would
also give us a more accurate timing as it would take into account the time
in the flows as well as time on the MQSeries queues on the hub.  However,
we were put off by a couple of statements that were made:


this will degrade channel performance

an error in the exit could cause message loss
The alternatives to the channel exit design given our
constraints are:


Use a message get MQ exit
Use a stand-alone program
Add a metrics node into the message flow.

The main problems with the above approaches are that they
will not give us a true indication of the amount of time the messages have
spent in a hub.  My other concerns are that the alternative approaches
will not provide better performance than using channel exits.
 I would like to get peoples views on the two negative comments regarding
use of channel exits and advise on what they would do and why to achieve
what we want to do.

Cheers,

Kulbir.







"Potkay, Peter M (PLC, IT)"
<[EMAIL PROTECTED]>

Sent by: "MQSeries List" <[EMAIL PROTECTED]>
22-Mar-2004 19:23
Please respond to "MQSeries List"
<[EMAIL PROTECTED]>
        
         
              

        To:
       MQSERIES

        cc:
       
        Subject:
       Re: Use channel exits or not?



Application connects to QMSpoke1.
QMSpoke1 hosts a RemoteQueueA, pointing at RemoteQueueB,
which lives on QMHub.
RemoteQueueB on QMHub points back at LocalQueue1 on SpokeQM1.
 
 
Application connects to QMSpoke1, and Opens RemoteQueueA
for putting, and opens LocalQueue1 for getting.
Put a message into RemoteQueueA.
Record the time.
Application immediatly MQGets from LocalQueue1.
Record the time.
 
Subtract the two times, and you have the amount of time
a message takes to get thru the hub. Yes it includes time spent on the
channels, but that is relevant. Put both QMs on the same box, and have
your channels already running to eliminate these variables as much as possible.
 
 
Do the test again by changing RemoteQueueA to point right
to LocalQueue1 to see what a difference there is if you eliminate the channel/HUB
hops.
 
 
 
 
-Original Message-
From: Kulbir S. Thind [mailto:[EMAIL PROTECTED]
Sent: Monday, March 22, 2004 2:00 PM
To: [EMAIL PROTECTED]
Subject: Use channel exits or not?



Hi, 

We are planning on having a hub and spoke architecture
that will see 100's of applications connect into the WBI MB hub we will
implement.  We have a requirement to be able to determine the amount
of time that the messages have spent in the hub.  We thought we would
do this by implementing some auditing functionality using channel exits
to copy the messages to another destinations as it arrives and as it leaves.
  

We have had some worrying comments regarding using channel
exits for this purpose, these comments are: 


this will degrade channel performance

an error in the exit could cause message loss

The alternatives to this approach are as follows:



Use a message get MQ exit
Use a stand-alone program
Add a metrics node into the message flow.

The main problems with the above approach are that they
will not give us a true indication of the amount of time the messages have
spent in a hub.  My other concerns are that the alternative approaches
will not provide better performance than using channel exits.


Would anyone like to comment on this?


Cheers, 

Kulbir.

This communication, including attachments, is for the
exclusive use of 
addressee and may contain proprietary, confidential or
privileged 
information. If you are not the intended recipient, any
use, copying, 
disclosure, dissemination or distribution is strictly
prohibited. If 
you are not the intended recipient, please notify the
sender 
immediately by return email and delete this communication
and destroy all copies.



Re: Use channel exits or not?

2004-03-22 Thread Potkay, Peter M (PLC, IT)



Application connects to QMSpoke1.
QMSpoke1 hosts a RemoteQueueA, pointing at RemoteQueueB, which lives
on QMHub.
RemoteQueueB on QMHub points back at LocalQueue1 on
SpokeQM1.
 
 
Application
connects to QMSpoke1, and Opens RemoteQueueA for putting, and opens LocalQueue1
for getting.
Put a message
into RemoteQueueA.
Record the time.
Application immediatly MQGets from
LocalQueue1.
Record the time.
 
Subtract the two times, and you have the amount of time
a message takes to get thru the hub. Yes it includes time spent on the channels,
but that is relevant. Put both QMs on the same box, and have your channels
already running to eliminate these variables as much as
possible.
 
 
Do the test again by changing RemoteQueueA to point
right to LocalQueue1 to see what a difference there is if you eliminate the
channel/HUB hops.
 
 
 
 

  -Original Message-From: Kulbir S. Thind
  [mailto:[EMAIL PROTECTED]Sent: Monday, March 22, 2004 2:00
  PMTo: [EMAIL PROTECTED]Subject: Use channel exits
  or not?Hi,
  We are planning on having a hub and spoke
  architecture that will see 100's of applications connect into the WBI MB hub
  we will implement.  We have a requirement to be able to determine the
  amount of time that the messages have spent in the hub.  We thought we
  would do this by implementing some auditing functionality using channel exits
  to copy the messages to another destinations as it arrives and as it leaves.
    We have had some worrying
  comments regarding using channel exits for this purpose, these comments
  are: 
  
this will degrade channel performance
an error in the exit could cause message
lossThe alternatives to this
  approach are as follows: 
  
Use a message get MQ exit
Use a stand-alone program
Add a metrics node into the message
flow.The main problems with the
  above approach are that they will not give us a true indication of the amount
  of time the messages have spent in a hub.  My other concerns are that the
  alternative approaches will not provide better performance than using channel
  exits. Would anyone like to comment on
  this? Cheers, Kulbir.

This communication, including attachments, is for the exclusive use of 
addressee and may contain proprietary, confidential or privileged 
information. If you are not the intended recipient, any use, copying, 
disclosure, dissemination or distribution is strictly prohibited. If 
you are not the intended recipient, please notify the sender 
immediately by return email and delete this communication and destroy all copies.




Use channel exits or not?

2004-03-22 Thread Kulbir S. Thind

Hi,

We are planning on having a hub and spoke
architecture that will see 100's of applications connect into the WBI MB
hub we will implement.  We have a requirement to be able to determine
the amount of time that the messages have spent in the hub.  We thought
we would do this by implementing some auditing functionality using channel
exits to copy the messages to another destinations as it arrives and as
it leaves.  

We have had some worrying comments regarding
using channel exits for this purpose, these comments are:


this will degrade channel performance
an error in the exit could cause message
loss
The alternatives to this approach are as
follows:


Use a message get MQ exit
Use a stand-alone program
Add a metrics node into the message flow.
The main problems with the above approach
are that they will not give us a true indication of the amount of time
the messages have spent in a hub.  My other concerns are that the
alternative approaches will not provide better performance than using channel
exits.

Would anyone like to comment on this?

Cheers,

Kulbir.