| Author |
Message
|
| Monk |
 Posted: Wed Apr 29, 2009 12:49 am Post subject: How to find which QM process loads user exits code? |
 |
|
Master
Joined: 21 Apr 2007
Posts: 282
|
Hi All,
I m using certain exits which i have written, and i wish to do runtime debugging of these exits.
since they are dynamically loaded by the queue manager process.
I want to know which queue manager process will call the exit code , so i can set break points and see whats happening.
I believe different QM process load different exits.
would be nice if someone could provide a list of that too.
thanks.
_________________
Thimk |
|
| Back to top |
|
 |
| gbaddeley |
| Posted: Wed Apr 29, 2009 5:09 pm Post subject: |
|
|
Jedi
Joined: 25 Mar 2003
Posts: 2495
Location: Melbourne, Australia
|
What type of MQ exits? Channel exits are loaded and run by the Message Channel Agent process.
Normally channel exits are coded to have debug code which is enabled by a setting in the exit data attribute of the channel. The debug code opens and writes information to a log file or the system log (or just stdout on z/OS). This has the advantage that debugging can be turned on if there are problems with the exit after it has been deployed. I've done a lot of exit programming and never dared to use breakpoint debuggers.
_________________
Glenn |
|
| Back to top |
|
|
| Monk |
| Posted: Wed Apr 29, 2009 10:09 pm Post subject: |
|
|
Master
Joined: 21 Apr 2007
Posts: 282
|
gbaddeley,
What you say is fine.
But where and which process space does the various exits run in.
is it the user process(for e.g. myMQclient.exe ) or is it some mq process(amqzla0.exe) or some other process.
if you say channel process
whats the name of the channel process.
and if the channel exits run in the channel process , i should be able to attach a debugger to the channel process and debug using breakpoint.
and which process do API exits run in?
I cant find much documentation on this in IBM site or its pdf.
if someone knows about this..please point me to it.
Thanks,
_________________
Thimk |
|
| Back to top |
|
|
| vol |
| Posted: Wed Apr 29, 2009 10:51 pm Post subject: |
|
|
Acolyte
Joined: 01 Feb 2009
Posts: 69
|
the channel process names are:
amqrmppa - channel pool process, runs all types of channels
runmqchl - individual sender channel process
runmqlsr - WMQ listener, and runs receiver and clients as threads
runmqchi - channel initiator, and runs sender channels as threads
amqcrsta - process started by inetd listener to run receiver and client channels
API exits run in the app process |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 30, 2009 12:03 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Monk wrote: |
i should be able to attach a debugger to the channel process and debug using breakpoint.
|
Do post how that works out for you. I've never had the nerve to breakpoint a qmgr process and I'd be interested to know if I've been worrying for nothing.
Having said that, I avoid exits unless there's absolutely no alternative so my experience is not extensive.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sridhsri |
| Posted: Fri May 01, 2009 7:04 pm Post subject: |
|
|
Master
Joined: 19 Jun 2008
Posts: 297
|
I completely agree with gbaddeley that great way to debug exits is to write debug statements from within an exit - to a file. However, that is not always useful. A badly written exit can crash the process before it writes the debug statements to the a file - so you wont really know where it failed.
Normally, ChannelExits create a FDC with probe id: XC130003. On UNIX based systems, you could debug such problems by causing the queue manager to hang on exception. At the time of the exception you could take a dump of the stack (For Ex: of the channel process amqrmppa) and see which method in your exit the problem occurred at. I find this far more useful than writing to a file.
There are two links that will help you achieve this:
http://www-01.ibm.com/support/docview.wss?rs=171&context=SSFKSJ&dc=DB520&uid=swg21263631&loc=en_US&cs=UTF-8&lang=en&rss=ct171websphere
[on how to hang the queue manager on exception]
http://www-01.ibm.com/support/docview.wss?fdoc=aimwmq&rs=171&uid=swg21179404
[a tool to capture the internal state of processes]
This method of debugging should work on all types of exits. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun May 03, 2009 3:45 pm Post subject: |
|
|
Jedi
Joined: 25 Mar 2003
Posts: 2495
Location: Melbourne, Australia
|
| sridhsri wrote: |
| I completely agree with gbaddeley that great way to debug exits is to write debug statements from within an exit - to a file. However, that is not always useful. A badly written exit can crash the process before it writes the debug statements to the a file - so you wont really know where it failed. |
The usual caveats apply of being careful with pointers and writing reentrant code. When developing a new exit, start out small and simple and gradually add complexity as you gain an understanding of what is going on. I've had plenty of crashed exits during development and it was usually an accidental mistake in the code. I have exits that have been running in large production systems for 10 years with no crashes.
_________________
Glenn |
|
| Back to top |
|
|
|
|
