Charley Rich | 26 Jan 23:14 2015

OnDemand TechTalk: Tracking messages through datapower

Watch a free, on-demand TechTalk on 
Middleware monitoring, management, tracking or self-service

This week's selection is: Tracking Messages Through DataPower

http://library.nastel.com/acton/media/6333/tracking-messages-through-datapower

To unsubscribe, write to LISTSERV@... and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Tim Zielke | 24 Jan 03:43 2015

MQSD structure padding on 64 bit applications

I spun my wheels on this today, so I wanted to document this, in case it could help out anybody else that encounters this in the future.  This information would probably be helpful for anyone who looks at MQI data structures in traces or the Application Activity Trace.

 

It looks like the MQSD (Subscription descriptor) is not properly aligned from a 64 bit stand point, and has some structure padding occurring in it.

 

Here is what the MQSD looks like from a C structure stand point:

 

struct tagMQSD {

   MQCHAR4   StrucId;              /* Structure identifier */

   MQLONG    Version;              /* Structure version number */

   MQLONG    Options;              /* Options associated with */

                                   /* subscribing */

   MQCHAR48  ObjectName;           /* Object name */

   MQCHAR12  AlternateUserId;      /* Alternate user identifier */

   MQBYTE40  AlternateSecurityId;  /* Alternate security identifier */

   MQLONG    SubExpiry;            /* Expiry of Subscription */

   MQCHARV   ObjectString;         /* Object long name */

   MQCHARV   SubName;              /* Subscription name */

   MQCHARV   SubUserData;          /* Subscription user data */

   MQBYTE24  SubCorrelId;          /* Correlation Id related to this */

                                   /* subscription */

   MQLONG    PubPriority;          /* Priority set in publications */

   MQBYTE32  PubAccountingToken;   /* Accounting Token set in */

                                   /* publications */

   MQCHAR32  PubApplIdentityData;  /* Appl Identity Data set in */

                                   /* publications */

   MQCHARV   SelectionString;      /* Message selector structure */

   MQLONG    SubLevel;             /* Subscription level */

   MQCHARV   ResObjectString;      /* Resolved long object name */

};

 

Here is an Activity Trace print out of a MQSD from a 64 bit application (the amqssub sample program). 

 

MQSD Structure:

  00000000:  5344 2020 0000 0001 0020 2022 2020 2020  'SD  .....  "    '

  00000010:  2020 2020 2020 2020 2020 2020 2020 2020  '                '

  00000020:  2020 2020 2020 2020 2020 2020 2020 2020  '                '

  00000030:  2020 2020 2020 2020 2020 2020 2020 2020  '                '

  00000040:  2020 2020 2020 2020 0000 0000 0000 0000  '        ........'

  00000050:  0000 0000 0000 0000 0000 0000 0000 0000  '................'

  00000060:  0000 0000 0000 0000 0000 0000 0000 0000  '................'

  00000070:  FFFF FFFF 0000 0000 0007 FFFE F343 4380  '.............CC.'

  00000080:  0000 0000 0000 0000 0000 0006 0000 0333  '...............3'

  00000090:  0000 0000 0000 0000 0000 0000 0000 0001  '................'

  000000A0:  0000 0000 0000 0333 0000 0000 0000 0000  '.......3........'

 000000B0:  0000 0000 0000 0000 0000 0000 0000 0333  '...............3'

  000000C0:  414D 5120 4C4C 4C4C 4C4C 4C4C 2E4D 5154  'AMQ LLLLLLLL.MQT'

  000000D0:  54BF C641 2000 2405 FFFF FFFD 0332 3434  'T..A .$......244'

  000000E0:  0000 0000 0000 0000 0000 0000 0000 0000  '................'

  000000F0:  0000 0000 0000 0000 0000 0006 0000 0000  '................'

  00000100:  0000 0000 0000 0000 0000 0000 0000 0000  '................'

  00000110:  0000 0000 0000 0000 0000 0000 54C2 BA56  '............T..V'

  00000120:  0000 0000 0000 0000 0000 0000 0000 0000  '................'

  00000130:  0000 0000 0000 0333 0000 0001 FEBE DBD0  '.......3........'

  00000140:  0000 0000 0000 0000 0000 0000 0000 0000  '................'

  00000150:  0000 0006 0000 04B8    

 

