| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Hardcoding MQMD Fields |
« View previous topic :: View next topic » |
| Author |
Message
|
| nthepak |
 Posted: Mon May 21, 2007 12:18 am Post subject: Hardcoding MQMD Fields |
 |
|
Voyager
Joined: 19 Dec 2005
Posts: 79
Location: India
|
Hi All,
I want to manually set the MQMD fields for my application's business requirements. I want to know which MQMD fields other than ApplIdentityData and ApplOriginData, can be used for this purpose.
_________________
BR,
Deepak N |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon May 21, 2007 5:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
If you mean "put application data" in the MQMD, the fields you mention are really the only places you can use, and are not terribly useful. The rest are reserved for use by the system, though clearly you can set things like priority, persistence and so forth.
If you need to put data in with the message, but can't include it with the message, I'd recommend you insert an RFH2 header with the message. You can put as much stuff as you want in the <usr> folder of this header.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| tleichen |
| Posted: Tue May 22, 2007 6:28 am Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
It's really not recommended to use the header fields for your own purposes. In the earlier days of MQSeries, many people did this, only to get burned later when other features came along and clobbered what they assumed to be safe data. 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Thu May 24, 2007 1:06 pm Post subject: Re: Hardcoding MQMD Fields |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| nthepak wrote: |
| I want to manually set the MQMD fields for my application's business requirements. I want to know which MQMD fields other than ApplIdentityData and ApplOriginData, can be used for this purpose. |
Hi,
You can safely use ApplIdentityData and ApplOriginData if you want. Remember ApplIdentityData belongs to Identity Context and ApplOriginData belongs to Origin Context. Hence, you need to set the appropriate options on both the MQOPEN and MQPUT. Plus you will also need to fill in the other fields that belong to both Identity Context and Origin Context because queue manager will not since you have elected to set them.
These fields are in the MQMD for applications to use. But it requires a lot more work. Hence, most people prefer to simply put the extra data in the message body.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri May 25, 2007 7:40 am Post subject: |
|
|
Guest
|
I'd like to offer an alternate answer to the original post:
It is a best practice to use the MD (and other MQ structures and objects) as IBM intends, and as documented in the APG and APR manuals. This will pretty much guarantee transparency as we move from one version of MQ to the next.
Having said that, it is possible (a worst practice?) for applications to use or misuse fields in the MD for whatever you can imagine. Programmers have absolute control of all MD fields.
An example: if the application data component of the message can't be modified or extended, but you need to pass more data, you could make use of the msgid, correlid or other MD fields to pass the data from one program to the next. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
