| Author |
Message
|
| ggriffith |
 Posted: Tue Nov 11, 2008 6:59 am Post subject: Application Identity not being written to MQMD |
 |
|
Acolyte
Joined: 17 Oct 2007
Posts: 67
|
| Anybody had problems when trying to write the application ID in V61 in a SLES 10 environment ( MQ 6.0.2). Works ok on a SLES 9 system. but that may be a red herring. MQOutput node has the message context set to 'Set All'. The message is being written to the queue but the Appl ID is blank. |
|
| Back to top |
|
 |
| ggriffith |
| Posted: Tue Nov 11, 2008 7:39 am Post subject: |
|
|
Acolyte
Joined: 17 Oct 2007
Posts: 67
|
| Now the problem has turned into a nightmare. It's fixed itself without me doing anything. Not what you want with production cutover to 6.1 looming very close. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Nov 11, 2008 7:54 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
This option just sets the MQPMO_SET_ALL_CONTEXT on the MQPUT.
Either you didn't atually deploy the flow with this setting, or you supplied a blank applid in the message flow logic.
I don't think that it's likely that MQ suddenly decided to work properly. |
|
| Back to top |
|
|
| ggriffith |
| Posted: Tue Nov 11, 2008 8:09 am Post subject: |
|
|
Acolyte
Joined: 17 Oct 2007
Posts: 67
|
Don't you think I checked that first before posting this topic. 
But I do agree, I would think it very unlikely that MQ should suddenly start working properly all by itself. Having said that, all I did was add a trace node to try to find out whats happening. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Nov 11, 2008 9:02 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
|
| Back to top |
|
|
| ggriffith |
| Posted: Tue Nov 11, 2008 9:19 am Post subject: |
|
|
Acolyte
Joined: 17 Oct 2007
Posts: 67
|
Yes, but no different to the previous deploy when I added an extra MQOutput ( which captuted the message with a blank ApplId,).
We have had this once before with 6.1, which was sorted by a redeployment, but it's a bit worrying that it's returned and this time it's taken 3, 4 or 5 deployments to correct the problem ( I've been trying various things to find out what's happening ). |
|
| Back to top |
|
|
| dkeister |
| Posted: Tue Nov 11, 2008 1:03 pm Post subject: |
|
|
Disciple
Joined: 25 Mar 2002
Posts: 184
Location: Purchase, New York
|
Did you remove the trace node and see if it still works?
_________________
Dean Keister |
|
| Back to top |
|
|
| ggriffith |
| Posted: Wed Nov 12, 2008 1:41 am Post subject: |
|
|
Acolyte
Joined: 17 Oct 2007
Posts: 67
|
| Yes, did that, still works. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Nov 12, 2008 2:39 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Sometimes the toolkit caches old values, but a project rebuild can sort it out.
As I said, you probably deployed a flow without the SET ALL option being set, whether you meant to do so or not.
If it consistently works now, I would assume that it was a toolkit quirk.
The way to avoid these is to use clean and/or rebuild before creating a bar file. |
|
| Back to top |
|
|
| ggriffith |
| Posted: Wed Nov 12, 2008 3:09 am Post subject: |
|
|
Acolyte
Joined: 17 Oct 2007
Posts: 67
|
Having used the broker for 7/8 years ( since v2.1 ), I've learnt to be very pedantic and never assume that the toolkit will do things for you. I always perform a clean/build before building the bar file and always remove the old flow from the execution group before deploying.
I guess I'm unlikely to get a solution to this problem, but I will post again if it happens again.  |
|
| Back to top |
|
|
|
|