At offset x’70’ in the MQSD structure, is the SubExpiry field which is a MQLONG (4 byte signed binary integer).  It contains x’FFFFFFFF’ = -1 or MQEI_UNLIMITED.

 

The next field should be the ObjectString, which is an MQCHARV (listed below):

 

struct tagMQCHARV {

   MQPTR   VSPtr;      /* Address of variable length string */

   MQLONG  VSOffset;   /* Offset of variable length string */

   MQLONG  VSBufSize;  /* Size of buffer */

   MQLONG  VSLength;   /* Length of variable length string */

   MQLONG  VSCCSID;    /* CCSID of variable length string */

};

 

The first field in the MQCHARV is an MQPTR, which is an 8 byte binary integer for a 64 bit application.  It should start at offset x’74’.  However, it is starting at offset x’78’ and there are 4 “mystery” bytes at offset x’74’. 

 

I believe this is due to structure padding that the compiler is inserting.  Since this is a 64 bit application, an 8 byte integer field like the VSPtr needs to start at an address that is 8 byte aligned.  The compiler would start the MQSD at an 8 byte aligned address.  Therefore offsets in the MQSD structure like x’08’, x’10’, x’18’, x’20’, x’28’, etc. would be 8 byte aligned offsets.  Since the next address for the VSPtr (which would be at offset x’74’) does not fall at an 8 byte aligned offset, the compiler inserts 4 bytes of structure padding so that the VSPtr can be at an 8 byte aligned address at offset x’78’.  At least, this is how I understand this to work.

 

The same things happens at offset x’11C’, to 8 byte align the VSPtr of the SelectionString field at offset x’120’.  Also at offset x’13C’, to 8 byte align the VSPtr of the ResObjectString field at offset x’140’.  This results in 12 extra bytes being added to the MQSD for structure padding.

 

This isn’t a big deal, but it can be very confusing if you are trying to read a raw MQSD structure in a trace, so I wanted to pass it on.  Also, if you are trying to programmatically step through an MQSD in a 64 bit application with using offset logic, watch out!

 

Regards,

Tim

 

Tim Zielke | CICS/MQ Systems Programmer

Aon Service Corporation | Aon Technology | Enterprise Architecture and Engineering

4 Overlook Point, Lincolnshire, IL 60069 

t +1.847.295.5000

tim.zielke-VwKEKOxrCg4@public.gmane.org

 

 

 


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

Thomas, Don | 23 Jan 20:16 2015
Picon

Re: Removing a QM from a Cluster

Thanks Jeff. Somehow I missed that command. That certainly helps.

 

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jefferson Lowrey
Sent: Friday, January 23, 2015 1:42 PM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Removing a QM from a Cluster

 

DIS QCLUSTER should show you the queues that a given qmgr knows about, yes?

If you really want to avoid having cluster queues on the decommisioned qmgr lurking around, you should take the extra step of explicitly unsharing them from the cluster before you start.

That assumes the qmgr is working sufficiently to broadcast that action.  


I think one of the main reasons why IBM discourages the use of RESET cluster is that it can take quite a while for things to repopulate. Although I will stipulate that I don't have any hands on experience with this in recent years.


Thank you,

Jeff Lowrey




From:        "Thomas, Don" <dont <at> HP.COM>
To:        MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Date:        01/23/2015 12:22 PM
Subject:        Re: [MQSERIES] Removing a QM from a Cluster
Sent by:        MQSeries List <MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT>




Hi  T.Rob,
                Thanks for the thorough response. I was shying away from using the RESET CLUSTER, but after further reading I’m not certain that the cluster queues from the decommissioned queue manager won’t still be lurking about in the FR or other PR’s. I don’t want any clustered queues from the decommissioned queue manager existing in a repository anywhere. I wish there was a way to query the repositories to see what queues they are aware of. I suppose I could use the RESET command as a last resort.
