| Author |
Message
|
| bobbee |
 Posted: Fri Sep 14, 2012 4:45 am Post subject: AMQSAXE0 modification for control |
 |
|
Knight
Joined: 20 Sep 2001
Posts: 545
Location: Tampa
|
I would like to modify my modified AMQSAXE0 to stop and start printing loggin information dynamically. My idea, unless there is a better one, is it to attempt to read a file named STOPTRACE in some directory. The appearance of this file would stop trace printing. It would be nice to turn off the exit all together. I believe the entry point for all the APIs (MQPUT, MQGET, etc) are what is called. This, I assume, would require me to put a read of a file in each procedure, whic would also mean that every API call, before and after, may try to open a file for read. VERY messy and costly. Any suggestions and do I have this wrong. Would be nice if you could issue a 'kill -1' and this thing would get a signal.
Again, I would like to turn it off dynamically, they current option is to stop and start the QMGR. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri Sep 14, 2012 5:42 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| You could use a background thread to look for the file, and then have each API call check to see if the background thread has set a variable that indicates "stop". |
|
| Back to top |
|
|
| bobbee |
| Posted: Fri Sep 14, 2012 6:12 am Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 545
Location: Tampa
|
| That is a nice approach, sort of like how to do disconnected MQGETs on z/OS sort of Post/Wait. I will start looking on how to do the implementation of a background thread and the verification of the status. THANKS!! |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Sep 14, 2012 8:38 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Another way would be to use a specific control message to turn the logging on/off. Whenever the exit sees the control message it does the switch according to the command.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bobbee |
| Posted: Sat Sep 15, 2012 2:40 am Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 545
Location: Tampa
|
| So I implemented the IF_EXISTS file code up in the EntryPoint section of the code. This will work for turning off all new processes that come into the exit. That is semi ok. How do you introduce the control message to the EntryPoints for the individual API's. I would suspect you would have some receiver process that sets global switches the API exit point can see. Do you have a link to an example so I can see what it is like. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Sep 15, 2012 7:07 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Sorry no examples. Just a theoretical remark. I suppose in order to log the exit has access to the message content. Now you could construct a message with a specific value in the MQMD format field and a command that would be honored by the exit.... This might still need to refer to some kind of switch that needs to be persisted on the File System to be reloaded at each channel startup. But would allow to avoid the disk hit checking for each message.... and allow for dynamic flip without a file system hit. Make sure you persist the switch value whenever the channel closes. I'd expect the exit would get a channel closure event? Or write the change to the file system in an asynchronous thread when ever the change occurs....
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bobbee |
| Posted: Sat Sep 15, 2012 1:04 pm Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 545
Location: Tampa
|
| Nice suggestion, I have to do some reading and understand the API Exit a little more, I would suspect the exit code gets called and the process parameters are passed to it. So as you said, there will have to be 'some' global or persistent data retained in state for the exits to access across all cals. Some analysis and design work ahead. Thanks for the suggestion. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Sep 18, 2012 3:22 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
|
| Back to top |
|
|
| bobbee |
| Posted: Tue Sep 18, 2012 3:48 pm Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 545
Location: Tampa
|
| well, three years ago I built it. Have used it at a few customers to unearth issues where the customer has not learned how to spell M-O-N-I-T-O-R-I-N-G. Ends up making a STRONG argument to as why they do need it. Monitoring that is. But that is a really good attempt at salesmanship. Hats off to you Roger. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Sep 18, 2012 4:18 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hello bobbee,
More of a "food for thought" item. I write MQ exits for all sorts of things in MQ and I can say hands-down, dealing with multi-processes and multi-threads within an API Exit is absolutely the most complex programming that I do.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| bobbee |
| Posted: Tue Sep 18, 2012 4:47 pm Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 545
Location: Tampa
|
| you have my EMAIL, send me a link to the propaganda on your MQ Auditor. They may be interested. I would certainly pass any info to them that would get me off these marathon conference calls do to issues late at night!!!! |
|
| Back to top |
|
|
|
|
