| Author |
Message
|
| phil parry |
 Posted: Tue Apr 14, 2009 6:25 am Post subject: Impact 2009 - MQI |
 |
|
Newbie
Joined: 20 Jan 2009
Posts: 7
|
Hello
Those of you attending Impact http://www-01.ibm.com/software/websphere/events/impact2009/?S_TACT=108AU73W&S_CMP=default next month may be interested to know that we will be running some feedback sessions that were inaugurated last year and which were highly successful.
This year, Morag and I will be running sessions aimed at understanding customers' use of the MQI, so if you feel like taking part, you'll be very welcome!
Thanks
Phil Parry |
|
| Back to top |
|
 |
| kevinf2349 |
| Posted: Tue Apr 14, 2009 7:46 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
Phil
Are there any plans to canvas those that can't get to Impact?
My company has forbidden any travel to conferences etc due the economic climate (or at least that is what they are blaming) and so I suspect have many other companies.
Why not use the open a discussion here too and get worldwide input? |
|
| Back to top |
|
|
| shashikanth_in |
| Posted: Tue Apr 14, 2009 7:39 pm Post subject: |
|
|
Centurion
Joined: 26 Feb 2009
Posts: 123
|
| I too agree, we can open a discussion here. |
|
| Back to top |
|
|
| phil parry |
| Posted: Fri Apr 17, 2009 5:50 am Post subject: Feedback |
|
|
Newbie
Joined: 20 Jan 2009
Posts: 7
|
Good idea - let's hear it.
But if you are able to attend these MQI Feedback sessions at Impact, it would be every useful if you could give some thought between now and then on:
- what sort of mistakes you make?
- what do you forget to do?
- what is missing?
- how should the Reference Guides be improved?
Ask your colleagues who aren't able to attend Impact. Bring stuff to show us.
If you know and love the MQI, or maybe you hate it, this will be your chance to tell us what you think and how current and future users could be helped.
Regards
Phil |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Apr 17, 2009 6:07 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I find that developers forget to set MQMD.Format = MQFMT_STRING on MQPUT and forget to use MQGMO_CONVERT on MQGET
All our messages are string data (mainly XML or CWF).
The IBM defaults mean that when they test MQ comms on their own PC it works fine but breaks when anything of a different code page crosses platforms later on in the development cycle.
I suppose ideally it would be possible to override the MQI defaults based on queue settings like one can with default persistence.
Developers often forget to report MQRC values and it would be great to have an easy way to trace the MQI calls and their reason codes. If there was a trace table automatically maintained by the queue manager of the last few hundred MQI calls it would often be very useful to view this.
If non-zero MQI reason codes could be optionally logged in the event log (perhaps based on a queue setting) it would help debugging.
Automatic backout requeueing based on backout requeue name and threshold would be nice to have. Disconnect interval on SVRCONN channels (non-Z/OS).
Add a MQI option to remove RFH2 headers on MQGET if they are present.
Above all I would like to see some really complete examples of MQI programs (adapters) with full use of reconnection logic (for client connections), error handling, get waits, syncpointing and all the other best practises that are usually not found in the example code provided. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Apr 17, 2009 7:42 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Why in the world is MQ*_FAIL_IF_QUIESCING not the default? If an application wants to prevent the QM from stopping, let them ask for it explicitly, not default to it!
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Apr 17, 2009 7:50 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| zpat wrote: |
| I find that developers forget to set MQMD.Format = MQFMT_STRING on MQPUT and forget to use MQGMO_CONVERT on MQGET. |
Just like MQ*_FAIL_IF_QUIESCING, another option I think that IBM has incorrect defaults for. The vast majority of MQ data is char data, so the default should be MQFMT_STRING.
| zpat wrote: |
Developers often forget to report MQRC values and it would be great to have an easy way to trace the MQI calls and their reason codes. If there was a trace table automatically maintained by the queue manager of the last few hundred MQI calls it would often be very useful to view this.
If non-zero MQI reason codes could be optionally logged in the event log (perhaps based on a queue setting) it would help debugging.
Above all I would like to see some really complete examples of MQI programs (adapters) with full use of reconnection logic (for client connections), error handling, get waits, syncpointing and all the other best practises that are usually not found in the example code provided. |
Please do this. I'm so tired of " MQ didn't give me a RC." or "Here it is." and they send me a JMS code.
| zpat wrote: |
Above all I would like to see some really complete examples of MQI programs (adapters) with full use of reconnection logic (for client connections), error handling, get waits, syncpointing and all the other best practises that are usually not found in the example code provided. |
I second that. Something better than the samples. A complete program for a ficticious app, with lots of comments and explanations as to why things are coded they way they are. It would be great to point to this and say "This is the right way. Now go code little developer, code. Like you've never coded before!"
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| shashikanth_in |
| Posted: Tue Apr 21, 2009 7:18 pm Post subject: No more environment variables for MQI |
|
|
Centurion
Joined: 26 Feb 2009
Posts: 123
|
| There are many system environment variables that MQI uses, for example MQCHLTAB. MQI should avoid adding new environment variables. It should provide a way to set them programatically. For example, allowing setting of CCDT file names via MQCNO. |
|
| Back to top |
|
|
|
|