The only good thing here is that the cluster is in a new environment that is still pretty early in the testing phase. The bad news is that we’re still at the point where we are one foot still in the old environment and one foot in the new. Unfortunately, all of my desktop client based tools are still in the old and cannot get across to the new. So it’s command line living for now. But there are only several queue managers in the cluster so checking all of the repositories doesn’t present a big obstacle.
 
Thanks again.
 
 
From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of T.Rob
Sent: Friday, January 23, 2015 10:54 AM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Removing a QM from a Cluster

 
Hi Don,
 
I know that IBM recommends to not use RESET CLUSTER except under advice of Support, but I'm a bit of a purist and don't like to see the old objects floating around in my namespace.  If it were me, once the QMgr is decommissioned I would reset it (and any other incarnations of it) from the full repositories before building the new one.
 
Also because I'm a bit of a purist, after taking care of the FRs, I would look on all the PRs in the cluster and make sure that they too had forgotten about the old QMgr (and any other incarnations of it) and issue local REFRESH commands if not.  If I do find any that still know about the old QMgr or its objects, I'd stop and try to figure out how and why the cluster is broken before continuing.  
 
These types of cluster-wide checks and actions are easy when there are tools available.  I'm fond of web-based tools but for scripting I use Paul's MQSCX for this kind of thing.  I can have one script on a central server with MQ client installed (usually the one where the central web tool is installed) and reach out and touch every QMgr in the network with a single script.  The ROI period on MQSCX for a single user license is measured in hours and I have the cleanest, healthiest clusters possible.
 
There are some perverse incentives driving some of IBM's advice.  For example, in order to sell MQ to small and medium businesses it is necessary for it to function with a small footprint.  I believe this to be the primary incentive that leads to advice such as putting the FRs on the same nodes as the business apps.  (Or more correctly, the LACK of advice to strongly encourage dedicated nodes for the FRs.)  Similarly, the more complex cluster maintenance appears  in the manuals, the more inaccessible and difficult the product seems.  The manuals almost encourage the practice of touching the least possible nodes in the cluster and trusting everything you didn't touch is OK.  Maybe it is because as a consultant I tend to get called in where there are problems, but I find that the cost/benefit of blind trust in the health of the cluster is not justified.  If the checks and maintenance are automated and the cost of running them is driven close to zero, and the impact of an unhealthy cluster is measured in tens of thousands of dollars, there is no reason to NOT inspect the cluster objects across every node after major maintenance, or even at intervals.  
 
From where I sit, RESET CLUSTER not only belongs in the MQ admin's toolbox for use at their discretion, but is essential.  IBM has to allow stale info to hang around in the cluster's namespace because the person writing MQ code doesn't know whether the QMgr is temporarily or permanently down.  But I as the administrator DEFINITELY know which QMgrs and cluster objects are supposed to be there and have no such doubts or reasons to leave them floating around the cluster namespace until they age out.
 
That's my take on it, for what it's worth.  There are plenty of people with healthy clusters who do not use RESET so I'm not saying it isn't possible.  Only that RESET CLUSTER is your friend when you know how the cluster works and use it properly.  
 
Kind regards,
-- T.Rob
 
I have availability! For a good time (with IBM MQ) call:
T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
+44 (0) 8714 089 546  Voice
https://ioptconsulting.com
https://twitter.com/tdotrob
 
From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Thomas, Don
Sent: Friday, January 23, 2015 9:49 AM
To:
MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject:
Removing a QM from a Cluster
 
Hello Listers,
 
                I have a situation where I have a PR qmgr that I need to recreate, we’ll call it PRQM. When it was created there were significant errors made in the definitions such that it is virtually useless. (Some very sloppy cutting and pasting). So I think the best course of action is to remove it from the cluster, delete it, recreate it correctly, and then reintroduce it to the cluster. From my reading the following are the steps that need to be done to accomplish this. I would appreciate it if any of you could verify if my list is complete and/or offer any suggestions from your own experiences.
 
