| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| NLSPATH versus MQSI_CONSOLE_NLSPATH on AIX |
« View previous topic :: View next topic » |
| Author |
Message
|
| rekarm01 |
 Posted: Wed Sep 21, 2016 6:18 pm Post subject: NLSPATH versus MQSI_CONSOLE_NLSPATH on AIX |
 |
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
We have a message flow deployed to IIB v10.0.0.4 on AIX, using ITX v9.0.0.18, and are getting these BIP2176S errors in our usertrace:
| Code: |
| BIP2176S: Could not find message 'xxxx' in catalog '/opt/IBM/mqsi/10.0.0.4/server/messages/En_US/txmsgv900.cat', inserts are ... |
We have a message catalog at /opt/IBM/itx/itx90018/wmqi/messages/En_US/txmsgv900.cat, but the broker is not finding it. The broker id sources the given mqsiprofile and dtxwmqi_900_64.sh to set these NLSPATH variables:
| Code: |
MQSI_CONSOLE_NLSPATH=/opt/IBM/itx/itx90018/wmqi/messages//En_US
NLSPATH=/opt/IBM/mqsi/10.0.0.4/server/messages/%L/%N:/opt/IBM/mqsi/10.0.0.4/server/messages/En_US/%N:
/usr/lib/nls/msg/%L/%N:/usr/lib/nls/msg/%L/%N.cat:
/usr/lib/nls/msg/%l.%c/%N:/usr/lib/nls/msg/%l.%c/%N.cat:
/opt/IBM/itx/itx90018/wmqi/messages/%L/%N:
/opt/IBM/itx/itx90018/wmqi/messages/En_US/%N |
This technote states that the AIX broker is no longer using NLSPATH as of wmb8, and is now using MQSI_CONSOLE_NLSPATH instead, but mqsiprofile is still only setting NLSPATH. This APAR states that MQSI_CONSOLE_NLSPATH doesn't support the same %-style escape sequences that NLSPATH does. The broker documentation itself is mixed, sometimes referring to NLSPATH, and sometimes referring to MQSI_CONSOLE_NLSPATH, but with the possibly unsupported %-style escape sequences.
The examples in the broker documentation suggest that MQSI_CONSOLE_NLSPATH should resolve to a list of filenames for non-Windows platforms, rather than to a list of directories. If so, then that could explain our BIP2176S errors; we are requesting a change to the script to confirm that, one way or the other. In the meantime, which of these environment variables should the broker be using, and what should they look like? |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Sep 22, 2016 3:54 am Post subject: Re: NLSPATH versus MQSI_CONSOLE_NLSPATH on AIX |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| rekarm01 wrote: |
| Code: |
| '/opt/IBM/mqsi/10.0.0.4/server/messages/En_US/txmsgv900.cat', inserts are ... |
We have a message catalog at /opt/IBM/itx/itx90018/wmqi/messages/En_US/txmsgv900.cat, |
Those are different paths?
Is that a typo?
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Thu Sep 22, 2016 8:44 am Post subject: Re: NLSPATH versus MQSI_CONSOLE_NLSPATH on AIX |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| mqjeff wrote: |
Those are different paths?
Is that a typo? |
Those are different paths. That is not a typo. The broker seems to be looking in the wrong place; setting the NLSPATH is supposed to help with that. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Sep 22, 2016 8:52 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
.. put a script that sets the right MQSI_CONSOLE_NLSPATH in the place for the broker mqsiprofile to pick it up... umm ... common\profiles\...
But looking at my mqsiprofile on my windows machine, I do see
set MQSI_CONSOLE_NLSPATH=%MQSI_BASE_FILEPATH%\server\messages\
So. If you're sourcing mqsiprofile after you've set those variables, then...
again, probably best to put a .sh script in workpath/common/profiles
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Thu Sep 22, 2016 10:13 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| mqjeff wrote: |
| ... put a script that sets the right MQSI_CONSOLE_NLSPATH in the place for the broker mqsiprofile to pick it up... umm ... common\profiles\... |
We have a script in place, dtxwmqi_900_64.sh. Upon login, the broker id sources the mqsiprofile, and then the dtxwmqi_900_64.sh script, in that order, which sets both the MQSI_CONSOLE_NLSPATH and NLSPATH variables as indicated above.
My questions are: which is the right variable to set? and what is the right value to set it to? The answers may be different for AIX than for Windows, so looking at a Windows machine may not help much. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Sep 22, 2016 11:29 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Ok. Going back through a few things. Your technote says that a fix is delivered in 8.4.0.4 of ITX, and you say you're using ITX v9.0.0.18. So you should be able to use
| Code: |
| /opt/IBM/itx/itx90018/wmqi/messages/%L/%N |
Likewise, the first technote you post is for ITX 8.x.x.x, and should be fixed in any v9
Your link http://www.ibm.com/support/knowledgecenter/SSMKHH_10.0.0/com.ibm.etools.mft.doc/as04540_.htm says that MQSI_CONSOLE_NLSPATH only applies to Windows, not to Unix. So that implies you should be setting NLSPATH.
However, http://www.ibm.com/support/knowledgecenter/SSMKHH_10.0.0/com.ibm.etools.mft.doc/as04521_.htm directly countermands that by setting MQSI_CONSOLE_NLSPATH on both platforms.
Since you're still getting regular IIB messages to the syslog, then your scripts haven't managed to remove the regular IIB message catalog from the MQSI/NLS Path...
I would try putting
| Code: |
| /opt/IBM/itx/itx90018/wmqi/messages/%L/%N |
in your MQSI_CONSOLE_PATH (unless that // was a typo).
IF that doesn't work, look at the EG's stdout file.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Fri Sep 23, 2016 10:59 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| mqjeff wrote: |
Ok. Going back through a few things. Your technote says that a fix is delivered in 8.4.0.4 of ITX, and you say you're using ITX v9.0.0.18. So you should be able to use
| Code: |
| /opt/IBM/itx/itx90018/wmqi/messages/%L/%N |
|
I think the fix there was to remove the '%L' and '%N' from the ITX script, because MQSI_CONSOLE_NLSPATH doesn't support them. So, adding them back would just break the fix. To change the way the broker interprets MQSI_CONSOLE_NLSPATH would have required a broker fix, not an ITX fix.
| mqjeff wrote: |
| Likewise, the first technote you post is for ITX 8.x.x.x, and should be fixed in any v9 |
And I think the fix there was to have the script set MQSI_CONSOLE_NLSPATH, in addition to setting NLSPATH. The v9 script sets both.
Setting NLSPATH to '...:/opt/IBM/itx/itx90018/wmqi/messages/%L/%N:/opt/IBM/itx/itx90018/wmqi/messages/En_US/%N' should work, but it doesn't. Or else setting MQSI_CONSOLE_NLSPATH to '/opt/IBM/itx/itx90018/wmqi/messages//En_US' should work, but it doesn't. (Yes, that '//' is probably a typo, but should be a harmless one, at least for resolving Unix pathnames; that's what was originally in the script, and what we're currently using.)
We can request changes to the script to try one thing or another, and we are doing that, but we don't own the script or the broker, so we can't control how long that will take ... particularly for non-critical errors that require scheduling a broker outage or restart. In the meantime, some help explaining the broker documentation could be useful. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Sep 23, 2016 11:31 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
|
| Back to top |
|
|
| rekarm01 |
| Posted: Mon Sep 26, 2016 6:16 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
I was focusing on the broker id, which we use to start the broker, and correctly sources the mqsiprofile and dtx start script. But we have a different user id for running a usertrace, for which we only sourced the mqsiprofile, and not the dtx start script. This caused mqsiformatlog to complain about the missing catalogs, due to the missing entry in MQSI_CONSOLE_NLSPATH. Sourcing the dtx start script before running mqsiformatlog resolved the missing catalog issue.
We did not need to modify the start scripts; MQSI_CONSOLE_PATH works fine as-is, (even with the extra '/'); it does not work with either the '%L', or '%N', so it seems they are still not supported. Setting just NLSPATH does not work, so it seems that mqsiformatlog really doesn't use it anymore. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Sep 27, 2016 8:59 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Well, I'm glad you figured it out, without my help.
I'm generally clueless about WTX... And it wasn't clear to me that you weren't talking about the broker runtime, either.
But that's because I didn't think that user trace used the local user's profile and not the broker's. However, given that trace is usually sent by XML and then processed into text, it does make sense.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Sep 27, 2016 6:28 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| rekarm01 wrote: |
I was focusing on the broker id, which we use to start the broker, and correctly sources the mqsiprofile and dtx start script. But we have a different user id for running a usertrace, for which we only sourced the mqsiprofile, and not the dtx start script. This caused mqsiformatlog to complain about the missing catalogs, due to the missing entry in MQSI_CONSOLE_NLSPATH. Sourcing the dtx start script before running mqsiformatlog resolved the missing catalog issue.
We did not need to modify the start scripts; MQSI_CONSOLE_PATH works fine as-is, (even with the extra '/'); it does not work with either the '%L', or '%N', so it seems they are still not supported. Setting just NLSPATH does not work, so it seems that mqsiformatlog really doesn't use it anymore. |
And could you please explain why running the mqsiprofile does not source the dtx start script?? i.e. setting up a correct runtime environment... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Thu Sep 29, 2016 10:30 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| mqjeff wrote: |
| And it wasn't clear to me that you weren't talking about the broker runtime, either. |
Sorry that wasn't more clear. I didn't notice that you were referring to the syslog, while I was referring to the usertrace.
| mqjeff wrote: |
| But that's because I didn't think that user trace used the local user's profile and not the broker's. However, ..., it does make sense. |
Yes, that was a surprise, and yes, it seems a little obvious now.
| fjb_saper wrote: |
| And could you please explain why running the mqsiprofile does not source the dtx start script?? i.e. setting up a correct runtime environment... |
Our server uses multiple versions of WMB/IIB, requiring different versions of WTX/ITX. Some brokers need to source dtxwmqi_900_64.sh, and some need to source dtxwmqi_84_64.sh, and the rest don't need to source either one. We cannot put all of the dtxwmqi scripts in the same <workpath>/common/profiles directory, because they conflict with each other. The different mqsiprofile scripts just source whatever is there; they don't decide which dtxwmqi scripts they should source, and which ones they shouldn't.
We thought about creating different <workpath> directories for the different brokers, but the impact of that goes far beyond creating separate common/profiles directories, so we decided against that. We also decided against modifying the vendor supplied mqsiprofile and dtxwmqi scripts directly. Instead, we moved the dtwmqi scripts out of the common/profiles directory to prevent any mqsiprofile from sourcing them, and now rely on the broker id .profile to keep track of whichever mqsiprofile and other scripts it needs to source, to setup the correct runtime environment. That seemed to be the simplest option. It's also what IBM recommended.
Our non-broker user id, on the other hand, is not tied to any particular broker, so there is no fixed notion of a "correct runtime environment". We use that id for supporting functions, (such as managing non-broker related MQ applications, usertrace, mqsilist, mqsireport*, etc.), and have separate user scripts to set up the environment for the desired version of MQ/broker, on demand. It doesn't use WTX/ITX directly, so we didn't see a need before now for it to source any dtxwmqi scripts. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Oct 01, 2016 12:28 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| rekarm01 wrote: |
| fjb_saper wrote: |
| And could you please explain why running the mqsiprofile does not source the dtx start script?? i.e. setting up a correct runtime environment... |
Our server uses multiple versions of WMB/IIB, requiring different versions of WTX/ITX. Some brokers need to source dtxwmqi_900_64.sh, and some need to source dtxwmqi_84_64.sh, and the rest don't need to source either one. We cannot put all of the dtxwmqi scripts in the same <workpath>/common/profiles directory, because they conflict with each other. The different mqsiprofile scripts just source whatever is there; they don't decide which dtxwmqi scripts they should source, and which ones they shouldn't.
We thought about creating different <workpath> directories for the different brokers, but the impact of that goes far beyond creating separate common/profiles directories, so we decided against that. We also decided against modifying the vendor supplied mqsiprofile and dtxwmqi scripts directly. Instead, we moved the dtwmqi scripts out of the common/profiles directory to prevent any mqsiprofile from sourcing them, and now rely on the broker id .profile to keep track of whichever mqsiprofile and other scripts it needs to source, to setup the correct runtime environment. That seemed to be the simplest option. It's also what IBM recommended.
Our non-broker user id, on the other hand, is not tied to any particular broker, so there is no fixed notion of a "correct runtime environment". We use that id for supporting functions, (such as managing non-broker related MQ applications, usertrace, mqsilist, mqsireport*, etc.), and have separate user scripts to set up the environment for the desired version of MQ/broker, on demand. It doesn't use WTX/ITX directly, so we didn't see a need before now for it to source any dtxwmqi scripts. |
So I take it you are already using the "per broker" set up for mqsiprofile.
I understand the need for a generic broker user id. It could however be mitigated with something like the setmqenv which can be run by qmgr.
All it takes is some fancy shell work like calling the new group initialization routine and adding a specific WTX/ITX by broker. So when you want to work with broker x you just call the init script passing the broker name and your environment is set up... and to make sure it is the same as the runtime environment of the broker the WTX/ITX part could be sourced from the broker specific profile path...
Have fun
_________________
MQ & Broker admin |
|
| 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
|
|
|
|
