Tim Zielke | 28 Jul 16:46 2014

Clustering Scenario Question

Hello,

 

We have a clustering scenario, that we are working on.  I was hoping to get some input from the LISTSERV on our approach, or what would be a better approach for this scenario.

 

We have the following application/MQ set up.

 

MQ queue managers are at 7.5.0.2 on Linux x86.

 

Server A hosts QM1

Server B hosts QM2

 

A redundant app1 runs on both server A and B.  app1 will take a message from Q1, process it, and then put a message on Q2 for processing by app2. 

 

Q1 is in cluster X and lives on both QM1 and QM2.  Q1 has the same CLWLRANK and CLWLPRTY on QM1 and QM2.  So basically, messages are being distributed somewhat evenly between QM1 and QM2 for Q1.

 

App2 should primarily run on QM1 and use QM2 only as a failover when QM1 is not available.  So Q2 is in cluster X and has the same CLWLRANK on QM1 and QM2.  However, the CLWLPRTY for Q2 is 5 on QM1 and 3 on QM2.  Also, the CLWLUSEQ for Q2 on QM2 is ANY.  Therefore, when app1 is running on QM2 and PUTs to Q2, MQ will send the message over to QM1 for processing.

 

This all works fine.  However, we have noticed if Server A/QM1 becomes unavailable for a longer period of time, there is a short window where app1 PUTs to Q2 on QM2 will be put on the SCTQ to be destined for QM1 for processing.  After a few minutes, QM2 realizes QM1 is truly not available, and then subsequent app1 PUTs to Q2 go to the local queue on QM2.  However, those previous Q2 messages that were PUT on the SCTQ on QM2 and were destined for QM1, stay on the SCTQ until QM1 becomes available again (which could be hours).  This does not meet our SLA, as we need these messages to be processed near time.

 

Therefore we were thinking about the following option.

 

Put a “loopback” QM3 on Server B.  QM3 would have a queue alias for Q2 with a target of Q2 and be in cluster X.  It would have a CLWLRANK that matches Q2 on QM1 and QM2, but a lower CLWLPRTY like 1.  We haven’t had a chance to test it yet, but we are assuming when that condition occurs where messages are “stuck” on the SCTQ on QM2 because QM1 is unavailable, then MQ will see the queue alias on QM3 and send the messages there.  Once QM3 receives the messages, it will route them back to QM2 where they can then be put on the local Q2 for processing. 

 

Would people have concerns with this above loopback queue manager approach for this stuck messages on the SCTQ scenario?

 

Have others used this approach for this type of clustering scenario?

 

Do others have a better suggestion to use?

 

I appreciate anyone’s input.

 

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

Livingston, Stuart J. | 28 Jul 16:36 2014

Attempting to use a Client channel definition table (CCDT)

Hello,

 

I been assigned to a project that will require the use of a client channel definition table. Being that I have no experience with one, I figure that I will try to set one up to play with.

 

My plan is to generate a CCDT on Z/OS using the CSQUTIL utility and ftp it down to my windows work station.

 

Is it possible to use a CCDT from a  Windows MQ client? If so how do I setup the MQ client to use my CCDT? Doing searches via google, I came across the variables MQCHLLIB and MQCHLTAB.

 

I have set these the variables and then used the sample program AMQSGETC to read messages on a mainframe queue manager, but the sample could not fine QMGR.

 

Does anyone have any suggestions?

 

 

Respectfully,

 

Stu

 

Stuart J. Livingston

Lead Tech Systems Architect

Transaction and Messaging Technologies

DTCC New York

slivingston-UFj9fDTTe30@public.gmane.org

212-855-8356

 

 

DTCC Confidential (Yellow)

 

 


DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.
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

Livingston, Stuart J. | 25 Jul 23:06 2014

SUBSCRIBE MQSERIES

 

 

Respectfully,

 

Stu

 

Stuart J. Livingston

Lead Tech Systems Architect

Transaction and Messaging Technologies

DTCC New York

slivingston-UFj9fDTTe30@public.gmane.org

212-855-8356

 

 

DTCC Confidential (Yellow)

 

 


DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.
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

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
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

To unsubscribe, write to LISTSERV@... and,
in the message body (not the subject), write: SIGNOFF MQSERIES

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.


Gmane