1)      Suspend the qmgr from the cluster. From PRQM issue:                                                 SUSPEND QMGR(PRQM) CLUSTER(MQCL)
2)      Verify that PRQM has been suspended. From the Full repo qmgr FRQM issue:   DIS CLUSQMGR(PRQM) SUSPEND
3)      Remove cluster reference from PRQM’s clusrcvr channel:                                            ALTER CHANNEL(TO.PRQM) CLUSTER(‘ ‘)
4)      Stop the clusrcvr channel if it’s running:                                                                                 STOP CHANNEL(TO.PRQM)
5)      Stop the clussdr channel if it’s running:                                                                                  STOP CHANNEL(TO.FRQM)
6)      Delete the clussdr channel on PRQM:                                                                                     DELETE CHANNEL(TO.FRQM)
7)      Refresh cluster from PRQM:                                                                                                       REFRESH CLUSTER(MQCL) REPOS(YES)
 
At this point I will delete and recreate the qmgr. Correctly this time. And then reintroduce it to the cluster.
 
Does anyone see anything missing from this? BTW, this is not a production environment and I’m running MQ V7.0.1.10 on Solaris 10.
 
Any and all comments would be welcome.
 
Thanks,
 
Don Thomas
ES Apps Development US

dont <at> hp.com
M +1 412 577 8005

 
 


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


 


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

 

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

 

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


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

Thomas, Don | 23 Jan 19:21 2015
Picon

Re: Removing a QM from a Cluster

Hi  T.Rob,

                Thanks for the thorough response. I was shying away from using the RESET CLUSTER, but after further reading I’m not certain that the cluster queues from the decommissioned queue manager won’t still be lurking about in the FR or other PR’s. I don’t want any clustered queues from the decommissioned queue manager existing in a repository anywhere. I wish there was a way to query the repositories to see what queues they are aware of. I suppose I could use the RESET command as a last resort.

The only good thing here is that the cluster is in a new environment that is still pretty early in the testing phase. The bad news is that we’re still at the point where we are one foot still in the old environment and one foot in the new. Unfortunately, all of my desktop client based tools are still in the old and cannot get across to the new. So it’s command line living for now. But there are only several queue managers in the cluster so checking all of the repositories doesn’t present a big obstacle.

 

Thanks again.

 

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of T.Rob
Sent: Friday, January 23, 2015 10:54 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org
Subject: Re: Removing a QM from a Cluster

 

Hi Don,

 

I know that IBM recommends to not use RESET CLUSTER except under advice of Support, but I'm a bit of a purist and don't like to see the old objects floating around in my namespace.  If it were me, once the QMgr is decommissioned I would reset it (and any other incarnations of it) from the full repositories before building the new one.

 

Also because I'm a bit of a purist, after taking care of the FRs, I would look on all the PRs in the cluster and make sure that they too had forgotten about the old QMgr (and any other incarnations of it) and issue local REFRESH commands if not.  If I do find any that still know about the old QMgr or its objects, I'd stop and try to figure out how and why the cluster is broken before continuing. 

 

These types of cluster-wide checks and actions are easy when there are tools available.  I'm fond of web-based tools but for scripting I use Paul's MQSCX for this kind of thing.  I can have one script on a central server with MQ client installed (usually the one where the central web tool is installed) and reach out and touch every QMgr in the network with a single script.  The ROI period on MQSCX for a single user license is measured in hours and I have the cleanest, healthiest clusters possible.

 

There are some perverse incentives driving some of IBM's advice.  For example, in order to sell MQ to small and medium businesses it is necessary for it to function with a small footprint.  I believe this to be the primary incentive that leads to advice such as putting the FRs on the same nodes as the business apps.  (Or more correctly, the LACK of advice to strongly encourage dedicated nodes for the FRs.)  Similarly, the more complex cluster maintenance appears  in the manuals, the more inaccessible and difficult the product seems.  The manuals almost encourage the practice of touching the least possible nodes in the cluster and trusting everything you didn't touch is OK.  Maybe it is because as a consultant I tend to get called in where there are problems, but I find that the cost/benefit of blind trust in the health of the cluster is not justified.  If the checks and maintenance are automated and the cost of running them is driven close to zero, and the impact of an unhealthy cluster is measured in tens of thousands of dollars, there is no reason to NOT inspect the cluster objects across every node after major maintenance, or even at intervals. 

 

