| Author |
Message
|
| zpat |
 Posted: Tue Mar 24, 2009 7:21 am Post subject: |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5867
Location: UK
|
IBM defaults are incredibly important and it's unfortunate that MQSTR is not the default format because so many developers don't code it.
Which means their application is not cross-platform compatible. Of course MQGMO_CONVERT is also not the default!
I would vote to introduce for a new queue manager setting to overide the default format. Maybe some kind person will code an API exit to do this and release it as a support pac? |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Tue Mar 24, 2009 7:36 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
There is a difference and distinction between defaults and initial values.
MQ has very few defaults. Rather, it has mostly initial values. The MQMD is a good example of initial values. Refer to the APR for the table of MQMD fields and their initial values (not defaults).
When an application puts a message to a queue, it must contain an MQMD. WMQ provides a template MQMD in copybook/include files. The programmer is responsible for setting the values of MQMD fields if the initial values are not appropriate. After MQPUT, the MQMD remains as the programmer (and for some fields, the qmgr) left it. The MQMD does not revert automatically or magically to its pristine initial value state.
When an application MQGETs a message, the MQMD from the queue overwrites/overlays the MQMD in the application. It is the responsibility of the programmer to (re)set MQMD fields before the next MQGET. Again, the MQMD does not revert to its pristine initial value state.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Mar 24, 2009 7:54 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5867
Location: UK
|
OK initial values then. Which many developers untrained in MQ programming effectively default to using.
The other thing IBM need to be careful about is sample code - they make it simple as an example (leaving out proper error handling perhaps) and some developers copy it and use it in production! |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 24, 2009 7:55 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
| The other thing IBM need to be careful about is sample code - they make it simple as an example (leaving out proper error handling perhaps) and some developers copy it and use it in production! |
IBM doesn't need to be careful of that. Developers need to be careful of that. It's False Laziness. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 24, 2009 7:56 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| The other thing IBM need to be careful about is sample code - they make it simple as an example (leaving out proper error handling perhaps) and some developers copy it and use it in production! |
Not just this; the number of places using mirrorq unmodified is alarming. More alarming was the site that described it as "a support pac" 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Mar 24, 2009 8:03 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5867
Location: UK
|
| mqjeff wrote: |
| IBM doesn't need to be careful of that. Developers need to be careful of that. It's False Laziness. |
In an ideal world yes, however there is only one IBM and many untrained (in MQ terms) developers.
In fact more fully worked examples with extensive error handling would be helpful. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 24, 2009 8:07 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| IBM doesn't need to be careful of that. Developers need to be careful of that. |
Or careful of me when I do the code review. I do feel there's a case for "better" sample code.
The world being as far from ideal as it is.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Mar 24, 2009 8:11 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| OK initial values then. |
Come on! This is not secret information. This well-documented in the APR and here in this post site. This is MQ Programming 101 stuff.
As to sample code: IBM provides lots of disclaimers. The term sample code ought to be enough of a warning.
Again, the APR identifies all of the possible outcomes (as ReasonCodes) for each and every API call.
What more can (or should) IBM do? Hurl a trout at developers?!
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Mar 24, 2009 8:52 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5867
Location: UK
|
You would be surprised at how often I have come across problems caused by MQ programs being written using these initial values.
I suppose it generates work for me, but it can cause problems especially when products are coded by third-parties and we can't change them. |
|
| Back to top |
|
|
| blovell |
| Posted: Tue Mar 24, 2009 9:04 am Post subject: |
|
|
Acolyte
Joined: 08 Feb 2006
Posts: 63
Location: Alpharetta, GA
|
All,
I have just conducted a test and received different results.
Solaris MQ V 5.3
A file was placed on a QLOCAL w/o a FORMAT field populated. The Samp program AMQSGET was run and the data was pulled w/o error.
RHEL 4 MQ v7.0
A file was placed on a QLOCAL w/o a FORMAT field populated. The samp program AMQSGET was run and encountered a 2110.
While I understand the most optimal solution is to have my client correct their coding to add MQSTR, it doesn't seem feasible at this point. Obviously this hasn't become a documented problem that would result in a support pac. But I would imagine other people have encountered this issue, as mentioned not all developers code for the format field.
_________________
Bradley M. Lovell |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 24, 2009 9:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| blovell wrote: |
Solaris MQ V 5.3
A file was placed on a QLOCAL w/o a FORMAT field populated. The Samp program AMQSGET was run and the data was pulled w/o error.
|
And there's no local conversion exit supressing the error? I'm guessing this is one of the machines which used to work rather than a WMQv5.3 you had laying round?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Mar 24, 2009 9:16 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| You would be surprised at how often I have come across problems caused by MQ programs being written using these initial values. |
Oddly, I wouldn't be surprised.
Programmers are responsible for all of the data that they process, not just some of it. Not specifying explicit values is careless. Not demonstrating a basic understanding of the product (DB2 or MQ or C, whatever) is grounds for termination.
Way back when I was in charge (and responsible) for ongoing operations, I had a large rubbler mallet on my desk. It was labeled "programmer attitude adjustment mallet." It was only infrequently used, but it was effective. It left no visible signs or fish smells.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| blovell |
| Posted: Tue Mar 24, 2009 9:20 am Post subject: |
|
|
Acolyte
Joined: 08 Feb 2006
Posts: 63
Location: Alpharetta, GA
|
We have no custom code suppressing the error. It simply has no error. Below you will find the difference in the running of the SAMP program. I am running this from the old 5.3 production environment.
**One note would there be a difference in Solaris and RHEL?
v7.0
Sample AMQSGET0 start
MQGET ended with reason code 2110
message <test
>
MQGET ended with reason code 2110
message <test
>
no more messages
Sample AMQSGET0 end
v5.3
Sample AMQSGET0 start
message <test
>
message <test
>
no more messages
Sample AMQSGET0 end
_________________
Bradley M. Lovell |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 24, 2009 9:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
This clearly a bug in the behavior in v5.3, not a CHANGE in behavior for v7.
In fact, if you were to update your v5.3 to CSD14, I suspect you'd see the same "problem".
Leaving the FORMAT blank for messages that you expect to be treated as Text is the wrong thing to do.
Coding your application to fail to handle a 2110 RC is a wrong thing to do. |
|
| Back to top |
|
|
| blovell |
| Posted: Tue Mar 24, 2009 9:28 am Post subject: |
|
|
Acolyte
Joined: 08 Feb 2006
Posts: 63
Location: Alpharetta, GA
|
Jeff,
Thank you kindly That is exactly the problem we are working on. We are on an older release for v5.3. That has to be our culprit.
_________________
Bradley M. Lovell |
|
| Back to top |
|
|
|
|
