| Author |
Message
|
| eleanora |
 Posted: Mon Aug 02, 2010 10:20 pm Post subject: saveqmgr bad PCF response message |
 |
|
Novice
Joined: 18 Nov 2002
Posts: 16
Location: Melbourne, Australia
|
i need some help pls. have 2 identical productions boxes:
mqm@lppwa1154[/var/mqm]uname -a
Linux lppwa1154 2.6.18-194.3.1.el5PAE #1 SMP Sun May 2 04:42:25 EDT 2010 i686 i686 i386 GNU/Linux
lppwa1129 CCSID(819)
mqm@lppwa1129[/var/mqm/]uname -a
Linux lppwa1129 2.6.18-194.el5PAE #1 SMP Tue Mar 16 22:00:21 EDT 2010 i686 i686 i386 GNU/Linux
Both running 6.0.2.8, one works with saveqmgr and the other gives:
mqm@lppwa1154[/var/mqm/bin]./saveqmgr.Linux -D7 -m LPPWA1154 -f
SAVEQMGR V6.0.3
Compiled for Websphere MQ V6.0 on Aug 29 2006
(saveqmgr.c) executing with diagnostic level 7
Requesting attributes of the queue manager...
(mqutils.c) ReplyToQ: SAVEQMGR.4C4D1AF62004B305 (mqutils.c) *** Putting to command server *** length - 36 bytes
00000000: 0100 0000 2400 0000 0100 0000 0200 0000 '....$...........'
00000010: 0100 0000 0100 0000 0000 0000 0000 0000 '................'
00000020: 0000 0000 '.... '
MsgId : X'414D51204C5050574131313534202020F61A4D4C06B30420'
(mqutils.c) Before MQGET: Options: 24577, Encoding: 546, CCSID: 0
(mqutils.c) After MQGET: RC: 0, Options: 24577, Encoding: 546, CCSID: 819, Format 'MQADMIN '
(mqutil.c) *** Got message from command server ***
CorrelId : X'414D51204C5050574131313534202020F61A4D4C06B30420'
length - 52 bytes
00000000: 0200 0000 2400 0000 0100 0000 0200 0000 '....$...........'
00000010: 0100 0000 0000 0000 0200 0000 E90B 0000 '................'
00000020: 0100 0000 0300 0000 1000 0000 0200 0000 '................'
00000030: 3303 0000 '3... '
(saveqmgr.c) processing a response:
Type = 2
StrucLength = 36
Version = 1
Command = 2
MsgSeqNumber = 1
Control = 0
CompCode = 2
Reason = 3049
ParameterCount = 1
(ObjectSets) = 1
Got bad PCF response message
Type = 2
StrucLength = 36
Version = 1
Command = 2
MsgSeqNumber = 1
Control = 0
CompCode = 2
Reason = 3049
ParameterCount = 1
Parameter = 2
Value = 819
Processing Aborted, output file may be incomplete
Both have CCSID(819), so I cannot figure out whats wrong. There are no errors found in MQ logs. I have tried the other versions of saveqmgr as well as the latest saveqmgr just in case, but get same error no matter which version I ran:
mqm@lppwa1154[/var/mqm/bin/elle]./saveqmgr.linux -D1 -m LPPWA1154 -f
Compiled for Websphere MQ V7.0.1.0 on Jan 22 2010
(saveqmgr.c) executing with diagnostic level 1
SAVEQMGR V6.1.3
Requesting attributes of the queue manager...
Got bad PCF response message
Type = 2
StrucLength = 36
Version = 1
Command = 2
MsgSeqNumber = 1
Control = 0
CompCode = 2
Reason = 3049
ParameterCount = 1
Parameter = 2
Value = 819
Processing Aborted, output file may be incomplete
help pls. thanks in advance! |
|
| Back to top |
|
 |