From where I sit, RESET CLUSTER not only belongs in the MQ admin's toolbox for use at their discretion, but is essential.  IBM has to allow stale info to hang around in the cluster's namespace because the person writing MQ code doesn't know whether the QMgr is temporarily or permanently down.  But I as the administrator DEFINITELY know which QMgrs and cluster objects are supposed to be there and have no such doubts or reasons to leave them floating around the cluster namespace until they age out.

 

That's my take on it, for what it's worth.  There are plenty of people with healthy clusters who do not use RESET so I'm not saying it isn't possible.  Only that RESET CLUSTER is your friend when you know how the cluster works and use it properly. 

 

Kind regards,

-- T.Rob

 

I have availability! For a good time (with IBM MQ) call:

T.Robert Wyatt, Managing partner

IoPT Consulting, LLC

+1 704-443-TROB (8762) Voice/Text

+44 (0) 8714 089 546  Voice

https://ioptconsulting.com

https://twitter.com/tdotrob

 

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f2VJ6XI05myT@public.gmane.org.AT] On Behalf Of Thomas, Don
Sent: Friday, January 23, 2015 9:49 AM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Removing a QM from a Cluster

 

Hello Listers,

 

                I have a situation where I have a PR qmgr that I need to recreate, we’ll call it PRQM. When it was created there were significant errors made in the definitions such that it is virtually useless. (Some very sloppy cutting and pasting). So I think the best course of action is to remove it from the cluster, delete it, recreate it correctly, and then reintroduce it to the cluster. From my reading the following are the steps that need to be done to accomplish this. I would appreciate it if any of you could verify if my list is complete and/or offer any suggestions from your own experiences.

 

1)      Suspend the qmgr from the cluster. From PRQM issue:                                                 SUSPEND QMGR(PRQM) CLUSTER(MQCL)

2)      Verify that PRQM has been suspended. From the Full repo qmgr FRQM issue:   DIS CLUSQMGR(PRQM) SUSPEND

3)      Remove cluster reference from PRQM’s clusrcvr channel:                                            ALTER CHANNEL(TO.PRQM) CLUSTER(‘ ‘)

4)      Stop the clusrcvr channel if it’s running:                                                                                 STOP CHANNEL(TO.PRQM)

5)      Stop the clussdr channel if it’s running:                                                                                  STOP CHANNEL(TO.FRQM)

6)      Delete the clussdr channel on PRQM:                                                                                     DELETE CHANNEL(TO.FRQM)

7)      Refresh cluster from PRQM:                                                                                                       REFRESH CLUSTER(MQCL) REPOS(YES)

 

At this point I will delete and recreate the qmgr. Correctly this time. And then reintroduce it to the cluster.

 

Does anyone see anything missing from this? BTW, this is not a production environment and I’m running MQ V7.0.1.10 on Solaris 10.

 

Any and all comments would be welcome.

 

Thanks,

 

Don Thomas
ES Apps Development US

dont-VXdhtT5mjnY@public.gmane.org
M +1 412 577 8005

 

 

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

 

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


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

Thomas, Don | 23 Jan 15:49 2015
Picon

Removing a QM from a Cluster

Hello Listers,

 

                I have a situation where I have a PR qmgr that I need to recreate, we’ll call it PRQM. When it was created there were significant errors made in the definitions such that it is virtually useless. (Some very sloppy cutting and pasting). So I think the best course of action is to remove it from the cluster, delete it, recreate it correctly, and then reintroduce it to the cluster. From my reading the following are the steps that need to be done to accomplish this. I would appreciate it if any of you could verify if my list is complete and/or offer any suggestions from your own experiences.

 

1)      Suspend the qmgr from the cluster. From PRQM issue:                                                 SUSPEND QMGR(PRQM) CLUSTER(MQCL)

2)      Verify that PRQM has been suspended. From the Full repo qmgr FRQM issue:   DIS CLUSQMGR(PRQM) SUSPEND

3)      Remove cluster reference from PRQM’s clusrcvr channel:                                            ALTER CHANNEL(TO.PRQM) CLUSTER(‘ ‘)

