| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Help with empty ApplIdentityData field of the MQMD |
« View previous topic :: View next topic » |
| Author |
Message
|
| LouML |
 Posted: Wed May 18, 2011 4:50 am Post subject: Help with empty ApplIdentityData field of the MQMD |
 |
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
Not sure if this belongs here or in MQ Security. Admins, please move as you see fit.
Prerequisite info:
Production Client app is running on a Windows server running MQ Client 7.0.1.4
Production Queue Manager is MQ Server 6.0.2.5 on Solaris. OAM is ENABLED.
Dev Queue Manager is MQ Server 7.0.1.5 on Solaris. OAM is DISABLED.
The svrconn channels for both QM's have the same configuration except the prod channel has MCAUSER('mqm') (I know this is bad!).
We have a problem with a message being put to the dead letter queue on the remote end because of feedback MQFB_STOPPED_BY_MSG_EXIT. The Exit on their end expects username/password in the ApplIdentityData field of the MQMD.
As they explained it, the ApplIdentityData and ApplOriginData fields of the MQMD were empty. These fields were not empty, when this exact same Production app, was pointed to our Dev Queue Manager,
I stopped our sender channel on each QM and viewed the message on the xmitq and see that this data is missing in Production but exists in Dev.
I'm guessing that OAM is part of the problem.
So, to get this working ASAP, I guess my options are:
1 - Disable OAM in Prod. This is not feasible at this point as we can not stop/restart the Queue Manager during the day (nor a good idea anyway). I'm not sure this is even the problem.
2 - Change MCAUSER on the svrconn channel to the userid of the sending windows app, then use setmqaut to allow access.
3 - Have the developers make some change with identity context ??? Not sure about this.
Since the app is working in Dev, the developers feel they can't do anything. Is there something they can change in their code (identity context or does the fact that the svrconn channel has MCAUSER('mqm') negate any app changes?
Any advice would be most appreciated.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed May 18, 2011 5:06 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If the same code runs differently on two queue managers (at the same levels) then you should examine all of the differences in the two queue managers.
If, for example, the OAM is disabled in development (which it shouldn't be...), then you should enable the OAM in development and get the programmers to revisit the code.
If, for example, the code runs as mqm in development and runs as a production user in production... then you should run the code in development as a simliarly restricted user and then confirm the OAM changes needed to produce the correct results... |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed May 18, 2011 6:33 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
The Exit on their end expects username/password in the ApplIdentityData field of the MQMD.
|
MQ does not put that information in that field.
The application would do it.
The application would need to be authorized to set that field on the MQPUT.
The application would need to specify the correct MQ options on the PUT call to set that field.
In DEV, they are "authorized" because there is no security (you disabled OAM -  ).
In PROD, they are "authorized" because they are connected to the Queue Manager as mqm, which can only ever have any and all authority.
So, either the code is different between DEV and PROD, they are connecting to the PROD QM over a channel other than the one that has 'mqm" in the MCAUSER, or, maybe in DEV they are allowed to set this value even though they are not specifying the correct option to do so because OAM is off, but in PROD the lack of the proper option is correctly causing MQ to ignore their attempt to populate that field.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| LouML |
| Posted: Wed May 18, 2011 7:27 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| PeterPotkay wrote: |
| Quote: |
The Exit on their end expects username/password in the ApplIdentityData field of the MQMD.
|
MQ does not put that information in that field.
The application would do it.
The application would need to be authorized to set that field on the MQPUT.
The application would need to specify the correct MQ options on the PUT call to set that field.
In DEV, they are "authorized" because there is no security (you disabled OAM - ).
In PROD, they are "authorized" because they are connected to the Queue Manager as mqm, which can only ever have any and all authority.
So, either the code is different between DEV and PROD, they are connecting to the PROD QM over a channel other than the one that has 'mqm" in the MCAUSER, or, maybe in DEV they are allowed to set this value even though they are not specifying the correct option to do so because OAM is off, but in PROD the lack of the proper option is correctly causing MQ to ignore their attempt to populate that field. |
The application is exactly the same. They run it pointing to the Dev QM and it works. They run it again, pointing to the Prod QM and it doesn't.
Actually, the Prod Queue Manager (version 6.0.2.5) where it has the problem has:
1 - The ApplIdentityData field of the MQMD empty but the UserIdentifier field of the MQMD is 'mqm'
2 - The OAM NOT commented out in the qm.ini file
3 - The mcauser('mqm') on the svrconn channel
The Dev Queue Manager (version 7.0.1.5) where it has NO problem has:
1 - The ApplIdentityData field of the MQMD has the correct data but the UserIdentifier field of the MQMD is empty
2 - The OAM commented out in the qm.ini file
3 - The mcauser(' ') on the svrconn channel
Again, the same Windows app has tried this pointing to each, so there is no difference in the app.
The app code has:
{
sendDestination = session.CreateQueue(queueName);
sendDestination.SetIntProperty(XMSC.WMQ_TARGET_CLIENT, XMSC.WMQ_TARGET_DEST_MQ);
sendDestination.SetBooleanProperty(XMSC.WMQ_MQMD_WRITE_ENABLED, true);
sendDestination.SetIntProperty(XMSC.WMQ_MQMD_MESSAGE_CONTEXT, XMSC.WMQ_MDCTX_SET_ALL_CONTEXT);
}
and further down, it has:
message.JMSReplyTo = replyToQueue;
message.SetIntProperty(XMSC.WMQ_PERSISTENCE, MQC.MQPER_PERSISTENT);
message.SetStringProperty(XMSC.JMS_IBM_FORMAT, MQC.MQFMT_STRING);
message.SetStringProperty(XMSC.JMS_IBM_MQMD_APPLIDENTITYDATA, applIdData);
| Quote: |
| but in PROD the lack of the proper option is correctly causing MQ to ignore their attempt to populate that field. |
What is the 'proper option' you speak of?
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed May 18, 2011 7:33 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed May 18, 2011 7:40 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
So this is why it's nice to have a test environment as well as a dev and prod environment.... Because then you can test things like apps running under normal authorization rather than as MQM or without OAM enabled or etc.
Again, it's best moving ahead to turn OAM *on* in development. |
|
| Back to top |
|
|
| LouML |
| Posted: Wed May 18, 2011 8:32 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| mqjeff wrote: |
So this is why it's nice to have a test environment as well as a dev and prod environment.... Because then you can test things like apps running under normal authorization rather than as MQM or without OAM enabled or etc.
Again, it's best moving ahead to turn OAM *on* in development. |
I agree and that is the plan going forward. We have multiple Dev Queue Managers, some older with OAM disabled and some newer, with OAM enabled.
We just tested it on a newer Dev QM (version 7.0.1.0 on Solaris), with OAM enabled, MCAUSER('mqm') and it worked.
So, now we have:
The Prod Queue Manager (version 6.0.2.5) where it has the problem has:
1 - The ApplIdentityData field of the MQMD empty but the UserIdentifier field of the MQMD is 'mqm'
2 - The OAM NOT commented out in the qm.ini file
3 - The mcauser('mqm') on the svrconn channel
The Dev Queue Manager (version 7.0.1.0) where it has NO problem has:
1 - The ApplIdentityData field of the MQMD has the correct data but the UserIdentifier field of the MQMD is empty
2 - The OAM NOT commented out in the qm.ini file
3 - The mcauser('mqm') on the svrconn channel
The only difference now, is the Queue Manager version. Here they are, side by side:
| Code: |
Version 6.0.2.5 Version 7.0.1.0
QMNAME(QM.PROD1.01) QMNAME(QM.DEV1.01)
ACCTCONO(DISABLED) ACCTCONO(DISABLED)
ACCTINT(1800) ACCTINT(1800)
ACCTMQI(OFF) ACCTMQI(OFF)
ACCTQ(OFF) ACCTQ(OFF)
ACTIVREC(MSG) ACTIVREC(MSG)
ALTDATE(2008-02-24) ALTDATE(2008-07-17)
ALTTIME(09.10.18) ALTTIME(16.53.16)
AUTHOREV(DISABLED) AUTHOREV(DISABLED)
CCSID(819) CCSID(819)
CHAD(DISABLED) CHAD(DISABLED)
CHADEV(DISABLED) CHADEV(DISABLED)
CHADEXIT( ) CHADEXIT( )
CHLEV(DISABLED) CHLEV(DISABLED)
CLWLDATA( ) CLWLDATA( )
CLWLEXIT( ) CLWLEXIT( )
CLWLLEN(100) CLWLLEN(100)
CLWLMRUC(999999999) CLWLMRUC(999999999)
CLWLUSEQ(LOCAL) CLWLUSEQ(LOCAL)
CMDEV(DISABLED)
CMDLEVEL(600) CMDLEVEL(701)
COMMANDQ(SYSTEM.ADMIN.COMMAND.QUEUE) COMMANDQ(SYSTEM.ADMIN.COMMAND.QUEUE)
CONFIGEV(DISABLED)
CRDATE(2008-02-24) CRDATE(2007-10-23)
CRTIME(09.10.18) CRTIME(07.50.13)
DEADQ(DEAD.LETTER.QUEUE) DEADQ(DEAD.LETTER.QUEUE)
DEFXMITQ( ) DEFXMITQ( )
DESCR( ) DESCR( )
DISTL(YES) DISTL(YES)
INHIBTEV(DISABLED) INHIBTEV(DISABLED)
IPADDRV(IPV4) IPADDRV(IPV4)
LOCALEV(DISABLED) LOCALEV(DISABLED)
LOGGEREV(DISABLED) LOGGEREV(DISABLED)
MARKINT(5000)
MAXHANDS(256) MAXHANDS(256)
MAXMSGL(4194304) MAXMSGL(4194304)
MAXPROPL(NOLIMIT)
MAXPRTY(9) MAXPRTY(9)
MAXUMSGS(10000) MAXUMSGS(10000)
MONACLS(QMGR) MONACLS(QMGR)
MONCHL(OFF) MONCHL(HIGH)
MONQ(OFF) MONQ(HIGH)
PERFMEV(DISABLED) PERFMEV(DISABLED)
PARENT( )
PLATFORM(UNIX) PLATFORM(UNIX)
PSRTYCNT(5)
PSNPMSG(DISCARD)
PSNPRES(NORMAL)
PSSYNCPT(IFPER)
QMID(QM.PROD1.01_2008-02-24_09.10.18) QMID(QM.DEV1.01_2007-10-23_07.50.13)
REMOTEEV(DISABLED) REMOTEEV(DISABLED)
PSMODE(COMPAT)
REPOS( ) REPOS( )
REPOSNL( ) REPOSNL( )
ROUTEREC(MSG) ROUTEREC(MSG)
SCHINIT(QMGR) SCHINIT(QMGR)
SCMDSERV(QMGR) SCMDSERV(QMGR)
SSLCRLNL( ) SSLCRLNL( )
SSLCRYP( ) SSLCRYP( )
SSLEV(DISABLED) SSLEV(DISABLED)
SSLFIPS(NO) SSLFIPS(NO)
SSLKEYR(/var/mqm/qmgrs/QM!PROD1!01/ssl/key) SSLKEYR(/var/mqm/qmgrs/QM!DEV1!01/ssl/key)
SSLRKEYC(0) SSLRKEYC(0)
STATACLS(QMGR) STATACLS(QMGR)
STATCHL(OFF) STATCHL(HIGH)
STATINT(1800) STATINT(900)
STATMQI(OFF) STATMQI(ON)
STATQ(OFF) STATQ(ON)
STRSTPEV(ENABLED) STRSTPEV(ENABLED)
SYNCPT SYNCPT
TREELIFE(1800)
TRIGINT(999999999) TRIGINT(999999999) |
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| LouML |
| Posted: Wed May 18, 2011 8:45 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| PeterPotkay wrote: |
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzak.doc/fr13070_.htm
| Quote: |
ApplIdentityData (MQCHAR32)
For the MQPUT and MQPUT1 calls, this is an input/output field if MQPMO_SET_IDENTITY_CONTEXT or MQPMO_SET_ALL_CONTEXT is specified in the PutMsgOpts parameter. If a null character is present, the null and any following characters are converted to blanks by the queue manager. If neither MQPMO_SET_IDENTITY_CONTEXT nor MQPMO_SET_ALL_CONTEXT is specified, this field is ignored on input and is an output-only field. For more information on message context, see the WebSphere MQ Application Programming Guide. |
See this link too:
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzak.doc/fr14060_.htm |
I'd seen these pages. The app code I posted earlier had some settings. Looks like they're going off of this:
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=/com.ibm.mq.csqzaw.doc/jm41030_.htm
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed May 18, 2011 8:47 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| LouML wrote: |
The Dev Queue Manager (version 7.0.1.0) where it has NO problem has:
1 - The ApplIdentityData field of the MQMD has the correct data but the UserIdentifier field of the MQMD is empty
2 - The OAM NOT commented out in the qm.ini file
3 - The mcauser('mqm') on the svrconn channel
|
Further evidence that they can set all the values of the Identity Context for some reason in DEV, but not in PROD.
Just because the qm.ini file is currently set that way for the OAM does not prove the QM is actually running with OAM. Do something with a client app to get a MQRC of 2035 to prove OAM is working on this "new" DEV QM (its running an older version of MQ than your original DEV).
Lets see the app code where they set the MQPMO options.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| LouML |
| Posted: Wed May 18, 2011 9:05 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| PeterPotkay wrote: |
| LouML wrote: |
The Dev Queue Manager (version 7.0.1.0) where it has NO problem has:
1 - The ApplIdentityData field of the MQMD has the correct data but the UserIdentifier field of the MQMD is empty
2 - The OAM NOT commented out in the qm.ini file
3 - The mcauser('mqm') on the svrconn channel
|
Further evidence that they can set all the values of the Identity Context for some reason in DEV, but not in PROD.
Just because the qm.ini file is currently set that way for the OAM does not prove the QM is actually running with OAM. Do something with a client app to get a MQRC of 2035 to prove OAM is working on this "new" DEV QM (its running an older version of MQ than your original DEV).
Lets see the app code where they set the MQPMO options. |
I've asked for that and await their reply.
As for the possibility that OAM is not enabled, I just created a new test QM on the same dev machine, created a svrconn channel with mcauser blank. I ran the sample connection test and it failed. Then I changed mcauser to 'mqm' and it connected.
| Code: |
bash-3.00$ /opt/mqm/samp/bin/amqscnxc -x 'dev1(1411)' -c CH.TEST.CLIENT QM.TEST.01
Sample AMQSCNXC start
Connecting to queue manager QM.TEST.01
using the server connection channel CH.TEST.CLIENT
on connection name dev1(1411).
MQCONNX ended with reason code 2035
bash-3.00$ /opt/mqm/samp/bin/amqscnxc -x 'dev1(1411)' -c CH.TEST.CLIENT QM.TEST.01
Sample AMQSCNXC start
Connecting to queue manager QM.TEST.01
using the server connection channel CH.TEST.CLIENT
on connection name dev1(1411).
Connection established to queue manager QM.TEST.01
Sample AMQSCNXC end
bash-3.00$ |
Meanwhile, I posted my qmgr configs earlier, although I can't imagine that would be the issue. I still believe it to be the app, but at this job, you have to prove it to them before they believe you 
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed May 18, 2011 9:12 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Your latest test only proved this new QM.TEST has OAM. We still don't know if the DEV QMs they are using are actually running with OAM.
Given the absence of evidence that their code specifies the correct MQPMO options to allow them to set these fields, to me anyway this says Production is working as expected. Even with super authority (mqm), if you don't explicitly set the option to set the Identity Context, you won't be able to set those fields, even if your code moves values into them. From the manual:
| Quote: |
If neither MQPMO_SET_IDENTITY_CONTEXT nor MQPMO_SET_ALL_CONTEXT is specified, this field is ignored on input and is an output-only field.
|
I'm very interested to know what the root cause will eventually be.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| LouML |
| Posted: Wed May 18, 2011 11:27 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| PeterPotkay wrote: |
| Your latest test only proved this new QM.TEST has OAM. We still don't know if the DEV QMs they are using are actually running with OAM. |
I now believe that you are correct about the Dev QM not having OAM enabled, even though the qm.ini shows it. Obviously, this was modified after OAM was disabled and the only way to re-enable it would be to delete and recreate the QM.
I ran the same connection test to the QA QM, which is on the same server as the Dev QM and was created at the same time. OAM is enabled and I get the 2035 without the 'mqm' mcauser.
The same test to the Dev QM works with and without 'mqm' mcauser.
I sent a request to the developers to try it to the QA QM, but as they are in the UK, I won't be hearing from them until tomorrow.
Will keep you posted.
Thanks for the help!
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed May 18, 2011 12:49 pm Post subject: Re: Help with empty ApplIdentityData field of the MQMD |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| LouML wrote: |
As they explained it, the ApplIdentityData and ApplOriginData fields of the MQMD were empty. These fields were not empty, when this exact same Production app, was pointed to our Dev Queue Manager,
I stopped our sender channel on each QM and viewed the message on the xmitq and see that this data is missing in Production but exists in Dev.
|
Please explain what you mean by 'empty.' Spaces, zeros, what?
Please explain what you mean by 'not empty.' Were the contents of these fields what you would expect? Like the application name? Put date/time?
_________________
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 |
|
|
| LouML |
| Posted: Wed May 18, 2011 12:59 pm Post subject: Re: Help with empty ApplIdentityData field of the MQMD |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| bruce2359 wrote: |
| LouML wrote: |
As they explained it, the ApplIdentityData and ApplOriginData fields of the MQMD were empty. These fields were not empty, when this exact same Production app, was pointed to our Dev Queue Manager,
I stopped our sender channel on each QM and viewed the message on the xmitq and see that this data is missing in Production but exists in Dev.
|
Please explain what you mean by 'empty.' Spaces, zeros, what?
Please explain what you mean by 'not empty.' Were the contents of these fields what you would expect? Like the application name? Put date/time? |
By empty, I mean spaces
| Code: |
AMQSBCG0 - starts here
**********************
...
ApplIdentityData : ' '
... |
and by not empty, I mean data we were expecting, in this case, username and password for an Exit on the Remote Queue Manager
| Code: |
AMQSBCG0 - starts here
**********************
...
ApplIdentityData : 'UsernamePassword '
... |
I should add, that when I say 'empty', the following fields are space filled:
UserIdentifier, PutDate, PutTime, ApplOriginData
and when I say 'not empty', or 'it worked', those same fileds have valid data. Which seems to point to the suggestions Peter made earlier.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| mvic |
| Posted: Wed May 18, 2011 1:20 pm Post subject: Re: Help with empty ApplIdentityData field of the MQMD |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
If all of this is aimed at proving whether the app set identity context, and so is responsible for incorrect values in the identity context...
(Correct me if I got that wrong)
Then proof could be obtained by saying
strmqtrc -t api -m QMNAME
And then putting an instance of the suspect message using the suspect app.
End trace with
endmqtrc -m QMNAME
Go to /var/mqm/trace. Run
dspmqtrc *.TRC
grep MQPUT *.FMT
That'll give you a starting point by showing what programs did an MQPUT during your trace capture period.
Open the relevant .FMT file(s) in a text editor, and look at the MQMD on input to and output from the MQPUT.
If you find the suspect message, look at the MQPMO and MQMD that were supplied to the MQPUT call. Would this be enough to prove the matter? |
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2 Next |
Page 1 of 2 |
|
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
|
|
|
|
