| Author |
Message
|
| bruce2359 |
 Posted: Mon Nov 27, 2006 12:52 pm Post subject: |
 |
|
Guest
|
Hence, if persistence, priority & CCSID are under admin controlled default, why not format?
Queue attributes PERSISTENCE anf PROIRITY are NOT overrides by system admins. These are values that will be honored ONLY if the programmer specifies PERSISTENCE_AS_Q_DEF and/or PRIORITY_AS_Q_DEF in the application program. |
|
| Back to top |
|
 |
| mvic |
| Posted: Mon Nov 27, 2006 12:57 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| bruce2359 wrote: |
| Hence, if persistence, priority & CCSID are under admin controlled default, why not format? |
I don't understand the CCSID part of this... Can someone explain how, as an MQ admin, you would be able to alter the CCSID of messages being put by an app. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Nov 27, 2006 1:05 pm Post subject: |
|
|
Guest
|
Sorry. I was quoting vitor: "Hence, if persistence, priority & CCSID are under admin controlled default, why not format? " I omitted the quotes.
Sysadmins can't override what the programmer does in the program.
Queue attributes PERSISTENCE anf PROIRITY are NOT overrides by system admins. These are values that will be honored ONLY if the programmer specifies PERSISTENCE_AS_Q_DEF and/or PRIORITY_AS_Q_DEF in the application program. |
|
| Back to top |
|
|
| mvic |
| Posted: Mon Nov 27, 2006 1:17 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| bruce2359 wrote: |
| I omitted the quotes. |
Ah, I get it now. Sorry for misunderstanding. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Nov 27, 2006 2:38 pm Post subject: |
|
|
Guest
|
| mvic wrote: |
| bruce2359 wrote: |
| I omitted the quotes. |
Ah, I get it now. Sorry for misunderstanding. |
This is why sysadmins need to understand MQ application programming with MQ; AND application programmers need to understand MQ system administration. |
|
| Back to top |
|
|
| tleichen |
| Posted: Tue Nov 28, 2006 6:54 am Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
Well, I have used messages that were not MQFMT_STRING in several different companies. One good application for MQFMT_NONE is data warehousing, whereby you archive data on a different platform from which it originated. In this scenario, you don't want conversion to happen, not even by accident. IBM may have had that degree of foresight when they made that decision. 
I also worked at a place where someone wrote an MQ wrapper that did things like force-feed a format of MQFMT_STRING into every message. Sure enough, when it came time to process different kinds of messages, they were not equipped to handle it. They actually set up a unique channel and wound up writing an exit to do nothing more than change the format! 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Nov 28, 2006 7:07 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
All I'm saying (and not in any "I'm right / you're wrong" way) is that if you happen to know that you've only got one data warehouse application that stores blobs, and the rest of the messaging architecture uses strings, it would be nice to have the option of setting the default on the queue manager to string. Hence only one prgramming team would have to remember to set the Format manually and far fewer people would need to be smacked in the head, saving time and pain. I've never deliberately advocated this as anything other than an overridable default value.
If on the other hand you have a lot of data warehousing, a very mixed bag of message types or a firm belief that format is the responsibility of the application developer then you could leave the default at none and smile while you're doing it.
Advocating the power of choice here. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Nov 28, 2006 7:39 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Why would it be the job of the infrastructure to know what applications are sending and receiving?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Nov 28, 2006 7:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jefflowrey wrote: |
| Why would it be the job of the infrastructure to know what applications are sending and receiving? |
Because the applications are so decoupled they're behind Chinese firewalls? Because all applications are developed separately with no direct impact analysis on the overall data flow? Because the the data dictionary is maintained by the infrastructure team and exposed to the applications as a series of black box objects? Because one or more of the applications are 3rd party with limited support and the data stream has to be reverse engineered via the infrastructure?
I'm not pulling these examples out of thin air...
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Nov 28, 2006 7:53 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
None of those issues require moving domain specific information out of the appplication/enterprise architecture and into the infrastructure configuration.
Of course, this does assume there is an enterprise architecture.
Is it any surprise that one of the key talking points about SOA from IBM these days is "governance"?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Nov 28, 2006 7:55 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jefflowrey wrote: |
| Is it any surprise that one of the key talking points about SOA from IBM these days is "governance"? |
Not to me. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Nov 29, 2006 12:20 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5867
Location: UK
|
| bruce2359 wrote: |
| Queue attributes PERSISTENCE anf PROIRITY are NOT overrides by system admins. These are values that will be honored ONLY if the programmer specifies PERSISTENCE_AS_Q_DEF and/or PRIORITY_AS_Q_DEF in the application program. |
Not true, since these values are the MQI defaults if the application doesn't specify them explicitly!
In this case these are good defaults that allow control of the options by adjusting the queue attributes. |
|
| Back to top |
|
|
| tleichen |
| Posted: Thu Nov 30, 2006 7:47 am Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
| zpat wrote: |
| bruce2359 wrote: |
| Queue attributes PERSISTENCE anf PROIRITY are NOT overrides by system admins. These are values that will be honored ONLY if the programmer specifies PERSISTENCE_AS_Q_DEF and/or PRIORITY_AS_Q_DEF in the application program. |
Not true, since these values are the MQI defaults if the application doesn't specify them explicitly!
In this case these are good defaults that allow control of the options by adjusting the queue attributes. |
Yes, but with items like persistence, it is, more or less, a toggle; your messages are either persistent or not, so making a default is inevitable. With format, that is not the case. There are far more choices involved with message format. I really believe that when this decision was being debated, that it was clear to IBM that the application HAD TO know something about the message in order to transmit/process it. Therefore, it was decided that format would be specified by the application. Thus, MQFMT_NONE was born. Just my guess, anyway. I can't believe we've gone the distance on such a basic thing. 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Nov 30, 2006 8:30 am Post subject: |
|
|
Guest
|
zpat wrote "Not true, since these values are the MQI defaults if the application doesn't specify them explicitly! "
The application programmer MUST specify ONE of these persistence explicitly. Read the Application Programmers Reference.
For the MQPUT and MQPUT1 calls, the value must be one of the following: MQPER_PERSISTENT, MQPER_NOT_PERSISTENT, or MQPER_PERSISTENCE_AS_Q_DEF.
Failing to specify one of these will result in a put failure. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Nov 30, 2006 10:10 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5867
Location: UK
|
Have you tried it? The manual (which I have read since I like to be correct) states that the initial values of these fields is set to the AS_Q_DEF value.
I've never known anyone explicitly code a value for the message priority, not even AS_Q_DEF and their programs work just fine, since the initial values for these fields (aka defaults) are as I pointed out. |
|
| Back to top |
|
|
|
|
