Costa, D. (Damian | 23 Jul 13:03 2014
Picon

MQ server conn channel protocol errors after MQ manager upgrade from v7.01.3 to V71.0.4

HI all,
 We just upgraded an AIX qmgr from v 7.0.1.3  to V7.1.0.4 ad are encountering a new error message in the error log.
 I've tried to google some form of coherent answer but somehow am getting some very disparate results.

My best guess is the app on the other end of the client connection is using an older MQ client . what worries me
is the app actually runs of the same server as the qmgr so by induction it should be using the MQ client
installed with the queue manager.
 That however is not always the case as there is a WAS involvement which make use of the MQ RESOURCE adapter (a 
fancy name for an MC client library).

This is the gist of the error:
07/23/14 12:52:45 - Process(22741106.531) User(mqm) Program(amqrmppa)
                    Host(dia-ete) Installation(Installation1)
                    VRMF(7.1.0.4) QMgr(**)

AMQ9504: A protocol error was detected for channel '*****.*****'.

EXPLANATION:
During communications with the remote queue manager, the channel program
detected a protocol error. The failure type was 11 with associated data of 0.
ACTION:
Contact the systems administrator who should examine the error logs to
determine the cause of the failure.

 Google results haven't given any clear direction what approach to take .  the very strange thing is that
there are instances of the channel  active and running. So not entirely sure what's happening but the error
log is getting flooded with this error.

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
(Continue reading)

MQ Client Channel Tables versus mqclient.ini

MQ Client Channel tables versus mqclient.ini

 

I’m reevaluating my ancient position that apps should use MQ Client Channel tables as the preferred method of specifying their MQ connection details. While I appreciated that channel tables exposed 100% of the options available to MQ Clients (unlike MQSERVER), and allowed me to set all those gory details without them worrying about the gory details (unlike MQCONNX), I didn’t like the binary nature of the file. You couldn’t just pop it open in read only mode to see what you had. I know there are lots of ways to officially look at the contents, but app areas didn’t always have access to these tools so they contacted me. Again.

 

So, this mqclient.ini file is a nice plain text file. What I haven’t been able to find online is an evaluation of mqclient.ini versus MQ Client Channel Tables. If the mqclient.ini file had all the functionality of the channel table I would change by recommendation away from channel tables and over to mqclient.ini.

 

So, any thoughts on this? Does mqclient.ini offer everything Client Channel tables do, assuming the following:

 

The MQ Client app will not be specifying a QM name on its MQ connect.

The MQ Client app will have one channel table or mqclient.ini file per environment.

The MQ Client app will need to connect to 1 of 3 queue managers that act as backup to each other. But it doesn’t care which one it connects to, and it only needs to be connected to one at a time.

 

 

The one benefit that client channel tables have over mqclient.ini that I can see is if the app needs to control which one of the QMs it wants to connect to, it can with channel tables (supply the QM name), but its not possible in mqclient.ini. Or is it…..If the app uses mqclient.ini (with 3 hostnames) and supplies a QM name – would the MQCONNX call fail with a 2058 and it would keep retrying until it ‘hit’ the right QM?

 

 

Any other big differences between the 2 methods?

 

Peter Potkay

 

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information.  If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited.  If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Application Activity Trace - Keeps going and going....

MQ 7.5.0.2

I make a stanza in mqat.ini to watch ‘Websphere Datapower*’, turn the queue manager’s ACTVTRC property from OFF to ON and it captures what I want. Yay.

 

I then turn the queue manager’s ACTVTRC property from ON to OFF.

 

But the tracing keeps going and going.

 

Thinking it may be ‘stuck’ on tracing an active app with a still valid hConn, I stop the DataPower application (an MQ Client) and restart it, but the tracing continues.

 

Thinking it might be related to the amqrmppa process that the MQ Clients use, I stop the DataPower application, and other MQ Clients until I have no running channels. The amqrmppa process persists so I kill it (this is a lab machine ). I then restart the DataPower app, but App Activity Tracing keeps going and going, like an unstoppable zombie.

 

I turn the queue manager’s ACTVTRC property from OFF to ON to OFF to ON lobbing a few curse words every so often, but the tracing keeps going and going.

 

ACTVTRC property is OFF. I alter the stanza in mqat.ini to turn tracing off for ‘Websphere Datapower*’, but the tracing keeps going and going. Realizing that perhaps the QM only reads mqat.ini at start up or when turn the queue manager’s ACTVTRC property is toggled, I turn the queue manager’s ACTVTRC property from OFF to ON and finally the tracing stops. Phew!

 

Anyone else seen this or any documentation that talks about it? It doesn’t seem ACTVTRC set to OFF means off!

 

 

Peter Potkay

 

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information.  If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited.  If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Paul Clarke | 21 Jul 11:08 2014

MO71 Beta Driver 2

My thanks to those of you who took the time and trouble to send me you comments, suggestions and bug reports.
The second Beta driver is now available for download. It contains a number of fixes. The two main new features are:
 
The ability to hide/show applications in the diagram from the application list
The Network display now supports multiple object move
 
As always please send me your feedback. This Driver will work without a licence file for 1 month from today and will run against any version of MQ, you do not need MQ V8 to try it,
 
Cheers,
Paul.
 
 
Paul Clarke
www.mqgem.com

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Chad Little | 21 Jul 03:18 2014

Browse issued turns into destructive get

I have noticed an interesting behavior lately with MQ 7.5, specifically on RHEL.  Similar configuration
exists on 7.1 queue managers on other operating systems but I am not pinning this to 7.5 necessarily.

The same result has happened with two programs.  One is a monitoring product and the other is Paul's q program
(V 6.0).

Using the -i (lowercase eye) for browse, the API call generated in the queue manager is a destructive get. 
The requirement is some users should only have browse access.  As such +dsp, +inq, and +browse were given to
the queue along with +connect, +dsp, and +inq to the queue manager.  When the user issues q with the -i, they
receive a 2035 and a trace validates that the call they are not authorized for is +get on the queue object.

Anybody have any idea how/why a browse issued would turn into a destructive get?

Thanks.
Chad

To unsubscribe, write to LISTSERV@... and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Tim Zielke | 18 Jul 20:21 2014

SPARC-V9 bi-endian question

Hello,

 

I was curious if anyone had run across this with MQ on Solaris SPARC.

 

I was doing some research on CPU endianness (for an MQTC session), and just read that the SPARC-V9 processor is a bi-endian processor for data access.  So in other words, you can configure it to load and store data in either big or little endian format.  The default is big endian.

 

That made me wonder about how MQ on Solaris SPARC would work, if a shop configured their SPARC-V9 processors to be little endian. 

 

The MQ native encoding for Solaris SPARC is big endian.

 

cmqc.h: #define MQENC_NATIVE                   0x00000111

 

I would think the Solaris SPARC queue manager would read MQLONG fields (i.e. Version, GMO Options, etc.) incorrectly, if a user did run the SPARC-V9 as little endian for data access.

 

I didn’t see anything documented about this topic of SPARC-V9 being bi-endian in the MQ manual.

 

Just curious if anyone has run across this scenario of running the SPARC-V9 as a little endian processor (for data access) with MQ on Solaris.

 

Thanks,

Tim


List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Tim Zielke | 18 Jul 17:58 2014

RFE - Application Activity Trace support for z/OS

Hello,

 

Please vote for the RFE, if you would find this helpful.

 

Headline:             Application Activity Trace support for z/OS

Link:                       http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=56321

 

Description:

Please provide the Application Activity Trace tool on z/OS.

 

Use Case:

I have recently started using more the MQ AAT (Application Activity Trace) on distributed, and with a few tweaks to the supplied amqsact source code, this is a very nice and powerful tool for debugging and MQ application review.

 

I noticed in the MQ manual that the AAT was not delivered for z/OS.    Perhaps this was due to this data being available through SMF.    However, for consistency sake and ease of use, it would be very helpful if the AAT was supported on z/OS, as well.

 

Business Justification:

For consistency sake and ease of use, it would be very helpful if the AAT was supported on z/OS, as well.

 

Thanks,

Tim


List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Roger Lacroix | 16 Jul 18:58 2014

Re: JMS ObjectMessage type

Hi Lawrence,

Tell your developer to RTM (you can add the 'F' if you want). :)