4)      Stop the clusrcvr channel if it’s running:                                                                                 STOP CHANNEL(TO.PRQM)

5)      Stop the clussdr channel if it’s running:                                                                                  STOP CHANNEL(TO.FRQM)

6)      Delete the clussdr channel on PRQM:                                                                                     DELETE CHANNEL(TO.FRQM)

7)      Refresh cluster from PRQM:                                                                                                       REFRESH CLUSTER(MQCL) REPOS(YES)

 

At this point I will delete and recreate the qmgr. Correctly this time. And then reintroduce it to the cluster.

 

Does anyone see anything missing from this? BTW, this is not a production environment and I’m running MQ V7.0.1.10 on Solaris 10.

 

Any and all comments would be welcome.

 

Thanks,

 

Don Thomas
ES Apps Development US

dont-VXdhtT5mjnY@public.gmane.org
M +1 412 577 8005

 


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

XiX | 21 Jan 03:21 2015
Picon

Re: Call for Speakers for MQ Technical Conference v2.0.1.5

sorry I didn't make it last year... I'm willing to say I will definitely make it this year... I would call it "MQ in an On Demand Environment"

On Tue, Jan 20, 2015 at 2:20 PM, Roger Lacroix <roger.lacroix-bJEeYj9oJeDQT0dZR+AlfA@public.gmane.org> wrote:
---------------------- Information from the mail header -----------------------
Sender:       MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org>
Poster:       Roger Lacroix <roger.lacroix-F8msR03N6m5XrIkS9f7CXA@public.gmane.org>
Subject:      Call for Speakers for MQ Technical Conference v2.0.1.5
-------------------------------------------------------------------------------

All,

We are looking for speakers on any product/service that uses IBM MQ (aka
WebSphere MQ & MQSeries) for "MQ Technical Conference v2.0.1.5" (MQTC).
The sessions are to be technical in nature and on any subject so long as
it relates to MQ.

We offer speakers the conference fee for free and we also pay for your
room at Kalahari Resorts. Note: Breakfast and lunch plus snacks & drinks
during the breaks are included for all attendees and speakers.

If you are interested please contact me at
callforspeakers <at> mqtechconference.com

MQTC is a premier event that brings together IBM MQ professionals from
across the mid-west and the world. MQTC will offer 70 technical sessions
and 15 vendor sessions that are designed to enhance the skills of IT
professionals who are using IBM’s IBM MQ on AIX, HP-UX, IBM i (OS/400),
Linux, Solaris, Windows and z/OS.

MQTC is the largest conference in the world solely dedicated to IBM MQ.

More information on MQTC can be found at http://www.mqtechconference.com

Regards,
Roger Lacroix
Capitalware Inc.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org 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


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 | 20 Jan 20:20 2015

Call for Speakers for MQ Technical Conference v2.0.1.5

All,

We are looking for speakers on any product/service that uses IBM MQ (aka 
WebSphere MQ & MQSeries) for "MQ Technical Conference v2.0.1.5" (MQTC). 
The sessions are to be technical in nature and on any subject so long as 
it relates to MQ.

We offer speakers the conference fee for free and we also pay for your 
room at Kalahari Resorts. Note: Breakfast and lunch plus snacks & drinks 
during the breaks are included for all attendees and speakers.

If you are interested please contact me at 
callforspeakers@...

MQTC is a premier event that brings together IBM MQ professionals from 
across the mid-west and the world. MQTC will offer 70 technical sessions 
and 15 vendor sessions that are designed to enhance the skills of IT 
professionals who are using IBM’s IBM MQ on AIX, HP-UX, IBM i (OS/400), 
Linux, Solaris, Windows and z/OS.

MQTC is the largest conference in the world solely dedicated to IBM MQ.

More information on MQTC can be found at http://www.mqtechconference.com

Regards,
Roger Lacroix
Capitalware Inc.

To unsubscribe, write to LISTSERV@... and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Thomas, Don | 20 Jan 20:00 2015
Picon

Re: MQ Expiry

Thanks Roger, Glen, T.Rob, and Bobl. That was my general understanding. I was looking for some specific doco to bolster my position with the app folks.

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Bob Juch
Sent: Tuesday, January 20, 2015 1:12 PM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: MQ Expiry

 