| hopsala |
| Posted: Mon Aug 02, 2010 11:56 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Hm, an odd one. You might try:
A. Running saveqmgr as a client from one machine to the other, and from a windows box to either linux boxes, and see what happens.
B. Copy the saveqmgr pack from the working server to the other one and run, and vice versa
C. This might all be a prob with the way you FTPed the pack. Did you make sure to transfer it in binary mode? Maybe you transferred the packs in a different mode to either server
D. Try interpreting the PCF response you get. It might even be worth it to send the same message that saveqmgr sends and get a response message.
E. It doesn't really make sense, but it's worth checking whether this might have something to do with default conversion, which might be enabled in one server but not in the next. Compare both servers' ccsid.tbl file.
F. Create another QM on the machine with the problem, and try running saveqmgr against it.
And... I'm out  |
|
| Back to top |
|
|
| eleanora |
| Posted: Tue Aug 03, 2010 1:34 am Post subject: |
|
|
Novice
Joined: 18 Nov 2002
Posts: 16
Location: Melbourne, Australia
|
i have tried A,B,C and E before and it being a prod box cannot really do any playing with. anyone has any other ideas what i can check without do? 
mqm@lppwa1129[/var/mqm/conv/table]ls -ltr
total 32
-rw-rw-r-- 1 mqm mqm 26999 Jan 12 2010 ccsid.tbl
mqm@lppwa1154[/var/mqm/conv/table]ls -ltrr
total 32
-rw-rw-r-- 1 mqm mqm 26999 Jan 11 2010 ccsid.tbl
Thanks! |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Aug 03, 2010 2:09 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Excellent use of the undocumented -D flag.
MQRC 3049 is MQRCCF_CCSID_ERROR. Command 2 is Inquire Qmgr...
Where I've seen this issue pop up before, it was that the server hosting the qmgr did not have all of the necessary things configured to perform conversion.
If you runmqsc against the qmgr in question, what does it report for the CCSID? The docs on MQRCCF_CCSID_ERROR suggest that the response message will include the 'correct' ccsid, but the diagnostics are showing that the response is CCSID 819 - which is bog standard.
I suspect you need to open a PMR. 
You're going to have to be a bit careful in working it to be clear that it's *NOT* an issue with saveqmgr.
A reasonable way to do this would be to confirm that the issue occurs if you use the PCF Sample. be aware that this listing has a slight bug in it that AddToFileQLocal is defined as returning an INT value but doesn't actually do so. Just change the method signature to void instead of int. |
|
| Back to top |
|
|
| eleanora |
| Posted: Tue Aug 03, 2010 4:22 pm Post subject: |
|
|
Novice
Joined: 18 Nov 2002
Posts: 16
Location: Melbourne, Australia
|
thank u! both qmgr report 819 as ccsid when runmqsc, i also suspect one server is not setup same way.. but cannot see the diff....so i guess i am going to open a PMR. i was just trying to short cut it here as u never know!!! we have thousands of boxes where we deploy saveqmgr using the same method, i v'e been supporting mq for them for 5 years and this is my first issue with it. i did have others but was always able to figure out what the issue is and how to fix it, until now.
thanks for your help! |
|
| Back to top |
|
|
| hopsala |
| Posted: Tue Aug 03, 2010 8:03 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| Good luck. Keep us posted as to how you solved it, maybe we'll learn something new. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Aug 03, 2010 8:57 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Have you checked whether it is your version of saveqmgr that is at fault?
| Quote: |
SAVEQMGR V6.0.3
Compiled for Websphere MQ V6.0 on Aug 29 2006 |
| Quote: |
mqm@lppwa1154[/var/mqm/bin/elle]./saveqmgr.linux -D1 -m LPPWA1154 -f
Compiled for Websphere MQ V7.0.1.0 on Jan 22 2010
(saveqmgr.c) executing with diagnostic level 1 |
Jeff might know if there is a known bug there. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| eleanora |
| Posted: Tue Aug 03, 2010 9:03 pm Post subject: |
|
|
Novice
Joined: 18 Nov 2002
Posts: 16
Location: Melbourne, Australia
|
| all existing saveqmgr versions produce this error on this particular server only. so while i understand that server has "something" - I do not understand what it is. none of the versions of saveqmgr on the other servers produce the error. the error reported has to do with ccsid, and again i cannot see anything wrong with ccsid. so back to the puzzle! |
|
| Back to top |
|
|
| eleanora |
| Posted: Fri Aug 06, 2010 12:48 am Post subject: |
|
|
Novice
Joined: 18 Nov 2002
Posts: 16
Location: Melbourne, Australia
|
i did log a pmr https://www-946.ibm.com/support/servicerequest/problemDescriptionSelect.action?userType=0&srNumber=60779&sourceAppl=XSR&retainCountryCode=000&branch=227&sourceNode=prNode6&sourceTranId=415451280993991444&draft=0 and so far got nothing.... someone is not reading it properly to see what values are reported in locale and ccsid...
meantime i got another request to change ccsid for a linux box which made me do some reading.. so here is what i don;t get and hope you can help me.
I am referring to http://www-01.ibm.com/support/docview.wss?uid=swg21233177 and in particular to :
-------------------------
[i]Example for Linux®:
You are using the locale "en_US.UTF-8". What is the CCSID?
$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
$ locale charmap
UTF-8
The codeset name is UTF-8 and from the "Note about UTF-8" in this technote, the CCSID is 1208.[/i]
-------------------
My understanding is that on Linux LANG=en_US.UTF-8 corresponds to CCSID 1208., while on AIX LANG=en_US will corresponds to CCSID of 819. which means the 2 servers i have (and now others as I check) have a mismatch as they report:
mqm@lppwa1129[/var/mqm/]locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
mqm@lppwa1129[/var/mqm/]echo "display qmgr ccsid" | runmqsc
5724-H72 (C) Copyright IBM Corp. 1994, 2005. ALL RIGHTS RESERVED.
Starting MQSC for queue manager LPPWA1129.
1 : display qmgr ccsid
AMQ8408: Display Queue Manager details.
QMNAME(LPPWA1129) CCSID(819)
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.
mqm@lppwa1129[/var/mqm/]
mqm@lppwa1129[/var/mqm/]locale charmap
UTF-8
-----------------------------------------------------------------
mqm@lppwa1154[/var/mqm/]locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
mqm@lppwa1154[/var/mqm/]echo "display qmgr ccsid" | runmqsc
5724-H72 (C) Copyright IBM Corp. 1994, 2005. ALL RIGHTS RESERVED.
Starting MQSC for queue manager LPPWA1154.
1 : display qmgr ccsid
AMQ8408: Display Queue Manager details.
QMNAME(LPPWA1154) CCSID(819)
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.
mqm@lppwa1154[/var/mqm/]locale charmap
UTF-8
--------------------------
while I would expect ccsid to be 1208. so is the issue is that ccsid should not be changed here from 1208 to 819 as its causing some issues (on 1 box so far)?
any thoughts? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Aug 06, 2010 1:10 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If it is truly a CCSID problem I would ask that you verify that all used ccsid locales are installed on your OS.
Say you run the QMGR in ccsid 819 but have not installed the equivalent character set on the OS ... you are bound to run into trouble.
To make things easy I would request that the os installs the Char sets for CCSID 1208 and for the CCSID of the qmgr.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| eleanora |
| Posted: Fri Aug 06, 2010 2:23 am Post subject: |
|
|
Novice
Joined: 18 Nov 2002
Posts: 16
Location: Melbourne, Australia
|
well thats the bit I am not sure about as I am not a SA. it is my understanding that all boxes are configured with same lang and then when qmgr is created it gets the corresponding ccsid (1208 in this case). then if someone goes and changes it to 819, it could have created an issue, so far on 1 box only. its only my theory at this stage, so i wanted to confirm it here.
on a dev box i've done this experiment just now:
QMNAME(LPDWA738) CCSID(1208)
$ locale
LANG=en_US
LC_CTYPE="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_COLLATE="en_US"
LC_MONETARY="en_US"
LC_MESSAGES="en_US"
LC_PAPER="en_US"
LC_NAME="en_US"
LC_ADDRESS="en_US"
LC_TELEPHONE="en_US"
LC_MEASUREMENT="en_US"
LC_IDENTIFICATION="en_US"
LC_ALL=
$ locale charmap
ISO-8859-1
$ ./saveqmgr.Linux -s
SAVEQMGR V6.0.1
Compiled for Websphere MQ V6.0 on Oct 3 2005
Requesting attributes of the queue manager...
Writing Queue Manager definition to SAVEQMGR.TST.
Generating attributes for Websphere MQ Release 6.0.0
Requesting attributes of all authinfo objects...
Requesting attributes of all queues...
Requesting attributes of all channels...
Requesting attributes of all processes...
Requesting attributes of all namelists...
Requesting attributes of all listeners...
Requesting attributes of all services...
Writing Queue definitions to SAVEQMGR.TST.
Skipping dynamic queue SAVEQMGR.4C3F2986200CAC04
Writing Channel definitions to SAVEQMGR.TST.
Writing Namelist definitions to SAVEQMGR.TST.
$
$ uname -a
Linux lpdwa738 2.4.21-63.ELhugemem #1 SMP Wed Oct 28 23:12:58 EDT 2009 i686 i686 i386 GNU/Linux
so according to http://www.tachyonsoft.com/iso88591.htm : ISO-8859-1 is CCSID 00819, but the existing qmgr has 1208 and has no issues with saveqmgr (or any other issues I am aware of from appl guys or MQ).
so i went ahead and create a test qmgr. it got created with
QMNAME(elle) CCSID(819)
and i had no issues running saveqmgr
$ ./saveqmgr.Linux -m elle -s
SAVEQMGR V6.0.1
Compiled for Websphere MQ V6.0 on Oct 3 2005
Requesting attributes of the queue manager...
Writing Queue Manager definition to SAVEQMGR.TST.
Generating attributes for Websphere MQ Release 6.0.0
Requesting attributes of all authinfo objects...
Requesting attributes of all queues...
Requesting attributes of all channels...
Requesting attributes of all processes...
Requesting attributes of all namelists...
Requesting attributes of all listeners...
Requesting attributes of all services...
Writing Queue definitions to SAVEQMGR.TST.
Skipping dynamic queue SAVEQMGR.4C5BE0CE20000703
I then went and changed it to
alter qmgr ccsid(1208)
bounced qmgr and still had no issues with same saveqmgr.
more thoughts? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 06, 2010 2:50 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Did you try the same test qmgr on the machine that doesn't work?
Did you try seeing if altering the qmgr ccsid on the machine that doesn't work, actually solves the problem? |
|
| Back to top |
|
|
| eleanora |
| Posted: Fri Aug 06, 2010 3:17 am Post subject: |
|
|
Novice
Joined: 18 Nov 2002
Posts: 16
Location: Melbourne, Australia
|
| i wish i could without loosing my job.... being a prod box cannot do much apart from running an inquiry type cmds. so thats why i tried on a dev box and nothing makes sense to me! |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 06, 2010 4:23 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Right. Forgot that, sorry.
At some point you're going to need to acquire authorization to make some change to this machine, once it is determined what is going on.
Can you run rpm -qa on this machine?
You should compare the results between the prod machine and the working machine. Any differences, specifically anything involving iconv file sets, may be meaningful.
A base rpm -qa output without any filtering will be fairly large, so you probably want to redirect it to a file and then use diff to compare the results.
And keep updating the PMR. The fact that you are unable to recreate the issue on the test machine, following the procedure that the L2 person used, is important information. |
|
| Back to top |
|
|
| eleanora |
| Posted: Sun Aug 08, 2010 8:42 pm Post subject: |
|
|
Novice
Joined: 18 Nov 2002
Posts: 16
Location: Melbourne, Australia
|
yep - once we know what needs to be changed, i will have to raise a change. the way its now looking to me - it will not be me! pmr is now xfered to level 3 as finally level 2 read my discovery and stopped telling me how it works on their machines. it does not look to me mq cares much about the discrepancy between what OS lang and CCSID have on other machines. i now found lots of existing servers where it does not match and ALL works as intended (MQ and appl). all but 1 server. so lets see what level 3 has to say.
btw rpm output on both machines is identical, which is knew up front...both machines were setup on the same day using same build package, just like mq. of course changes could be done once the build is complete..but so far i cannot find any diff apart from pcf errors on one box.
will keep u posted. |
|
| Back to top |
|
|
|
|