For JMS applications, MQ will handle (send/receive) 2 types of objects (notice I didn't say ObjectMessage), they are JMSTextMessage and JMSByteMessage.  If they did not explicitly create a TextMessage (for JMSTextMessage) then the message type will be JMSByteMessage.  Now maybe they can cast the incoming object (JMSByteMessage) to be ObjectMessage, I don't know as I have never tried that but I doubt it.

Regards,
Roger Lacroix
Capitalware Inc.

At 12:42 PM 7/16/2014, Coombs, Lawrence wrote:
Does anyone have any experience working with JMS ObjectMessages? I have a developer claiming that they are able to send the ObjectMessage, but when they receive it, it is a JMSBytesMessage.
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

Coombs, Lawrence | 16 Jul 18:42 2014

Re: JMS ObjectMessage type

Does anyone have any experience working with JMS ObjectMessages? I have a developer claiming that they are able to send the ObjectMessage, but when they receive it, it is a JMSBytesMessage.

This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Picon

Queue Manager Performance Analysis

Hi listers,

We have a queue manager with which we are having issues with the response time for certain PCF requests, and I am hoping someone can help clue me in to things to look at.

note - while these time trials are using runmqsc, we are experiencing very similar completion times using a PCF client running off-host - runmqsc does not appear to be a part of the issue.

Appreciate any assistance anyone can offer at this time. The queue manager is running, but the delayed response times are impacting other functionality that relies on the queue manager (monitoring, remote configuration, etc.)

Thanks,
David



SunOS 5.10 147440-13 sun4u sparc SUNW,SPARC-Enterprise
M4000, 16x2400MHz SPARC64

=== output from 'top' ===
load averages: 25.00, 26.28, 25.81
1362 processes:1349 sleeping, 2 running, 1 stopped, 10 on cpu
CPU states: 30.9% idle, 26.9% user, 42.2% kernel, 0.0% iowait, 0.0% swap
Memory: 64.0G real, 29.6G free, 30.2G swap in use, 68.9G swap free
**** does not appear to be a resource issue, as there is plenty of memory, no swapping, no iowait, available CPU time, not a lot of processes contending for CPU cycles, though the load averages appear to be a bit high.

WMQ Version 7.0.1.4
2,622 Local Queues
15,965 Queue Handles
849 Channels
10,937 Active channel instances

-- queues --

$ time echo 'dis ql(*)' | runmqsc PRODQMGR| grep QUEUE | wc -l
2622
real 0m1.04s
user 0m0.29s
sys 0m0.69s

$ time echo 'dis qs(*)' | runmqsc PRODQMGR| grep QUEUE | wc -l
2747
real 0m2.31s
user 0m0.62s
sys 0m0.97s

$ time echo 'dis qs(*) type(handle)' | runmqsc PRODQMGR| grep QUEUE | wc -l
15965
real 2m48.48s <<<<<
user 0m1.79s
sys 0m3.36s

-- channels --

$ time echo 'dis chl(*)' | runmqsc PRODQMGR| grep CHANNEL | wc -l
849
real 0m1.00s
user 0m0.28s
sys 0m0.45s

$ time echo 'dis chs(*)' | runmqsc PRODQMGR| grep CHANNEL | wc -l
10937
real 0m34.18s <<<<<
user 0m27.52s
sys 0m4.46s


$ ps -fu mqm | grep amqrmppa | grep PRODQMGR| wc -l
115
$ ps -fu mqm | grep amqzlaa0 | grep PRODQMGR| wc -l
185


$ mqconfig -v 7.0
mqconfig: V3.7 analyzing Solaris 10 (sparc) settings for WebSphere MQ V7.0
mqconfig: You do not have a group.mqm project configured. IBM recommends
that you configure a group.mqm project with resource limits for
WebSphere MQ, but you can run queue managers under other projects.
If you plan to use a different project for WebSphere MQ, rerun
mqconfig with the -p option to analyze that project.
mqconfig: No project given. Analyzing the current project.
Project user.mqm (): System V Semaphores
max-sem-ids 16 of 2048 sets (0%) IBM>=1024 PASS

Project user.mqm (): System V Shared Memory
max-shm-ids 72 of 65536 sets (0%) IBM>=1024 PASS
max-shm-memory 131941395333120 bytes IBM>=4294967296 PASS

Project user.mqm (): Other Settings
max-file-descriptor 10000 descriptors IBM>=10000 PASS

Shell Default Options ()
ksh bgnice:off IBM:off PASS



<< "Once the game is over, the king and the pawn go back into the same box." - Anon >>

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Coombs, Lawrence | 16 Jul 03:33 2014

Re: JCA Adapter behavior..

I have a queue that is read by a JMS application running inside Jboss application server. The queue is
defined with a backout threshold of 3 and a valid backout queue name. The platform is Linux and the version
of WebSphere MQ is 7.0.1.8.

All the messages in the backout queue have their backout counter set to '0'. How can that be? I assumed that
the counter would be '3'. Can someone shed any light on this?

This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its
subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you
are not the intended recipient, please delete it without reading the contents. Thank you.


To unsubscribe, write to LISTSERV <at> LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html


Gmane