The default is no expiry. It can't be changed.

 

The only way to set it is in the MQMD.

 

 

On Tue, Jan 20, 2015 at 10:46 AM, Thomas, Don <dont <at> hp.com> wrote:

Hi listers,

                I apologize in advance for asking this question to this group, but I’m not an applications guy. Can someone tell me where the message expiry is set, or more specifically where the default is set. I know that it is part of the MQMD and CAN be set by the putting application, but I can’t find any value at the queue or queue manager levelto set a default. Any insight, even if it’s just pointing me to the proper reference, would be greatly appreciated.

 

 

Thanks,

 

Don Thomas
ES Apps Development US

dont <at> hp.com
+1 412 577 8005

 

 

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

 

 

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


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

Thomas, Don | 20 Jan 19:53 2015
Picon

Re: MQ Expiry

Thanks Paul. I agree with you that the application owners should be the sole determiners of when a message should expire. In fact in all of the years that I’ve been doing MQ admin work, this is the first that it was requested that I look into setting it at the queue level.

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Paul Clarke
Sent: Tuesday, January 20, 2015 1:07 PM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: MQ Expiry

 

Hi Don,

 

There is no concept of a default expiry on a queue or queue manager definition. The closest to a default is the default value specified in the MQMD_DEFAULT definition which is MQEI_UNLIMITED. This means that, provided the application programmer uses it, messages will not expire by default.

 

I think it would be quite hazardous to have Administrators deciding how long a message should live for. It seems right to me that the application programmer decides how important a message. I appreciate that there are defaults on the queue which are also pretty hazardous and one could debate whether these were a good idea too

 

Cheers,
Paul.

 

Paul Clarke

MQGem Software Limited
IBM Business Partner
www.mqgem.com
Twitter: <at> MQGem

 

From: Thomas, Don

Sent: Tuesday, January 20, 2015 5:46 PM

Subject: MQ Expiry

 

Hi listers,

                I apologize in advance for asking this question to this group, but I’m not an applications guy. Can someone tell me where the message expiry is set, or more specifically where the default is set. I know that it is part of the MQMD and CAN be set by the putting application, but I can’t find any value at the queue or queue manager levelto set a default. Any insight, even if it’s just pointing me to the proper reference, would be greatly appreciated.

 

 

Thanks,

 

Don Thomas
ES Apps Development US

dont <at> hp.com
M +1 412 577 8005

 

 

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

 

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


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

Thomas, Don | 20 Jan 18:46 2015
Picon

MQ Expiry

Hi listers,

                I apologize in advance for asking this question to this group, but I’m not an applications guy. Can someone tell me where the message expiry is set, or more specifically where the default is set. I know that it is part of the MQMD and CAN be set by the putting application, but I can’t find any value at the queue or queue manager levelto set a default. Any insight, even if it’s just pointing me to the proper reference, would be greatly appreciated.

 

 

Thanks,

 

Don Thomas
ES Apps Development US

dont-VXdhtT5mjnY@public.gmane.org
M +1 412 577 8005

 


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

Dave Corbett | 19 Jan 22:18 2015

Non-IBM MQ client applications and advanced cipher spec usage

Listers,

We have TIBCO clients written in BusinessWorks (BW) connecting into our MQ environment.  This is all in our tier 3 network, so no external considerations are involved.  We want to enable the more advanced cipher specs but I am being told that since TIBCO uses the Oracle JRE, the IBM MQ client that is packaged with the BW app cannot query the JVM to get the list of more advanced cipher specs, and therefore the only ones allowed are the really old ones such as TRIPLE_DES_SHA_US or RC4_MD5_US or any of a number of other weaker specs.

Has anyone else encountered this - and if so is there some sort of work around?

Thanks,
David Corbett
IBM Certified Solution Designer - WebSphere MQ V7.0
IBM Certified System Administrator - WebSphere MQ V7.0

U.S. BANCORP made the following annotations
---------------------------------------------------------------------
Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation.

---------------------------------------------------------------------
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


Gmane