Housecleaning for MQ

Discussion:

Mike Davidson

2013-06-25 15:26:33 UTC

Hello Everyone,

We have a bad case of "rabbit" queues (for lack of a better term)... Many
of our Qmgrs simply have too many unused queues defined, especially for
the Dev Qmgrs where developers are allowed to define their own queues for
testing. It'd be nice to clean house occasionally, but we're afraid we
might delete a queue that's needed by someone.

So I was thinking (watch out) - Wouldn't it be nice if there was a
queue-level attribute (or attributes) that reflected a date-time stamp (or
even just date) for the last time that queue was read/written to
(Get/Put)? - call the attributes (LASTREAD & LASTWRITE, or LASTGET &
LASTPUT). Then we could run a report every week, month, or whatever to
display the queues not used in the past 6 months/year/whatever and clean
up this mess!!

Before I submit such an RFE, I thought I'd run it by you all and get your
input on how you currently handle this dilemma, as well as your feelings
on such an attribute(s).

Mike Davidson
TSYS Tech Support - WebsphereMQ
MikeDavidson-***@public.gmane.org

-----------------------------------------
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

Paul S Dennis

2013-06-25 15:51:48 UTC

Permalink

Does DISPLAY QSTATUS not help you here? LPUTDATE, LPUTTIME, LGETDATE,
LGETTIME.... need to have MONQ set to something other than OFF...

Thanks
Paul

Paul Dennis
WebSphere MQ for z/OS Development

From: Mike Davidson <MikeDavidson-MaERPT+***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 25/06/2013 16:42
Subject: Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

Hello Everyone,

We have a bad case of "rabbit" queues (for lack of a better term)... Many
of our Qmgrs simply have too many unused queues defined, especially for
the Dev Qmgrs where developers are allowed to define their own queues for
testing. It'd be nice to clean house occasionally, but we're afraid we
might delete a queue that's needed by someone.

So I was thinking (watch out) - Wouldn't it be nice if there was a
queue-level attribute (or attributes) that reflected a date-time stamp (or
even just date) for the last time that queue was read/written to
(Get/Put)? - call the attributes (LASTREAD & LASTWRITE, or LASTGET &
LASTPUT). Then we could run a report every week, month, or whatever to
display the queues not used in the past 6 months/year/whatever and clean
up this mess!!

Before I submit such an RFE, I thought I'd run it by you all and get your
input on how you currently handle this dilemma, as well as your feelings
on such an attribute(s).

Mike Davidson
TSYS Tech Support - WebsphereMQ
MikeDavidson-***@public.gmane.org
----------------------------------------- The information contained in
this communication (including any attachments hereto) is confidential and
is intended solely for the personal and confidential use of the individual
or entity to whom it is addressed. If the reader of this message is not
the intended recipient or an agent responsible for delivering it to the
intended recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying, or
unauthorized use of this information, or the taking of any action in
reliance on the contents of this information is strictly prohibited. If
you have received this communication in error, please notify us
immediately by e-mail, and delete the original message. 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

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

Jefferson Lowrey

2013-06-25 15:52:12 UTC

Permalink

http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc12260_.htm

Thank you,

Jeff Lowrey

From: Mike Davidson <MikeDavidson-MaERPT+***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/25/2013 09:49 AM
Subject: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

Hello Everyone,

We have a bad case of "rabbit" queues (for lack of a better term)... Many
of our Qmgrs simply have too many unused queues defined, especially for
the Dev Qmgrs where developers are allowed to define their own queues for
testing. It'd be nice to clean house occasionally, but we're afraid we
might delete a queue that's needed by someone.

So I was thinking (watch out) - Wouldn't it be nice if there was a
queue-level attribute (or attributes) that reflected a date-time stamp (or
even just date) for the last time that queue was read/written to
(Get/Put)? - call the attributes (LASTREAD & LASTWRITE, or LASTGET &
LASTPUT). Then we could run a report every week, month, or whatever to
display the queues not used in the past 6 months/year/whatever and clean
up this mess!!

Before I submit such an RFE, I thought I'd run it by you all and get your
input on how you currently handle this dilemma, as well as your feelings
on such an attribute(s).

Mike Davidson
TSYS Tech Support - WebsphereMQ
MikeDavidson-***@public.gmane.org
----------------------------------------- The information contained in
this communication (including any attachments hereto) is confidential and
is intended solely for the personal and confidential use of the individual
or entity to whom it is addressed. If the reader of this message is not
the intended recipient or an agent responsible for delivering it to the
intended recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying, or
unauthorized use of this information, or the taking of any action in
reliance on the contents of this information is strictly prohibited. If
you have received this communication in error, please notify us
immediately by e-mail, and delete the original message. 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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

GINA MCCARTHY

2013-06-25 15:54:35 UTC

Permalink

That would be wonderful! I use the last time a change occurred in the
filesystem.

/var/mqm/qmgrs/MYQMGR/queues/q

My assumption is, that it would reflect the last time a message was put.

Gina

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
Behalf Of Mike Davidson
Sent: Tuesday, June 25, 2013 11:27 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Housecleaning for MQ

Hello Everyone,

We have a bad case of "rabbit" queues (for lack of a better term)...
Many of our Qmgrs simply have too many unused queues defined, especially
for the Dev Qmgrs where developers are allowed to define their own
queues for testing. It'd be nice to clean house occasionally, but we're
afraid we might delete a queue that's needed by someone.

So I was thinking (watch out) - Wouldn't it be nice if there was a
queue-level attribute (or attributes) that reflected a date-time stamp
(or even just date) for the last time that queue was read/written to
(Get/Put)? - call the attributes (LASTREAD & LASTWRITE, or LASTGET &
LASTPUT). Then we could run a report every week, month, or whatever to
display the queues not used in the past 6 months/year/whatever and clean
up this mess!!

Before I submit such an RFE, I thought I'd run it by you all and get
your input on how you currently handle this dilemma, as well as your
feelings on such an attribute(s).

Mike Davidson
TSYS Tech Support - WebsphereMQ
MikeDavidson-***@public.gmane.org
----------------------------------------- The information contained in
this communication (including any attachments hereto) is confidential
and is intended solely for the personal and confidential use of the
individual or entity to whom it is addressed. If the reader of this
message is not the intended recipient or an agent responsible for
delivering it to the intended recipient, you are hereby notified that
you have received this communication in error and that any review,
dissemination, copying, or unauthorized use of this information, or the
taking of any action in reliance on the contents of this information is
strictly prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original message.
Thank you

________________________________

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=sign
off%20mqseries>

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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

Mike Davidson

2013-06-25 16:36:02 UTC

Permalink

Paul,

Thanks for the reply. What are the overhead implications with leaving the
monitoring on 24/7/365?

Mike Davidson
TSYS Tech Support - WebsphereMQ
MikeDavidson-***@public.gmane.org

From: Paul S Dennis <DENNISPS-E4/***@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org,
Date: 06/25/2013 11:53 AM
Subject: Re: Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>

Does DISPLAY QSTATUS not help you here? LPUTDATE, LPUTTIME, LGETDATE,
LGETTIME.... need to have MONQ set to something other than OFF...

Thanks
Paul

Paul Dennis
WebSphere MQ for z/OS Development

From: Mike Davidson <MikeDavidson-MaERPT+***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 25/06/2013 16:42
Subject: Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

Hello Everyone,

We have a bad case of "rabbit" queues (for lack of a better term)... Many
of our Qmgrs simply have too many unused queues defined, especially for
the Dev Qmgrs where developers are allowed to define their own queues for
testing. It'd be nice to clean house occasionally, but we're afraid we
might delete a queue that's needed by someone.

So I was thinking (watch out) - Wouldn't it be nice if there was a
queue-level attribute (or attributes) that reflected a date-time stamp (or
even just date) for the last time that queue was read/written to
(Get/Put)? - call the attributes (LASTREAD & LASTWRITE, or LASTGET &
LASTPUT). Then we could run a report every week, month, or whatever to
display the queues not used in the past 6 months/year/whatever and clean
up this mess!!

Before I submit such an RFE, I thought I'd run it by you all and get your
input on how you currently handle this dilemma, as well as your feelings
on such an attribute(s).

Mike Davidson
TSYS Tech Support - WebsphereMQ
MikeDavidson-***@public.gmane.org
----------------------------------------- The information contained in
this communication (including any attachments hereto) is confidential and
is intended solely for the personal and confidential use of the individual
or entity to whom it is addressed. If the reader of this message is not
the intended recipient or an agent responsible for delivering it to the
intended recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying, or
unauthorized use of this information, or the taking of any action in
reliance on the contents of this information is strictly prohibited. If
you have received this communication in error, please notify us
immediately by e-mail, and delete the original message. 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

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

David Awerbuch (BLOOMBERG/ 731 LEXIN)

2013-06-25 17:04:58 UTC

Permalink

Hi Jeff,

LPUTTIME|LGETTIME
"The time at which the last message was [put to|retrieved from] the queue since the queue manager started. When no [put|get] time is available, perhaps because no message has been [put to|retrieved from] the queue since the queue manager was started, the value is shown as a blank."

Many shops restart their development environments on a regular basis, and this method will not work when the queue manager is started. I can only guess Mike thought of this before submitting his original request.

Mike 1
Jeff 0

Dave

----- Original Message -----
From: ***@LISTSERV.MEDUNIWIEN.AC.AT
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
At: Jun 25 2013 11:52:25

http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc12260_.htm

Thank you,

Jeff Lowrey

From: Mike Davidson <***@TSYS.COM>
To: ***@listserv.meduniwien.ac.at,
Date: 06/25/2013 09:49 AM
Subject: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <***@listserv.meduniwien.ac.at>

Hello Everyone,

We have a bad case of "rabbit" queues (for lack of a better term)... Many of our Qmgrs simply have too many unused queues defined, especially for the Dev Qmgrs where developers are allowed to define their own queues for testing. It'd be nice to clean house occasionally, but we're afraid we might delete a queue that's needed by someone.

So I was thinking (watch out) - Wouldn't it be nice if there was a queue-level attribute (or attributes) that reflected a date-time stamp (or even just date) for the last time that queue was read/written to (Get/Put)? - call the attributes (LASTREAD & LASTWRITE, or LASTGET & LASTPUT). Then we could run a report every week, month, or whatever to display the queues not used in the past 6 months/year/whatever and clean up this mess!!

Before I submit such an RFE, I thought I'd run it by you all and get your input on how you currently handle this dilemma, as well as your feelings on such an attribute(s).

Mike Davidson
TSYS Tech Support - WebsphereMQ
***@TSYS.com
----------------------------------------- The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. 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
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

<< Seriously? I don't understand why you don't understand what I don't understand!! >>

GINA MCCARTHY

2013-06-25 17:05:33 UTC

Permalink

Can you talk about the overhead and resources used?

Gina

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
Behalf Of Paul S Dennis
Sent: Tuesday, June 25, 2013 11:52 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

Does DISPLAY QSTATUS not help you here? LPUTDATE, LPUTTIME, LGETDATE,
LGETTIME.... need to have MONQ set to something other than OFF...

Thanks
Paul

Paul Dennis
WebSphere MQ for z/OS Development

From: Mike Davidson <MikeDavidson-MaERPT+***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 25/06/2013 16:42
Subject: Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

________________________________

Hello Everyone,

We have a bad case of "rabbit" queues (for lack of a better term)...
Many of our Qmgrs simply have too many unused queues defined, especially
for the Dev Qmgrs where developers are allowed to define their own
queues for testing. It'd be nice to clean house occasionally, but we're
afraid we might delete a queue that's needed by someone.

So I was thinking (watch out) - Wouldn't it be nice if there was a
queue-level attribute (or attributes) that reflected a date-time stamp
(or even just date) for the last time that queue was read/written to
(Get/Put)? - call the attributes (LASTREAD & LASTWRITE, or LASTGET &
LASTPUT). Then we could run a report every week, month, or whatever to
display the queues not used in the past 6 months/year/whatever and clean
up this mess!!

Before I submit such an RFE, I thought I'd run it by you all and get
your input on how you currently handle this dilemma, as well as your
feelings on such an attribute(s).

Mike Davidson
TSYS Tech Support - WebsphereMQ
MikeDavidson-***@public.gmane.org
----------------------------------------- The information contained in
this communication (including any attachments hereto) is confidential
and is intended solely for the personal and confidential use of the
individual or entity to whom it is addressed. If the reader of this
message is not the intended recipient or an agent responsible for
delivering it to the intended recipient, you are hereby notified that
you have received this communication in error and that any review,
dissemination, copying, or unauthorized use of this information, or the
taking of any action in reliance on the contents of this information is
strictly prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original message.
Thank you

________________________________

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=sign
off%20mqseries>

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

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU

________________________________

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=sign
off%20mqseries>

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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

rweinger-5mf8PG+

2013-06-25 16:51:08 UTC

Permalink

Yes, it would be a nice attribute.
If the only concern is with test level queues just GET/PUT disable them
and wait for the complaints.

From:
Mike Davidson <MikeDavidson-MaERPT+***@public.gmane.org>
To:
MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Date:
06/25/2013 11:41 AM
Subject:
Housecleaning for MQ
Sent by:
MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>

Hello Everyone,

We have a bad case of "rabbit" queues (for lack of a better term)... Many
of our Qmgrs simply have too many unused queues defined, especially for
the Dev Qmgrs where developers are allowed to define their own queues for
testing. It'd be nice to clean house occasionally, but we're afraid we
might delete a queue that's needed by someone.

So I was thinking (watch out) - Wouldn't it be nice if there was a
queue-level attribute (or attributes) that reflected a date-time stamp (or
even just date) for the last time that queue was read/written to
(Get/Put)? - call the attributes (LASTREAD & LASTWRITE, or LASTGET &
LASTPUT). Then we could run a report every week, month, or whatever to
display the queues not used in the past 6 months/year/whatever and clean
up this mess!!

Before I submit such an RFE, I thought I'd run it by you all and get your
input on how you currently handle this dilemma, as well as your feelings
on such an attribute(s).

Mike Davidson
TSYS Tech Support - WebsphereMQ
MikeDavidson-***@public.gmane.org
----------------------------------------- The information contained in
this communication (including any attachments hereto) is confidential and
is intended solely for the personal and confidential use of the individual
or entity to whom it is addressed. If the reader of this message is not
the intended recipient or an agent responsible for delivering it to the
intended recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying, or
unauthorized use of this information, or the taking of any action in
reliance on the contents of this information is strictly prohibited. If
you have received this communication in error, please notify us
immediately by e-mail, and delete the original message. 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

The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

Jefferson Lowrey

2013-06-25 17:26:42 UTC

Permalink

Hi Dave -
I don't keep score here. Other places, maybe... ;-)

I think Mike didn't know about this and reject it before asking his
question, based on his response to Paul.

I also think that any queue that hasn't been gotten from/written to since
the last time the qmgr was restarted is a reasonable candidate for
deletion, even in DEV. I also think that it's easy enough to find out
when the qmgr was last restarted, and make a determination if it's been
too short, and collect data over several days. And, notice, Mike is
talking about running the command several times, over a month or six
months or etc, and storing the data.

I also think, in Dev, that it's a much more complicated problem than just
"nobody's using this queue right now". A set of queues could be unused
during several sprints of a development project, but still be required to
exist in Dev for a forthcoming sprint. So I'm not sure that there's any
data that a queue manager can actually maintain to make up for project
management communications and documentation issues.

But the function of DIS QSTATUS is the same function Mike was looking to
have added, so I don't think an RFE is a reasonable idea.

Thank you,

Jeff Lowrey

From: "David Awerbuch (BLOOMBERG/ 731 LEXIN)" <dawerbuch-AlFclGv/***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/25/2013 11:05 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

Hi Jeff,

LPUTTIME|LGETTIME
"The time at which the last message was [put to|retrieved from] the queue
since the queue manager started. When no [put|get] time is available,
perhaps because no message has been [put to|retrieved from] the queue
since the queue manager was started, the value is shown as a blank."

Many shops restart their development environments on a regular basis, and
this method will not work when the queue manager is started. I can only
guess Mike thought of this before submitting his original request.

Mike 1
Jeff 0

Dave

----- Original Message -----
From: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
At: Jun 25 2013 11:52:25
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc12260_.htm

Thank you,

Jeff Lowrey

From: Mike Davidson <MikeDavidson-MaERPT+***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/25/2013 09:49 AM
Subject: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

Hello Everyone,

We have a bad case of "rabbit" queues (for lack of a better term)... Many
of our Qmgrs simply have too many unused queues defined, especially for
the Dev Qmgrs where developers are allowed to define their own queues for
testing. It'd be nice to clean house occasionally, but we're afraid we
might delete a queue that's needed by someone.

So I was thinking (watch out) - Wouldn't it be nice if there was a
queue-level attribute (or attributes) that reflected a date-time stamp (or
even just date) for the last time that queue was read/written to
(Get/Put)? - call the attributes (LASTREAD & LASTWRITE, or LASTGET &
LASTPUT). Then we could run a report every week, month, or whatever to
display the queues not used in the past 6 months/year/whatever and clean
up this mess!!

Before I submit such an RFE, I thought I'd run it by you all and get your
input on how you currently handle this dilemma, as well as your feelings
on such an attribute(s).

Mike Davidson
TSYS Tech Support - WebsphereMQ
MikeDavidson-***@public.gmane.org
----------------------------------------- The information contained in
this communication (including any attachments hereto) is confidential and
is intended solely for the personal and confidential use of the individual
or entity to whom it is addressed. If the reader of this message is not
the intended recipient or an agent responsible for delivering it to the
intended recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying, or
unauthorized use of this information, or the taking of any action in
reliance on the contents of this information is strictly prohibited. If
you have received this communication in error, please notify us
immediately by e-mail, and delete the original message. 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

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

<< Seriously? I don't understand why you don't understand what I don't
understand!! >>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

Potkay, Peter M (CTO Architecture + Engineering)

2013-06-25 17:44:52 UTC

Permalink

Check with your monitoring team. Your MQ monitoring solution may keep track of this info.

We use BMTM (a.k.a. QPASA) and it keeps track of how many messages got put or gotten from the queue in its database. If we have a LOCAL* queue that we suspect is eligible for deletion we run a report in BMTM / QPASA and if no messages went thru the queue in a year, open the change control to delete that sucker. After leaving it put/get disabled for a few days.

*MQ doesn't provide stats for Remote or Alias queues, so BMTM/QPASA has no data to report on for those queue types. MQ should provide these stats for these queue types! Vote here please :-D
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=31297

Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: Tuesday, June 25, 2013 1:27 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

Hi Dave -
I don't keep score here. Other places, maybe... ;-)

I think Mike didn't know about this and reject it before asking his question, based on his response to Paul.

I also think that any queue that hasn't been gotten from/written to since the last time the qmgr was restarted is a reasonable candidate for deletion, even in DEV. I also think that it's easy enough to find out when the qmgr was last restarted, and make a determination if it's been too short, and collect data over several days. And, notice, Mike is talking about running the command several times, over a month or six months or etc, and storing the data.

I also think, in Dev, that it's a much more complicated problem than just "nobody's using this queue right now". A set of queues could be unused during several sprints of a development project, but still be required to exist in Dev for a forthcoming sprint. So I'm not sure that there's any data that a queue manager can actually maintain to make up for project management communications and documentation issues.

But the function of DIS QSTATUS is the same function Mike was looking to have added, so I don't think an RFE is a reasonable idea.

Thank you,

Jeff Lowrey

From: "David Awerbuch (BLOOMBERG/ 731 LEXIN)" <***@bloomberg.net<mailto:dawerbuch-AlFclGv/***@public.gmane.org>>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80Ties2YCUG/***@public.gmane.orgniwien.ac.at>,
Date: 06/25/2013 11:05 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>>
________________________________

Hi Jeff,

LPUTTIME|LGETTIME
"The time at which the last message was [put to|retrieved from] the queue since the queue manager started. When no [put|get] time is available, perhaps because no message has been [put to|retrieved from] the queue since the queue manager was started, the value is shown as a blank."

Many shops restart their development environments on a regular basis, and this method will not work when the queue manager is started. I can only guess Mike thought of this before submitting his original request.

Mike 1
Jeff 0

Dave

----- Original Message -----
From: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgN.AC.AT>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
At: Jun 25 2013 11:52:25
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc12260_.htm

Thank you,

Jeff Lowrey

From: Mike Davidson <MikeDavidson-MaERPT+***@public.gmane.org<mailto:***@TSYS.COM>>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80Ties2YCUG/***@public.gmane.orgniwien.ac.at>,
Date: 06/25/2013 09:49 AM
Subject: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>>
________________________________

Hello Everyone,

We have a bad case of "rabbit" queues (for lack of a better term)... Many of our Qmgrs simply have too many unused queues defined, especially for the Dev Qmgrs where developers are allowed to define their own queues for testing. It'd be nice to clean house occasionally, but we're afraid we might delete a queue that's needed by someone.

So I was thinking (watch out) - Wouldn't it be nice if there was a queue-level attribute (or attributes) that reflected a date-time stamp (or even just date) for the last time that queue was read/written to (Get/Put)? - call the attributes (LASTREAD & LASTWRITE, or LASTGET & LASTPUT). Then we could run a report every week, month, or whatever to display the queues not used in the past 6 months/year/whatever and clean up this mess!!

Before I submit such an RFE, I thought I'd run it by you all and get your input on how you currently handle this dilemma, as well as your feelings on such an attribute(s).

Mike Davidson
TSYS Tech Support - WebsphereMQ
MikeDavidson-***@public.gmane.org<mailto:MikeDavidson-***@public.gmane.org>
----------------------------------------- The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

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

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

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

<< Seriously? I don't understand why you don't understand what I don't understand!! >>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
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.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

Potkay, Peter M (CTO Architecture + Engineering)

2013-06-25 17:54:33 UTC

Permalink

Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.255.23.254]
Content-Type: multipart/alternative;
boundary="_000_9BB766F505133C498D6D60FB74AA403CCFC9AD1HFDEXC408ad1prod_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.25.174229
X-PMX-Spam: Gauge=* Probability=10%, Report='
AT_TLD 0.1, HTML_90_100 0.1, HTML_95_100 0.1, HTML_98_100 0.1, HTML_99_100 0.1, SUPERLONG_LINE 0.05, BODY_SIZE_10000_PLUS 0, FROM_NAME_PHRASE 0, URI_ENDS_IN_HTML 0, WEBMAIL_SOURCE 0, WEBMAIL_XOIP 0, WEBMAIL_X_IP_HDR 0, __ANY_URI 0, __CANPHARM_UNSUB_LINK 0, __CP_MEDIA_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_HTML 0, __HAS_MSGID 0, __HAS_XOIP 0, __HTML_FONT_BLUE 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_PHRASE_7 0, __STYLE_RATWARE_NEG 0, __SUBJ_ALPHA_NEGATE 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0, __URI_NS '

--_000_9BB766F505133C498D6D60FB74AA403CCFC9AD1HFDEXC408ad1prod_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

They rejected my RFE with this reason:
"While this is something we would like to do, it is unlikely to be implemen=
ted in any foreseeable timeframe. Therefore this requirement is being rejec=
ted. However, there is similar information available via the Application Ac=
tivity Trace Reports that could be used to monitor usage of queues."

Um, OK.

Hey Peter, was this remote queue used in the past year?
Beats me, we'll never know. But let me trace it for a year...come see me in=
2014!

<sigh>

Peter Potkay

From: Potkay, Peter M (CTO Architecture + Engineering)
Sent: Tuesday, June 25, 2013 1:45 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: RE: Housecleaning for MQ

Check with your monitoring team. Your MQ monitoring solution may keep track=
of this info.

We use BMTM (a.k.a. QPASA) and it keeps track of how many messages got put =
or gotten from the queue in its database. If we have a LOCAL* queue that we=
suspect is eligible for deletion we run a report in BMTM / QPASA and if no=
messages went thru the queue in a year, open the change control to delete =
that sucker. After leaving it put/get disabled for a few days.

*MQ doesn't provide stats for Remote or Alias queues, so BMTM/QPASA has no =
data to report on for those queue types. MQ should provide these stats for =
these queue types! Vote here please :-D
http://www.ibm.com/developerworks/rfe/execute?use_case=3DviewRfe&CR_ID=3D31=
297

Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf O=
f Jefferson Lowrey
Sent: Tuesday, June 25, 2013 1:27 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.org=
AC.AT>
Subject: Re: Housecleaning for MQ

Hi Dave -
I don't keep score here. Other places, maybe... ;-)

I think Mike didn't know about this and reject it before asking his questio=
n, based on his response to Paul.

I also think that any queue that hasn't been gotten from/written to since t=
he last time the qmgr was restarted is a reasonable candidate for deletion,=
even in DEV. I also think that it's easy enough to find out when the qmgr=
was last restarted, and make a determination if it's been too short, and c=
ollect data over several days. And, notice, Mike is talking about running=
the command several times, over a month or six months or etc, and storing =
the data.

I also think, in Dev, that it's a much more complicated problem than just "=
nobody's using this queue right now". A set of queues could be unused duri=
ng several sprints of a development project, but still be required to exist=
in Dev for a forthcoming sprint. So I'm not sure that there's any data t=
hat a queue manager can actually maintain to make up for project management=
communications and documentation issues.

But the function of DIS QSTATUS is the same function Mike was looking to ha=
ve added, so I don't think an RFE is a reasonable idea.

Thank you,

Jeff Lowrey

From: "David Awerbuch (BLOOMBERG/ 731 LEXIN)" <***@bloomberg.n=
et<mailto:dawerbuch-AlFclGv/***@public.gmane.org>>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80Ties2YCUG/***@public.gmane.org=
niwien.ac.at>,
Date: 06/25/2013 11:05 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQ=
SERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>>
________________________________

Hi Jeff,

LPUTTIME|LGETTIME
"The time at which the last message was [put to|retrieved from] the queue s=
ince the queue manager started. When no [put|get] time is available, perhap=
s because no message has been [put to|retrieved from] the queue since the q=
ueue manager was started, the value is shown as a blank."

Many shops restart their development environments on a regular basis, and t=
his method will not work when the queue manager is started. I can only gues=
s Mike thought of this before submitting his original request.

Mike 1
Jeff 0

Dave

----- Original Message -----
From: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.org=
N.AC.AT>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.org=
AC.AT>
At: Jun 25 2013 11:52:25
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc12260_.=
htm

Thank you,

Jeff Lowrey

From: Mike Davidson <MikeDavidson-MaERPT+***@public.gmane.org<mailto:***@TSYS.=
COM>>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80Ties2YCUG/***@public.gmane.org=
niwien.ac.at>,
Date: 06/25/2013 09:49 AM
Subject: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQ=
SERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>>
________________________________

Hello Everyone,

We have a bad case of "rabbit" queues (for lack of a better term)... Many o=
f our Qmgrs simply have too many unused queues defined, especially for the =
Dev Qmgrs where developers are allowed to define their own queues for testi=
ng. It'd be nice to clean house occasionally, but we're afraid we might del=
ete a queue that's needed by someone.

So I was thinking (watch out) - Wouldn't it be nice if there was a queue-le=
vel attribute (or attributes) that reflected a date-time stamp (or even jus=
t date) for the last time that queue was read/written to (Get/Put)? - call =
the attributes (LASTREAD & LASTWRITE, or LASTGET & LASTPUT). Then we could =
run a report every week, month, or whatever to display the queues not used =
in the past 6 months/year/whatever and clean up this mess!!

Before I submit such an RFE, I thought I'd run it by you all and get your i=
nput on how you currently handle this dilemma, as well as your feelings on =
such an attribute(s).

Mike Davidson
TSYS Tech Support - WebsphereMQ
MikeDavidson-***@public.gmane.org<mailto:MikeDavidson-***@public.gmane.org>
----------------------------------------- The information contained in this=
communication (including any attachments hereto) is confidential and is in=
tended solely for the personal and confidential use of the individual or en=
tity to whom it is addressed. If the reader of this message is not the inte=
nded recipient or an agent responsible for delivering it to the intended re=
cipient, you are hereby notified that you have received this communication =
in error and that any review, dissemination, copying, or unauthorized use o=
f this information, or the taking of any action in reliance on the contents=
of this information is strictly prohibited. If you have received this comm=
unication in error, please notify us immediately by e-mail, and delete the =
original message. Thank you
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Mana=
ge Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=3D=
mqser-l&A=3D1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subj=
ect=3DUnsubscribe&BODY=3Dsignoff%20mqseries>

Instructions for managing your mailing list subscription are provided in th=
e Listserv General Users Guide available at http://www.lsoft.com<http://www=
.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Mana=
ge Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=3D=
mqser-l&A=3D1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subj=
ect=3DUnsubscribe&BODY=3Dsignoff%20mqseries>

Instructions for managing your mailing list subscription are provided in th=
e Listserv General Users Guide available at http://www.lsoft.com<http://www=
.lsoft.com/resources/manuals.asp>

<< Seriously? I don't understand why you don't understand what I don't unde=
rstand!! >>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Mana=
ge Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=3D=
mqser-l&A=3D1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subj=
ect=3DUnsubscribe&BODY=3Dsignoff%20mqseries>

Instructions for managing your mailing list subscription are provided in th=
e Listserv General Users Guide available at http://www.lsoft.com<http://www=
.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addr=
essee and may contain proprietary, confidential and/or privileged informati=
on. If you are not the intended recipient, any use, copying, disclosure, d=
issemination or distribution is strictly prohibited. If you are not the in=
tended recipient, please notify the sender immediately by return e-mail, de=
lete this communication and destroy all copies.
************************************************************

--_000_9BB766F505133C498D6D60FB74AA403CCFC9AD1HFDEXC408ad1prod_
Content-Type: text/html; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:m=3D"http://schema=
s.microsoft.com/office/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html=
40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii">
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style></style>
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
They rejected my RFE with=
this reason:<o:p></o:p>
“While this is some=
thing we would like to do, it is unlikely to be implemented in any foreseea=
ble timeframe. Therefore this requirement is being rejected. However,
there is similar information available via the Application Activity Trace =
Reports that could be used to monitor usage of queues.”<o:p></o:p></s=
pan>
<o:p> </o:p><=
/p>
Um, OK.<o:p></o:p>=

<o:p> </o:p><=
/p>
<o:p> </o:p><=
/p>
Hey Peter, was this remot=
e queue used in the past year?<o:p></o:p>
Beats me, we’ll nev=
er know. But let me trace it for a year…come see me in 2014!<o:p></o:=
p>
<o:p> </o:p><=
/p>
<sigh><o:p></o:p></=
span>
<o:p> </o:p><=
/p>
<o:p> </o:p><=
/p>
<o:p> </o:p><=
/p>
<div>
Peter Potkay
 
 
<o:p></o:p>
</div>
<o:p> </o:p><=
/p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
From: Potkay, =
Peter M (CTO Architecture + Engineering)
 
Sent: Tuesday, June 25, 2013 1:45 PM 
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org 
Subject: RE: Housecleaning for MQ<o:p></o:p>
</div>
</div>
<o:p> </o:p>
Check with your monitorin=
g team. Your MQ monitoring solution may keep track of this info.<o:p></o:p>=

<o:p> </o:p><=
/p>
We use BMTM (a.k.a. QPASA=
) and it keeps track of how many messages got put or gotten from the queue =
in its database. If we have a LOCAL* queue that we suspect
is eligible for deletion we run a report in BMTM / QPASA and if no message=
s went thru the queue in a year, open the change control to delete that suc=
ker. After leaving it put/get disabled for a few days.<o:p></o:p>
<o:p> </o:p><=
/p>
*MQ doesn’t provide=
stats for Remote or Alias queues, so BMTM/QPASA has no data to report on f=
or those queue types. MQ should provide these stats for these
queue types! Vote here please :-D<o:p></o:p>
<a href=3D"http://www.ibm=
.com/developerworks/rfe/execute?use_case=3DviewRfe&CR_ID=3D31297">http:=
//www.ibm.com/developerworks/rfe/execute?use_case=3DviewRfe&CR_ID=3D312=
97</a><o:p></o:p>
<o:p> </o:p><=
/p>
<o:p> </o:p><=
/p>
<o:p> </o:p><=
/p>
<o:p> </o:p><=
/p>
<=
b>Peter Potkay
<o:p></o:p>
<o:p> </o:p><=
/p>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
From: MQSeries=
List [<a href=3D"mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org">mailto:MQSERIE=
***@LISTSERV.MEDUNIWIEN.AC.AT</a>]
On Behalf Of Jefferson Lowrey 
Sent: Tuesday, June 25, 2013 1:27 PM 
To: <a href=3D"mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org">***@L=
ISTSERV.MEDUNIWIEN.AC.AT</a> 
Subject: Re: Housecleaning for MQ<o:p></o:p>
</div>
<o:p> </o:p>
Hi Dave -
 
I don't keep score here.  Other places, maybe... ;-)
 
 
I think Mike didn't know about this and reject it before asking =
his question, based on his response to Paul.
 
 
I also think that any queue that hasn't been gotten from/written=
to since the last time the qmgr was restarted is a reasonable candidate fo=
r deletion, even in DEV.  I also think that it's easy
enough to find out when the qmgr was last restarted, and make a determinat=
ion if it's been too short, and collect data over several days.   And,=
notice, Mike is talking about running the command several times, over a mo=
nth or six months or etc, and storing
the data.   
 
I also think, in Dev, that it's a much more complicated problem =
than just "nobody's using this queue right now".  A set of q=
ueues could be unused during several sprints of a development project,
but still be required to exist in Dev for a forthcoming sprint.   So =
I'm not sure that there's any data that a queue manager can actually mainta=
in to make up for project management communications and documentation issue=
s.
 
 
But the function of DIS QSTATUS is the same function Mike was lo=
oking to have added, so I don't think an RFE is a reasonable idea.
 
 
Thank you, 
 
Jeff Lowrey 
 
 
 
From:        &=
quot;David Awerbuch (BLOOMBERG/ 731 LEXIN)" <<a href=3D"mailto:dawe=
rbuch-AlFclGv/***@public.gmane.org">dawerbuch-AlFclGv/***@public.gmane.org</a>>
 
To:        <=
a href=3D"mailto:MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org">MQSERIES-JX7+OpRa80Ties2YCUG/***@public.gmane.org=
niwien.ac.at</a>,
 
Date:        0=
6/25/2013 11:05 AM
 
Subject:        Re: [MQSERIES] Housecleaning for MQ
 
Sent by:        MQSeries List <<a href=3D"mailto:MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org">M=
QSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org</a>>
<o:p></o:p>
<div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">
<hr size=3D"2" width=3D"100%" noshade=3D"" style=3D"color:#A0A0A0" align=3D=
"center">
</div>
 
 
 
Hi Jeff, 
 
LPUTTIME|LGETTIME
 
"The time at which the last message was [put to|retrieved f=
rom] the queue since the queue manager started. When no [put|get] time is a=
vailable, perhaps because no message has been [put to|retrieved
from] the queue since the queue manager was started, the value is shown as=
a blank."
 
 
Many shops restart their development environments on a regular b=
asis, and this method will not work when the queue manager is started. I ca=
n only guess Mike thought of this before submitting his
original request. 
 
Mike 1 
Jeff 0 
 
Dave 
 
 
----- =
Original Message ----- 
From: <a href=3D"mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org">***@LISTS=
ERV.MEDUNIWIEN.AC.AT</a> 
To: <a href=3D"mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org">***@LISTSER=
V.MEDUNIWIEN.AC.AT</a> 
At: Jun 25 2013 11:52:25 
<a href=3D"http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.do=
c/sc12260_.htm">http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/top=
ic/com.ibm.mq.doc/sc12260_.htm</a> 
 
Thank you, 
 
Jeff Lowrey 
 
 
 
From:        Mike Davidson <<a href=
=3D"mailto:MikeDavidson-MaERPT+***@public.gmane.org">MikeDavidson-MaERPT+***@public.gmane.org</a>><span=
style=3D"font-size:10.0pt;font-family:"Arial","sans-serif&q=
uot;">
 
To:        <a href=3D"mailto:MQSERIES@=
listserv.meduniwien.ac.at">MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org</a>,
 
Date:        06/25/2013 09:49 AM
 
Subject:        [MQSERIES] Housecleani=
ng for MQ
 
Sent by:        MQSeries List <<a h=
ref=3D"mailto:MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org">MQSERIES-JX7+***@public.gmane.org=
ien.ac.at</a>>
<o:p></o:p>
<div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">
<hr size=3D"2" width=3D"100%" align=3D"center">
</div>
 
 
 
Hello Everyone, 
 
We have a bad case of "rabbit" queues (for lack of a better term)=
... Many of our Qmgrs simply have too many unused queues defined, especiall=
y for the Dev Qmgrs where developers are allowed to define their own queues=
for testing. It'd be nice to clean house
occasionally, but we're afraid we might delete a queue that's needed by so=
meone.
 
 
So I was thinking (watch out) - Wouldn't it be nice if there was a queue-le=
vel attribute (or attributes) that reflected a date-time stamp (or even jus=
t date) for the last time that queue was read/written to (Get/Put)? - call =
the attributes (LASTREAD & LASTWRITE,
or LASTGET & LASTPUT). Then we could run a report every week, month, o=
r whatever to display the queues not used in the past 6 months/year/whateve=
r and clean up this mess!!
 
 
Before I submit such an RFE, I thought I'd run it by you all and get your i=
nput on how you currently handle this dilemma, as well as your feelings on =
such an attribute(s).
 
 
Mike Davidson 
TSYS Tech Support - WebsphereMQ 
<a href=3D"mailto:MikeDavidson-***@public.gmane.org">MikeDavidson-***@public.gmane.org</a><s=
pan style=3D"font-family:"Arial","sans-serif""> 
----------------------------------------- The information contained in this=
communication (including any attachments hereto) is confidential and is in=
tended solely for the personal and confidential use of the individual or en=
tity to whom it is addressed. If
the reader of this message is not the intended recipient or an agent respo=
nsible for delivering it to the intended recipient, you are hereby notified=
that you have received this communication in error and that any review, di=
ssemination, copying, or unauthorized
use of this information, or the taking of any action in reliance on the co=
ntents of this information is strictly prohibited. If you have received thi=
s communication in error, please notify us immediately by e-mail, and delet=
e the original message. Thank you
<o:p></o:p>
<div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">
<hr size=3D"2" width=3D"100%" align=3D"center">
</div>
<a href=
=3D"http://listserv.meduniwien.ac.at/archives/mqser-l.html">List=
Archive</a>
- <a href=3D"http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=3Dm=
qser-l&A=3D1">Manage Your List Settings</a><span styl=
e=3D"font-size:10.0pt;font-family:"Arial","sans-serif""=

<a href=3D"mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=3DUnsub=
scribe&BODY=3Dsignoff%20mqseries">Unsubscribe</a><spa=
n style=3D"font-size:10.0pt;font-family:"Arial","sans-serif&=
quot;">
<o:p></o:p>
Instructions for=
managing your mailing list subscription are provided in the Listserv Gener=
al Users Guide available at
<a href=3D"http://www.lsoft.com/resources/manuals.asp">=
http://www.lsoft.com</a>
<o:p></o:p>
 
 
<< Seriously? I don't understand why you don't understand what I don'=
t understand!! >>
<o:p></o:p>
<o:p> </o:p>
<div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">
<hr size=3D"2" width=3D"100%" align=3D"center">
</div>
<a href=3D"http://listserv.meduniwien.ac.at/archi=
ves/mqser-l.html">List Archive</a> -
<a href=3D"http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=3Dmqser-l&amp=
;A=3D1">Manage Your List Settings</a> -
<a href=3D"mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=3DUnsubscribe&=
amp;BODY=3Dsignoff%20mqseries">
Unsubscribe</a> <o:p></o:p>
Instructions for managing your mailing list subscription are provided=
in the Listserv General Users Guide available at
<a href=3D"http://www.lsoft.com/resources/manuals.asp">http://www.lsoft.com=
</a> <o:p>
</o:p>
</div>
************************************************************ 
This communication, including attachments, is for the exclusive use of addr=
essee and may contain proprietary, confidential and/or privileged informati=
on.  If you are not the intended recipient, any use, copying, disclosu=
re, 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. 
************************************************************</body>
</html>

--_000_9BB766F505133C498D6D60FB74AA403CCFC9AD1HFDEXC408ad1prod_--

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

GINA MCCARTHY

2013-06-25 17:59:29 UTC

Permalink

I think it's a great idea to keep those fields. Why should they refresh
when the qmgr gets recycled?

I have production queues that are only used a few times a year. Also, we
are going through a large ERP implementation over the last few years so,
many production queues are no longer used once the app has been
migrated.

We are currently upgrading and replatforming our WMQ distributed
environment. It's been a bear in trying to determine, in each
environment, the last time each of the hundreds of queues were last
used. This would have (could be) been a godsend. I am finding about 30%
haven't been used in years.

DIS QSTATUS would not have helped in my case.

Gina

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
Behalf Of Jefferson Lowrey
Sent: Tuesday, June 25, 2013 1:27 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

Hi Dave -
I don't keep score here. Other places, maybe... ;-)

I think Mike didn't know about this and reject it before asking his
question, based on his response to Paul.

I also think that any queue that hasn't been gotten from/written to
since the last time the qmgr was restarted is a reasonable candidate for
deletion, even in DEV. I also think that it's easy enough to find out
when the qmgr was last restarted, and make a determination if it's been
too short, and collect data over several days. And, notice, Mike is
talking about running the command several times, over a month or six
months or etc, and storing the data.

I also think, in Dev, that it's a much more complicated problem than
just "nobody's using this queue right now". A set of queues could be
unused during several sprints of a development project, but still be
required to exist in Dev for a forthcoming sprint. So I'm not sure
that there's any data that a queue manager can actually maintain to make
up for project management communications and documentation issues.

But the function of DIS QSTATUS is the same function Mike was looking to
have added, so I don't think an RFE is a reasonable idea.

Thank you,

Jeff Lowrey

From: "David Awerbuch (BLOOMBERG/ 731 LEXIN)"
<dawerbuch-AlFclGv/***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/25/2013 11:05 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

________________________________

Hi Jeff,

LPUTTIME|LGETTIME
"The time at which the last message was [put to|retrieved from] the
queue since the queue manager started. When no [put|get] time is
available, perhaps because no message has been [put to|retrieved from]
the queue since the queue manager was started, the value is shown as a
blank."

Many shops restart their development environments on a regular basis,
and this method will not work when the queue manager is started. I can
only guess Mike thought of this before submitting his original request.

Mike 1
Jeff 0

Dave

----- Original Message -----
From: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
At: Jun 25 2013 11:52:25
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc1226
0_.htm
<http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc122
60_.htm>

Thank you,

Jeff Lowrey

From: Mike Davidson <MikeDavidson-MaERPT+***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/25/2013 09:49 AM
Subject: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

________________________________

Hello Everyone,

We have a bad case of "rabbit" queues (for lack of a better term)...
Many of our Qmgrs simply have too many unused queues defined, especially
for the Dev Qmgrs where developers are allowed to define their own
queues for testing. It'd be nice to clean house occasionally, but we're
afraid we might delete a queue that's needed by someone.

So I was thinking (watch out) - Wouldn't it be nice if there was a
queue-level attribute (or attributes) that reflected a date-time stamp
(or even just date) for the last time that queue was read/written to
(Get/Put)? - call the attributes (LASTREAD & LASTWRITE, or LASTGET &
LASTPUT). Then we could run a report every week, month, or whatever to
display the queues not used in the past 6 months/year/whatever and clean
up this mess!!

Before I submit such an RFE, I thought I'd run it by you all and get
your input on how you currently handle this dilemma, as well as your
feelings on such an attribute(s).

Mike Davidson
TSYS Tech Support - WebsphereMQ
MikeDavidson-***@public.gmane.org
----------------------------------------- The information contained in
this communication (including any attachments hereto) is confidential
and is intended solely for the personal and confidential use of the
individual or entity to whom it is addressed. If the reader of this
message is not the intended recipient or an agent responsible for
delivering it to the intended recipient, you are hereby notified that
you have received this communication in error and that any review,
dissemination, copying, or unauthorized use of this information, or the
taking of any action in reliance on the contents of this information is
strictly prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original message.
Thank you

________________________________

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=sign
off%20mqseries>

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

________________________________

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=sign
off%20mqseries>

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

<< Seriously? I don't understand why you don't understand what I don't
understand!! >>

________________________________

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=sign
off%20mqseries>

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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

Potkay, Peter M (CTO Architecture + Engineering)

2013-06-25 18:06:56 UTC

Permalink

Add my vote for not resetting these attributes when the QM is restarted. Seems odd that it was implemented to reset when the QM was started (or shut down) - I don't see any end user benefit for the reset to occur at that time. Perhaps there were significant implications in the MQ internals.

Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of GINA MCCARTHY
Sent: Tuesday, June 25, 2013 1:59 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

I think it's a great idea to keep those fields. Why should they refresh when the qmgr gets recycled?

I have production queues that are only used a few times a year. Also, we are going through a large ERP implementation over the last few years so, many production queues are no longer used once the app has been migrated.

We are currently upgrading and replatforming our WMQ distributed environment. It's been a bear in trying to determine, in each environment, the last time each of the hundreds of queues were last used. This would have (could be) been a godsend. I am finding about 30% haven't been used in years.

DIS QSTATUS would not have helped in my case.

Gina

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: Tuesday, June 25, 2013 1:27 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Housecleaning for MQ

Hi Dave -
I don't keep score here. Other places, maybe... ;-)

I think Mike didn't know about this and reject it before asking his question, based on his response to Paul.

I also think that any queue that hasn't been gotten from/written to since the last time the qmgr was restarted is a reasonable candidate for deletion, even in DEV. I also think that it's easy enough to find out when the qmgr was last restarted, and make a determination if it's been too short, and collect data over several days. And, notice, Mike is talking about running the command several times, over a month or six months or etc, and storing the data.

I also think, in Dev, that it's a much more complicated problem than just "nobody's using this queue right now". A set of queues could be unused during several sprints of a development project, but still be required to exist in Dev for a forthcoming sprint. So I'm not sure that there's any data that a queue manager can actually maintain to make up for project management communications and documentation issues.

But the function of DIS QSTATUS is the same function Mike was looking to have added, so I don't think an RFE is a reasonable idea.

Thank you,

Jeff Lowrey

From: "David Awerbuch (BLOOMBERG/ 731 LEXIN)" <***@bloomberg.net<mailto:dawerbuch-AlFclGv/***@public.gmane.org>>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80Ties2YCUG/***@public.gmane.orgniwien.ac.at>,
Date: 06/25/2013 11:05 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>>
________________________________

Hi Jeff,

LPUTTIME|LGETTIME
"The time at which the last message was [put to|retrieved from] the queue since the queue manager started. When no [put|get] time is available, perhaps because no message has been [put to|retrieved from] the queue since the queue manager was started, the value is shown as a blank."

Many shops restart their development environments on a regular basis, and this method will not work when the queue manager is started. I can only guess Mike thought of this before submitting his original request.

Mike 1
Jeff 0

Dave

----- Original Message -----
From: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgN.AC.AT>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
At: Jun 25 2013 11:52:25
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc12260_.htm

Thank you,

Jeff Lowrey

From: Mike Davidson <MikeDavidson-MaERPT+***@public.gmane.org<mailto:***@TSYS.COM>>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80Ties2YCUG/***@public.gmane.orgniwien.ac.at>,
Date: 06/25/2013 09:49 AM
Subject: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>>
________________________________

Hello Everyone,

We have a bad case of "rabbit" queues (for lack of a better term)... Many of our Qmgrs simply have too many unused queues defined, especially for the Dev Qmgrs where developers are allowed to define their own queues for testing. It'd be nice to clean house occasionally, but we're afraid we might delete a queue that's needed by someone.

So I was thinking (watch out) - Wouldn't it be nice if there was a queue-level attribute (or attributes) that reflected a date-time stamp (or even just date) for the last time that queue was read/written to (Get/Put)? - call the attributes (LASTREAD & LASTWRITE, or LASTGET & LASTPUT). Then we could run a report every week, month, or whatever to display the queues not used in the past 6 months/year/whatever and clean up this mess!!

Before I submit such an RFE, I thought I'd run it by you all and get your input on how you currently handle this dilemma, as well as your feelings on such an attribute(s).

Mike Davidson
TSYS Tech Support - WebsphereMQ
MikeDavidson-***@public.gmane.org<mailto:MikeDavidson-***@public.gmane.org>
----------------------------------------- The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

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

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

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

<< Seriously? I don't understand why you don't understand what I don't understand!! >>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

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

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
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.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

Bob Juch

2013-06-25 18:47:13 UTC

Permalink

Peter,

If the values were to survive a shutdown they'd have to be written to
disk after each change. That would be a lot of overhead.

Bob Juch
Juch Services LLC

On Tue, Jun 25, 2013 at 2:06 PM, Potkay, Peter M (CTO Architecture +

Post by Potkay, Peter M (CTO Architecture + Engineering)
Add my vote for not resetting these attributes when the QM is restarted.
Seems odd that it was implemented to reset when the QM was started (or shut
down) – I don’t see any end user benefit for the reset to occur at that
time. Perhaps there were significant implications in the MQ internals.
Peter Potkay
GINA MCCARTHY
Sent: Tuesday, June 25, 2013 1:59 PM
Subject: Re: Housecleaning for MQ
I think it’s a great idea to keep those fields. Why should they refresh when
the qmgr gets recycled?
I have production queues that are only used a few times a year. Also, we are
going through a large ERP implementation over the last few years so, many
production queues are no longer used once the app has been migrated.
We are currently upgrading and replatforming our WMQ distributed
environment. It’s been a bear in trying to determine, in each environment,
the last time each of the hundreds of queues were last used. This would have
(could be) been a godsend. I am finding about 30% haven’t been used in
years.
DIS QSTATUS would not have helped in my case.
Gina
Jefferson Lowrey
Sent: Tuesday, June 25, 2013 1:27 PM
Subject: Re: Housecleaning for MQ
Hi Dave -
I don't keep score here. Other places, maybe... ;-)
I think Mike didn't know about this and reject it before asking his
question, based on his response to Paul.
I also think that any queue that hasn't been gotten from/written to since
the last time the qmgr was restarted is a reasonable candidate for deletion,
even in DEV. I also think that it's easy enough to find out when the qmgr
was last restarted, and make a determination if it's been too short, and
collect data over several days. And, notice, Mike is talking about running
the command several times, over a month or six months or etc, and storing
the data.
I also think, in Dev, that it's a much more complicated problem than just
"nobody's using this queue right now". A set of queues could be unused
during several sprints of a development project, but still be required to
exist in Dev for a forthcoming sprint. So I'm not sure that there's any
data that a queue manager can actually maintain to make up for project
management communications and documentation issues.
But the function of DIS QSTATUS is the same function Mike was looking to
have added, so I don't think an RFE is a reasonable idea.
Thank you,
Jeff Lowrey
From: "David Awerbuch (BLOOMBERG/ 731 LEXIN)"
Date: 06/25/2013 11:05 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
________________________________
Hi Jeff,
LPUTTIME|LGETTIME
"The time at which the last message was [put to|retrieved from] the queue
since the queue manager started. When no [put|get] time is available,
perhaps because no message has been [put to|retrieved from] the queue since
the queue manager was started, the value is shown as a blank."
Many shops restart their development environments on a regular basis, and
this method will not work when the queue manager is started. I can only
guess Mike thought of this before submitting his original request.
Mike 1
Jeff 0
Dave
----- Original Message -----
At: Jun 25 2013 11:52:25
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc12260_.htm
Thank you,
Jeff Lowrey
Date: 06/25/2013 09:49 AM
Subject: [MQSERIES] Housecleaning for MQ
________________________________
Hello Everyone,
We have a bad case of "rabbit" queues (for lack of a better term)... Many of
our Qmgrs simply have too many unused queues defined, especially for the Dev
Qmgrs where developers are allowed to define their own queues for testing.
It'd be nice to clean house occasionally, but we're afraid we might delete a
queue that's needed by someone.
So I was thinking (watch out) - Wouldn't it be nice if there was a
queue-level attribute (or attributes) that reflected a date-time stamp (or
even just date) for the last time that queue was read/written to (Get/Put)?
- call the attributes (LASTREAD & LASTWRITE, or LASTGET & LASTPUT). Then we
could run a report every week, month, or whatever to display the queues not
used in the past 6 months/year/whatever and clean up this mess!!
Before I submit such an RFE, I thought I'd run it by you all and get your
input on how you currently handle this dilemma, as well as your feelings on
such an attribute(s).
Mike Davidson
TSYS Tech Support - WebsphereMQ
----------------------------------------- The information contained in this
communication (including any attachments hereto) is confidential and is
intended solely for the personal and confidential use of the individual or
entity to whom it is addressed. If the reader of this message is not the
intended recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this communication
in error and that any review, dissemination, copying, or unauthorized use of
this information, or the taking of any action in reliance on the contents of
this information is strictly prohibited. If you have received this
communication in error, please notify us immediately by e-mail, and delete
the original message. 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
________________________________
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
<< Seriously? I don't understand why you don't understand what I don't
understand!! >>
________________________________
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
************************************************************
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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Ram

2013-06-25 18:58:11 UTC

Permalink

Rather rely on reset qstats output - queue/dequeue count is accurate reflection of number of messages arrived/processed

Ram Ramanathan

I think itâs a great idea to keep those fields. Why should they refresh when the qmgr gets recycled?
I have production queues that are only used a few times a year. Also, we are going through a large ERP implementation over the last few years so, many production queues are no longer used once the app has been migrated.
We are currently upgrading and replatforming our WMQ distributed environment. Itâs been a bear in trying to determine, in each environment, the last time each of the hundreds of queues were last used. This would have (could be) been a godsend. I am finding about 30% havenât been used in years.
DIS QSTATUS would not have helped in my case.
Gina
Sent: Tuesday, June 25, 2013 1:27 PM
Subject: Re: Housecleaning for MQ
Hi Dave -
I don't keep score here. Other places, maybe... ;-)
I think Mike didn't know about this and reject it before asking his question, based on his response to Paul.
I also think that any queue that hasn't been gotten from/written to since the last time the qmgr was restarted is a reasonable candidate for deletion, even in DEV. I also think that it's easy enough to find out when the qmgr was last restarted, and make a determination if it's been too short, and collect data over several days. And, notice, Mike is talking about running the command several times, over a month or six months or etc, and storing the data.
I also think, in Dev, that it's a much more complicated problem than just "nobody's using this queue right now". A set of queues could be unused during several sprints of a development project, but still be required to exist in Dev for a forthcoming sprint. So I'm not sure that there's any data that a queue manager can actually maintain to make up for project management communications and documentation issues.
But the function of DIS QSTATUS is the same function Mike was looking to have added, so I don't think an RFE is a reasonable idea.
Thank you,
Jeff Lowrey
Date: 06/25/2013 11:05 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
Hi Jeff,
LPUTTIME|LGETTIME
"The time at which the last message was [put to|retrieved from] the queue since the queue manager started. When no [put|get] time is available, perhaps because no message has been [put to|retrieved from] the queue since the queue manager was started, the value is shown as a blank."
Many shops restart their development environments on a regular basis, and this method will not work when the queue manager is started. I can only guess Mike thought of this before submitting his original request.
Mike 1
Jeff 0
Dave
----- Original Message -----
At: Jun 25 2013 11:52:25
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc12260_.htm
Thank you,
Jeff Lowrey
Date: 06/25/2013 09:49 AM
Subject: [MQSERIES] Housecleaning for MQ
Hello Everyone,
We have a bad case of "rabbit" queues (for lack of a better term)... Many of our Qmgrs simply have too many unused queues defined, especially for the Dev Qmgrs where developers are allowed to define their own queues for testing. It'd be nice to clean house occasionally, but we're afraid we might delete a queue that's needed by someone.
So I was thinking (watch out) - Wouldn't it be nice if there was a queue-level attribute (or attributes) that reflected a date-time stamp (or even just date) for the last time that queue was read/written to (Get/Put)? - call the attributes (LASTREAD & LASTWRITE, or LASTGET & LASTPUT). Then we could run a report every week, month, or whatever to display the queues not used in the past 6 months/year/whatever and clean up this mess!!
Before I submit such an RFE, I thought I'd run it by you all and get your input on how you currently handle this dilemma, as well as your feelings on such an attribute(s).
Mike Davidson
TSYS Tech Support - WebsphereMQ
----------------------------------------- The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. 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
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
<< Seriously? I don't understand why you don't understand what I don't understand!! >>
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

Potkay, Peter M (CTO Architecture + Engineering)

2013-06-25 19:26:42 UTC

Permalink

They only need to be written to disk at QM shutdown. Yeah, I guess if there is an abnormal termination of the QM you can't be sure these stats get written to disk. So I suppose its performance related that these stats don't persist. A busy QM with lots of queues would have a tremendous amount of stats needing to be constantly written to disk.

Peter Potkay

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Bob Juch
Sent: Tuesday, June 25, 2013 2:47 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

Peter,

If the values were to survive a shutdown they'd have to be written to disk after each change. That would be a lot of overhead.

Bob Juch
Juch Services LLC

On Tue, Jun 25, 2013 at 2:06 PM, Potkay, Peter M (CTO Architecture +

Post by Potkay, Peter M (CTO Architecture + Engineering)
Add my vote for not resetting these attributes when the QM is restarted.
Seems odd that it was implemented to reset when the QM was started (or
shut
down) - I don't see any end user benefit for the reset to occur at
that time. Perhaps there were significant implications in the MQ internals.
Peter Potkay
Behalf Of GINA MCCARTHY
Sent: Tuesday, June 25, 2013 1:59 PM
Subject: Re: Housecleaning for MQ
I think it's a great idea to keep those fields. Why should they
refresh when the qmgr gets recycled?
I have production queues that are only used a few times a year. Also,
we are going through a large ERP implementation over the last few
years so, many production queues are no longer used once the app has been migrated.
We are currently upgrading and replatforming our WMQ distributed
environment. It's been a bear in trying to determine, in each
environment, the last time each of the hundreds of queues were last
used. This would have (could be) been a godsend. I am finding about
30% haven't been used in years.
DIS QSTATUS would not have helped in my case.
Gina
Behalf Of Jefferson Lowrey
Sent: Tuesday, June 25, 2013 1:27 PM
Subject: Re: Housecleaning for MQ
Hi Dave -
I don't keep score here. Other places, maybe... ;-)
I think Mike didn't know about this and reject it before asking his
question, based on his response to Paul.
I also think that any queue that hasn't been gotten from/written to
since the last time the qmgr was restarted is a reasonable candidate
for deletion, even in DEV. I also think that it's easy enough to find
out when the qmgr was last restarted, and make a determination if it's been too short, and
collect data over several days. And, notice, Mike is talking about running
the command several times, over a month or six months or etc, and
storing the data.
I also think, in Dev, that it's a much more complicated problem than
just "nobody's using this queue right now". A set of queues could be
unused during several sprints of a development project, but still be required to
exist in Dev for a forthcoming sprint. So I'm not sure that there's any
data that a queue manager can actually maintain to make up for project
management communications and documentation issues.
But the function of DIS QSTATUS is the same function Mike was looking
to have added, so I don't think an RFE is a reasonable idea.
Thank you,
Jeff Lowrey
From: "David Awerbuch (BLOOMBERG/ 731 LEXIN)"
Date: 06/25/2013 11:05 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
________________________________
Hi Jeff,
LPUTTIME|LGETTIME
"The time at which the last message was [put to|retrieved from] the
queue since the queue manager started. When no [put|get] time is
available, perhaps because no message has been [put to|retrieved from]
the queue since the queue manager was started, the value is shown as a blank."
Many shops restart their development environments on a regular basis,
and this method will not work when the queue manager is started. I can
only guess Mike thought of this before submitting his original request.
Mike 1
Jeff 0
Dave
----- Original Message -----
At: Jun 25 2013 11:52:25
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc12
260_.htm
Thank you,
Jeff Lowrey
Date: 06/25/2013 09:49 AM
Subject: [MQSERIES] Housecleaning for MQ
________________________________
Hello Everyone,
We have a bad case of "rabbit" queues (for lack of a better term)...
Many of our Qmgrs simply have too many unused queues defined,
especially for the Dev Qmgrs where developers are allowed to define their own queues for testing.
It'd be nice to clean house occasionally, but we're afraid we might
delete a queue that's needed by someone.
So I was thinking (watch out) - Wouldn't it be nice if there was a
queue-level attribute (or attributes) that reflected a date-time stamp
(or even just date) for the last time that queue was read/written to (Get/Put)?
- call the attributes (LASTREAD & LASTWRITE, or LASTGET & LASTPUT).
Then we could run a report every week, month, or whatever to display
the queues not used in the past 6 months/year/whatever and clean up this mess!!
Before I submit such an RFE, I thought I'd run it by you all and get
your input on how you currently handle this dilemma, as well as your
feelings on such an attribute(s).
Mike Davidson
TSYS Tech Support - WebsphereMQ
----------------------------------------- The information contained in
this communication (including any attachments hereto) is confidential
and is intended solely for the personal and confidential use of the
individual or entity to whom it is addressed. If the reader of this
message is not the intended recipient or an agent responsible for
delivering it to the intended recipient, you are hereby notified that
you have received this communication in error and that any review,
dissemination, copying, or unauthorized use of this information, or
the taking of any action in reliance on the contents of this
information is strictly prohibited. If you have received this
communication in error, please notify us immediately by e-mail, and
delete the original message. 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
________________________________
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
<< Seriously? I don't understand why you don't understand what I don't
understand!! >>
________________________________
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
************************************************************
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

Jefferson Lowrey

2013-06-25 19:34:30 UTC

Permalink

And, again, at some point these stats stop being something used for MQ
purposes, and start being used to replace good change management
practices.

Particularly outside of a DEV environment, there should be a change
management record that backs up the creation of every queue and describes
it's role, and ties that creation to a specific team and responsible
party, and ideally to the relevant project or product.

Application level backout queues for production apps that are well
functioning and receiving data from well behaved systems could conceivable
go unaccessed for a long time. But that doesn't mean they aren't
needed....

Thank you,

Jeff Lowrey

From: "Potkay, Peter M (CTO Architecture + Engineering)"
<Peter.Potkay-***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/25/2013 01:27 PM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

They only need to be written to disk at QM shutdown. Yeah, I guess if
there is an abnormal termination of the QM you can't be sure these stats
get written to disk. So I suppose its performance related that these stats
don't persist. A busy QM with lots of queues would have a tremendous
amount of stats needing to be constantly written to disk.

Peter Potkay

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Bob Juch
Sent: Tuesday, June 25, 2013 2:47 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

Peter,

If the values were to survive a shutdown they'd have to be written to disk
after each change. That would be a lot of overhead.

Bob Juch
Juch Services LLC

On Tue, Jun 25, 2013 at 2:06 PM, Potkay, Peter M (CTO Architecture +

internals.

Post by Potkay, Peter M (CTO Architecture + Engineering)
Peter Potkay
Behalf Of GINA MCCARTHY
Sent: Tuesday, June 25, 2013 1:59 PM
Subject: Re: Housecleaning for MQ
I think it's a great idea to keep those fields. Why should they
refresh when the qmgr gets recycled?
I have production queues that are only used a few times a year. Also,
we are going through a large ERP implementation over the last few
years so, many production queues are no longer used once the app has

been migrated.

Post by Potkay, Peter M (CTO Architecture + Engineering)
We are currently upgrading and replatforming our WMQ distributed
environment. It's been a bear in trying to determine, in each
environment, the last time each of the hundreds of queues were last
used. This would have (could be) been a godsend. I am finding about
30% haven't been used in years.
DIS QSTATUS would not have helped in my case.
Gina
Behalf Of Jefferson Lowrey
Sent: Tuesday, June 25, 2013 1:27 PM
Subject: Re: Housecleaning for MQ
Hi Dave -
I don't keep score here. Other places, maybe... ;-)
I think Mike didn't know about this and reject it before asking his
question, based on his response to Paul.
I also think that any queue that hasn't been gotten from/written to
since the last time the qmgr was restarted is a reasonable candidate
for deletion, even in DEV. I also think that it's easy enough to find
out when the qmgr was last restarted, and make a determination if it's

been too short, and

Post by Potkay, Peter M (CTO Architecture + Engineering)
collect data over several days. And, notice, Mike is talking about

running

Post by Potkay, Peter M (CTO Architecture + Engineering)
the command several times, over a month or six months or etc, and
storing the data.
I also think, in Dev, that it's a much more complicated problem than
just "nobody's using this queue right now". A set of queues could be
unused during several sprints of a development project, but still be

required to

Post by Potkay, Peter M (CTO Architecture + Engineering)
exist in Dev for a forthcoming sprint. So I'm not sure that there's

any

Post by Potkay, Peter M (CTO Architecture + Engineering)
data that a queue manager can actually maintain to make up for project
management communications and documentation issues.
But the function of DIS QSTATUS is the same function Mike was looking
to have added, so I don't think an RFE is a reasonable idea.
Thank you,
Jeff Lowrey
From: "David Awerbuch (BLOOMBERG/ 731 LEXIN)"
Date: 06/25/2013 11:05 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
________________________________
Hi Jeff,
LPUTTIME|LGETTIME
"The time at which the last message was [put to|retrieved from] the
queue since the queue manager started. When no [put|get] time is
available, perhaps because no message has been [put to|retrieved from]
the queue since the queue manager was started, the value is shown as a

blank."

Post by Potkay, Peter M (CTO Architecture + Engineering)
Many shops restart their development environments on a regular basis,
and this method will not work when the queue manager is started. I can
only guess Mike thought of this before submitting his original request.
Mike 1
Jeff 0
Dave
----- Original Message -----
At: Jun 25 2013 11:52:25
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc12
260_.htm
Thank you,
Jeff Lowrey
Date: 06/25/2013 09:49 AM
Subject: [MQSERIES] Housecleaning for MQ
________________________________
Hello Everyone,
We have a bad case of "rabbit" queues (for lack of a better term)...
Many of our Qmgrs simply have too many unused queues defined,
especially for the Dev Qmgrs where developers are allowed to define

their own queues for testing.

Post by Potkay, Peter M (CTO Architecture + Engineering)
It'd be nice to clean house occasionally, but we're afraid we might
delete a queue that's needed by someone.
So I was thinking (watch out) - Wouldn't it be nice if there was a
queue-level attribute (or attributes) that reflected a date-time stamp
(or even just date) for the last time that queue was read/written to

(Get/Put)?

Post by Potkay, Peter M (CTO Architecture + Engineering)
- call the attributes (LASTREAD & LASTWRITE, or LASTGET & LASTPUT).
Then we could run a report every week, month, or whatever to display
the queues not used in the past 6 months/year/whatever and clean up this

mess!!

Post by Potkay, Peter M (CTO Architecture + Engineering)
Before I submit such an RFE, I thought I'd run it by you all and get
your input on how you currently handle this dilemma, as well as your
feelings on such an attribute(s).
Mike Davidson
TSYS Tech Support - WebsphereMQ
----------------------------------------- The information contained in
this communication (including any attachments hereto) is confidential
and is intended solely for the personal and confidential use of the
individual or entity to whom it is addressed. If the reader of this
message is not the intended recipient or an agent responsible for
delivering it to the intended recipient, you are hereby notified that
you have received this communication in error and that any review,
dissemination, copying, or unauthorized use of this information, or
the taking of any action in reliance on the contents of this
information is strictly prohibited. If you have received this
communication in error, please notify us immediately by e-mail, and
delete the original message. 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
________________________________
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
<< Seriously? I don't understand why you don't understand what I don't
understand!! >>
________________________________
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
************************************************************
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.

Post by Potkay, Peter M (CTO Architecture + Engineering)
************************************************************
________________________________
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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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
************************************************************
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.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

T.Rob

2013-06-25 21:34:55 UTC

Permalink

There's also an element here of sub-optimal application design.

When I ran a WMQ admin team, we had a policy that we could drop a poison
message on your queue and the app had to survive it. We also advised
applications to support a "ping" type message which, when received by any
app instance, would result in that app instance responding with valuable
diagnostic data - how long it had been up, how many messages it processed,
which instance it was (in the case that there were multiples), etc. The
idea was that if a web app slowed down, we could spray it with pings to see
which instances responded. That would reveal an unbalanced load
distribution or nodes that were hung and not responding at all. We were
also able to send an infrequent stream of "tracer bullets" intermixed with
live traffic. In addition, we could drop a message with invalid XML, weird
code pages and other defects onto the queue to make sure the app survived
and logged the event.

Assuming either of these techniques were followed, it would be simple to
drop a small, persistent message per day onto each local queue. Preferably
a ping message but a poison message would do. Then, in addition to knowing
the last time the queue was read, there would be some assurance that any
application developed off that queue would at least resist poison messages,
and possibly also provide some basic instrumentation facility.

Unfortunately, such considerations are unpopular in application design. Too
bad because the ROI is amazing.

-- T.Rob

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Jefferson Lowrey
Sent: Tuesday, June 25, 2013 3:35 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

And, again, at some point these stats stop being something used for MQ
purposes, and start being used to replace good change management practices.

Particularly outside of a DEV environment, there should be a change
management record that backs up the creation of every queue and describes
it's role, and ties that creation to a specific team and responsible party,
and ideally to the relevant project or product.

Application level backout queues for production apps that are well
functioning and receiving data from well behaved systems could conceivable
go unaccessed for a long time. But that doesn't mean they aren't needed....

Thank you,

Jeff Lowrey

From: "Potkay, Peter M (CTO Architecture + Engineering)"
<Peter.Potkay-***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/25/2013 01:27 PM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

_____

They only need to be written to disk at QM shutdown. Yeah, I guess if there
is an abnormal termination of the QM you can't be sure these stats get
written to disk. So I suppose its performance related that these stats don't
persist. A busy QM with lots of queues would have a tremendous amount of
stats needing to be constantly written to disk.

Peter Potkay

-----Original Message-----
From: MQSeries List [ <mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Bob Juch
Sent: Tuesday, June 25, 2013 2:47 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

Peter,

If the values were to survive a shutdown they'd have to be written to disk
after each change. That would be a lot of overhead.

Bob Juch
Juch Services LLC

On Tue, Jun 25, 2013 at 2:06 PM, Potkay, Peter M (CTO Architecture +

internals.

migrated.

been too short, and

Post by Potkay, Peter M (CTO Architecture + Engineering)
collect data over several days. And, notice, Mike is talking about

running

required to

Post by Potkay, Peter M (CTO Architecture + Engineering)
exist in Dev for a forthcoming sprint. So I'm not sure that there's any
data that a queue manager can actually maintain to make up for project
management communications and documentation issues.
But the function of DIS QSTATUS is the same function Mike was looking
to have added, so I don't think an RFE is a reasonable idea.
Thank you,
Jeff Lowrey
From: "David Awerbuch (BLOOMBERG/ 731 LEXIN)"
Date: 06/25/2013 11:05 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
________________________________
Hi Jeff,
LPUTTIME|LGETTIME
"The time at which the last message was [put to|retrieved from] the
queue since the queue manager started. When no [put|get] time is
available, perhaps because no message has been [put to|retrieved from]
the queue since the queue manager was started, the value is shown as a

blank."

http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc12

Post by Potkay, Peter M (CTO Architecture + Engineering)
260_.htm
Thank you,
Jeff Lowrey
Date: 06/25/2013 09:49 AM
Subject: [MQSERIES] Housecleaning for MQ
________________________________
Hello Everyone,
We have a bad case of "rabbit" queues (for lack of a better term)...
Many of our Qmgrs simply have too many unused queues defined,
especially for the Dev Qmgrs where developers are allowed to define their

own queues for testing.

(Get/Put)?

mess!!

http://www.lsoft.com

Post by Potkay, Peter M (CTO Architecture + Engineering)
________________________________
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/>

http://www.lsoft.com

Post by Potkay, Peter M (CTO Architecture + Engineering)
<< Seriously? I don't understand why you don't understand what I don't
understand!! >>
________________________________
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/>

http://www.lsoft.com

Post by Potkay, Peter M (CTO Architecture + Engineering)
************************************************************
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.

http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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/> http://www.lsoft.com
Archive: <http://listserv.meduniwien.ac.at/archives/mqser-l.html>
http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
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.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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/>
http://www.lsoft.com
Archive: <http://listserv.meduniwien.ac.at/archives/mqser-l.html>
http://listserv.meduniwien.ac.at/archives/mqser-l.html

_____

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>

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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

Meekin, Paul

2013-06-26 07:36:34 UTC

Permalink

Except IBM clearly do see the value in making these values available so I don't think extending them to persist beyond QMgr starts is any real change in design philosophy.

In terms of performance, presumably the data is currently kept in memory so just add a thread to periodically check the values of each queue and update the value on disk if it's changed.

Paul

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: 25 June 2013 20:35
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

And, again, at some point these stats stop being something used for MQ purposes, and start being used to replace good change management practices.

Particularly outside of a DEV environment, there should be a change management record that backs up the creation of every queue and describes it's role, and ties that creation to a specific team and responsible party, and ideally to the relevant project or product.

Application level backout queues for production apps that are well functioning and receiving data from well behaved systems could conceivable go unaccessed for a long time. But that doesn't mean they aren't needed....

Thank you,

Jeff Lowrey

From: "Potkay, Peter M (CTO Architecture + Engineering)" <Peter.Potkay-***@public.gmane.org<mailto:Peter.Potkay-***@public.gmane.org>>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80Ties2YCUG/***@public.gmane.orgniwien.ac.at>,
Date: 06/25/2013 01:27 PM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>>
________________________________

They only need to be written to disk at QM shutdown. Yeah, I guess if there is an abnormal termination of the QM you can't be sure these stats get written to disk. So I suppose its performance related that these stats don't persist. A busy QM with lots of queues would have a tremendous amount of stats needing to be constantly written to disk.

Peter Potkay

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

Mike Davidson

2013-06-26 12:11:09 UTC

Permalink

I confess ignorance (with a little stupidity thrown in) on my part for not
thinking of Queue Status originally.

However, we are actually looking for values that would persist a Qmgr
shutdown for the same reason Gina mentions here. This would be extremely
valuable to us - and apparently to others, as well. ;-)

Mike Davidson
TSYS Tech Support - WebsphereMQ
***@TSYS.com

From: GINA MCCARTHY <***@ARROW.COM>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT,
Date: 06/25/2013 02:00 PM
Subject: Re: Housecleaning for MQ
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT>

I think itâs a great idea to keep those fields. Why should they refresh
when the qmgr gets recycled?

I have production queues that are only used a few times a year. Also, we
are going through a large ERP implementation over the last few years so,
many production queues are no longer used once the app has been migrated.

We are currently upgrading and replatforming our WMQ distributed
environment. Itâs been a bear in trying to determine, in each environment,
the last time each of the hundreds of queues were last used. This would
have (could be) been a godsend. I am finding about 30% havenât been used
in years.

DIS QSTATUS would not have helped in my case.

Gina

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Jefferson Lowrey
Sent: Tuesday, June 25, 2013 1:27 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Housecleaning for MQ

Hi Dave -
I don't keep score here. Other places, maybe... ;-)

I think Mike didn't know about this and reject it before asking his
question, based on his response to Paul.

I also think that any queue that hasn't been gotten from/written to since
the last time the qmgr was restarted is a reasonable candidate for
deletion, even in DEV. I also think that it's easy enough to find out
when the qmgr was last restarted, and make a determination if it's been
too short, and collect data over several days. And, notice, Mike is
talking about running the command several times, over a month or six
months or etc, and storing the data.

I also think, in Dev, that it's a much more complicated problem than just
"nobody's using this queue right now". A set of queues could be unused
during several sprints of a development project, but still be required to
exist in Dev for a forthcoming sprint. So I'm not sure that there's any
data that a queue manager can actually maintain to make up for project
management communications and documentation issues.

But the function of DIS QSTATUS is the same function Mike was looking to
have added, so I don't think an RFE is a reasonable idea.

Thank you,

Jeff Lowrey

From: "David Awerbuch (BLOOMBERG/ 731 LEXIN)" <
***@bloomberg.net>
To: ***@listserv.meduniwien.ac.at,
Date: 06/25/2013 11:05 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <***@listserv.meduniwien.ac.at>

Hi Jeff,

LPUTTIME|LGETTIME
"The time at which the last message was [put to|retrieved from] the queue
since the queue manager started. When no [put|get] time is available,
perhaps because no message has been [put to|retrieved from] the queue
since the queue manager was started, the value is shown as a blank."

Many shops restart their development environments on a regular basis, and
this method will not work when the queue manager is started. I can only
guess Mike thought of this before submitting his original request.

Mike 1
Jeff 0

Dave

----- Original Message -----
From: ***@LISTSERV.MEDUNIWIEN.AC.AT
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
At: Jun 25 2013 11:52:25
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc12260_.htm

Thank you,

Jeff Lowrey

From: Mike Davidson <***@TSYS.COM>
To: ***@listserv.meduniwien.ac.at,
Date: 06/25/2013 09:49 AM
Subject: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <***@listserv.meduniwien.ac.at>

Hello Everyone,

We have a bad case of "rabbit" queues (for lack of a better term)... Many
of our Qmgrs simply have too many unused queues defined, especially for
the Dev Qmgrs where developers are allowed to define their own queues for
testing. It'd be nice to clean house occasionally, but we're afraid we
might delete a queue that's needed by someone.

So I was thinking (watch out) - Wouldn't it be nice if there was a
queue-level attribute (or attributes) that reflected a date-time stamp (or
even just date) for the last time that queue was read/written to
(Get/Put)? - call the attributes (LASTREAD & LASTWRITE, or LASTGET &
LASTPUT). Then we could run a report every week, month, or whatever to
display the queues not used in the past 6 months/year/whatever and clean
up this mess!!

Before I submit such an RFE, I thought I'd run it by you all and get your
input on how you currently handle this dilemma, as well as your feelings
on such an attribute(s).

Mike Davidson
TSYS Tech Support - WebsphereMQ
***@TSYS.com
----------------------------------------- The information contained in
this communication (including any attachments hereto) is confidential and
is intended solely for the personal and confidential use of the individual
or entity to whom it is addressed. If the reader of this message is not
the intended recipient or an agent responsible for delivering it to the
intended recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying, or
unauthorized use of this information, or the taking of any action in
reliance on the contents of this information is strictly prohibited. If
you have received this communication in error, please notify us
immediately by e-mail, and delete the original message. 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

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

<< Seriously? I don't understand why you don't understand what I don't
understand!! >>

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

Potkay, Peter M (CTO Architecture + Engineering)

2013-06-26 12:40:24 UTC

Permalink

Mike,
Check with your monitoring team. Their tools just might have the ability to record the # of puts and # of gets on a local queue and persist the values for as long as you want in the monitoring toolâs datastore.

Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Mike Davidson
Sent: Wednesday, June 26, 2013 8:11 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Housecleaning for MQ

I confess ignorance (with a little stupidity thrown in) on my part for not thinking of Queue Status originally.

However, we are actually looking for values that would persist a Qmgr shutdown for the same reason Gina mentions here. This would be extremely valuable to us - and apparently to others, as well. ;-)

Mike Davidson
TSYS Tech Support - WebsphereMQ
***@TSYS.com<mailto:***@TSYS.com>

From: GINA MCCARTHY <***@ARROW.COM<mailto:***@ARROW.COM>>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>,
Date: 06/25/2013 02:00 PM
Subject: Re: Housecleaning for MQ
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>>
________________________________

I think itâs a great idea to keep those fields. Why should they refresh when the qmgr gets recycled?

I have production queues that are only used a few times a year. Also, we are going through a large ERP implementation over the last few years so, many production queues are no longer used once the app has been migrated.

We are currently upgrading and replatforming our WMQ distributed environment. Itâs been a bear in trying to determine, in each environment, the last time each of the hundreds of queues were last used. This would have (could be) been a godsend. I am finding about 30% havenât been used in years.

DIS QSTATUS would not have helped in my case.

Gina

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jefferson Lowrey
Sent: Tuesday, June 25, 2013 1:27 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Housecleaning for MQ

Hi Dave -
I don't keep score here. Other places, maybe... ;-)

I think Mike didn't know about this and reject it before asking his question, based on his response to Paul.

I also think that any queue that hasn't been gotten from/written to since the last time the qmgr was restarted is a reasonable candidate for deletion, even in DEV. I also think that it's easy enough to find out when the qmgr was last restarted, and make a determination if it's been too short, and collect data over several days. And, notice, Mike is talking about running the command several times, over a month or six months or etc, and storing the data.

I also think, in Dev, that it's a much more complicated problem than just "nobody's using this queue right now". A set of queues could be unused during several sprints of a development project, but still be required to exist in Dev for a forthcoming sprint. So I'm not sure that there's any data that a queue manager can actually maintain to make up for project management communications and documentation issues.

But the function of DIS QSTATUS is the same function Mike was looking to have added, so I don't think an RFE is a reasonable idea.

Thank you,

Jeff Lowrey

From: "David Awerbuch (BLOOMBERG/ 731 LEXIN)" <***@bloomberg.net<mailto:***@bloomberg.net>>
To: ***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>,
Date: 06/25/2013 11:05 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>>
________________________________

Hi Jeff,

LPUTTIME|LGETTIME
"The time at which the last message was [put to|retrieved from] the queue since the queue manager started. When no [put|get] time is available, perhaps because no message has been [put to|retrieved from] the queue since the queue manager was started, the value is shown as a blank."

Many shops restart their development environments on a regular basis, and this method will not work when the queue manager is started. I can only guess Mike thought of this before submitting his original request.

Mike 1
Jeff 0

Dave

----- Original Message -----
From: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
At: Jun 25 2013 11:52:25
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc12260_.htm

Thank you,

Jeff Lowrey

From: Mike Davidson <***@TSYS.COM<mailto:***@TSYS.COM>>
To: ***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>,
Date: 06/25/2013 09:49 AM
Subject: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>>
________________________________

Hello Everyone,

We have a bad case of "rabbit" queues (for lack of a better term)... Many of our Qmgrs simply have too many unused queues defined, especially for the Dev Qmgrs where developers are allowed to define their own queues for testing. It'd be nice to clean house occasionally, but we're afraid we might delete a queue that's needed by someone.

So I was thinking (watch out) - Wouldn't it be nice if there was a queue-level attribute (or attributes) that reflected a date-time stamp (or even just date) for the last time that queue was read/written to (Get/Put)? - call the attributes (LASTREAD & LASTWRITE, or LASTGET & LASTPUT). Then we could run a report every week, month, or whatever to display the queues not used in the past 6 months/year/whatever and clean up this mess!!

Before I submit such an RFE, I thought I'd run it by you all and get your input on how you currently handle this dilemma, as well as your feelings on such an attribute(s).

Mike Davidson
TSYS Tech Support - WebsphereMQ
***@TSYS.com<mailto:***@TSYS.com>
----------------------------------------- The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

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

________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

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

<< Seriously? I don't understand why you don't understand what I don't understand!! >>

________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

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

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
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.
************************************************************

Hatcher Jeter

2013-06-26 12:51:52 UTC

Permalink

I know that Tivoli for Messaging will record and store these in the
Dataware House. So you can easily pull the info from Tivoli

Hatcher H. Jeter, Jr.
Domain Architect - Integration Technologies
IBM Practice
Avnet Services

Mobile: 804-334-4750
***@atech.com
www.atech.com

This message, including files attached to it, may contain confidential
information that is intended only for the use of the ADDRESSEES(S) named
above. If you are not an intended recipient, you are hereby notified that
any dissemination or copying of the information contained in this message,
or the taking of any action in reliance upon the information, is strictly
prohibited. If you have received this message in error, please notify the
sender immediately and delete the message from your system. Thank You.

From: "Potkay, Peter M (CTO Architecture + Engineering)" <***@THEHARTFORD.COM>

To: ***@LISTSERV.MEDUNIWIEN.AC.AT,

Date: 06/26/2013 08:41 AM

Subject: Re: Housecleaning for MQ

Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT>

Mike,
Check with your monitoring team. Their tools just might have the ability to
record the # of puts and # of gets on a local queue and persist the values
for as long as you want in the monitoring tool’s datastore.

Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Mike Davidson
Sent: Wednesday, June 26, 2013 8:11 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Housecleaning for MQ

I confess ignorance (with a little stupidity thrown in) on my part for not
thinking of Queue Status originally.

However, we are actually looking for values that would persist a Qmgr
shutdown for the same reason Gina mentions here. This would be extremely
valuable to us - and apparently to others, as well. ;-)

Mike Davidson
TSYS Tech Support - WebsphereMQ
***@TSYS.com

From: GINA MCCARTHY <***@ARROW.COM>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT,
Date: 06/25/2013 02:00 PM
Subject: Re: Housecleaning for MQ
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT>

I think it’s a great idea to keep those fields. Why should they refresh
when the qmgr gets recycled?

I have production queues that are only used a few times a year. Also, we
are going through a large ERP implementation over the last few years so,
many production queues are no longer used once the app has been migrated.

We are currently upgrading and replatforming our WMQ distributed
environment. It’s been a bear in trying to determine, in each environment,
the last time each of the hundreds of queues were last used. This would
have (could be) been a godsend. I am finding about 30% haven’t been used
in years.

DIS QSTATUS would not have helped in my case.

Gina

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Jefferson Lowrey
Sent: Tuesday, June 25, 2013 1:27 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Housecleaning for MQ

Hi Dave -
I don't keep score here. Other places, maybe... ;-)

I think Mike didn't know about this and reject it before asking his
question, based on his response to Paul.

I also think that any queue that hasn't been gotten from/written to since
the last time the qmgr was restarted is a reasonable candidate for
deletion, even in DEV. I also think that it's easy enough to find out when
the qmgr was last restarted, and make a determination if it's been too
short, and collect data over several days. And, notice, Mike is talking
about running the command several times, over a month or six months or etc,
and storing the data.

I also think, in Dev, that it's a much more complicated problem than just
"nobody's using this queue right now". A set of queues could be unused
during several sprints of a development project, but still be required to
exist in Dev for a forthcoming sprint. So I'm not sure that there's any
data that a queue manager can actually maintain to make up for project
management communications and documentation issues.

But the function of DIS QSTATUS is the same function Mike was looking to
have added, so I don't think an RFE is a reasonable idea.

Thank you,

Jeff Lowrey

From: "David Awerbuch (BLOOMBERG/ 731 LEXIN)" <
***@bloomberg.net>
To: ***@listserv.meduniwien.ac.at,
Date: 06/25/2013 11:05 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <***@listserv.meduniwien.ac.at>

Hi Jeff,

LPUTTIME|LGETTIME
"The time at which the last message was [put to|retrieved from] the queue
since the queue manager started. When no [put|get] time is available,
perhaps because no message has been [put to|retrieved from] the queue since
the queue manager was started, the value is shown as a blank."

Many shops restart their development environments on a regular basis, and
this method will not work when the queue manager is started. I can only
guess Mike thought of this before submitting his original request.

Mike 1
Jeff 0

Dave

----- Original Message -----
From: ***@LISTSERV.MEDUNIWIEN.AC.AT
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
At: Jun 25 2013 11:52:25
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc12260_.htm

Thank you,

Jeff Lowrey

From: Mike Davidson <***@TSYS.COM>
To: ***@listserv.meduniwien.ac.at,
Date: 06/25/2013 09:49 AM
Subject: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <***@listserv.meduniwien.ac.at>

Hello Everyone,

We have a bad case of "rabbit" queues (for lack of a better term)... Many
of our Qmgrs simply have too many unused queues defined, especially for the
Dev Qmgrs where developers are allowed to define their own queues for
testing. It'd be nice to clean house occasionally, but we're afraid we
might delete a queue that's needed by someone.

So I was thinking (watch out) - Wouldn't it be nice if there was a
queue-level attribute (or attributes) that reflected a date-time stamp (or
even just date) for the last time that queue was read/written to (Get/Put)?
- call the attributes (LASTREAD & LASTWRITE, or LASTGET & LASTPUT). Then we
could run a report every week, month, or whatever to display the queues not
used in the past 6 months/year/whatever and clean up this mess!!

Before I submit such an RFE, I thought I'd run it by you all and get your
input on how you currently handle this dilemma, as well as your feelings on
such an attribute(s).

Mike Davidson
TSYS Tech Support - WebsphereMQ
***@TSYS.com
----------------------------------------- The information contained in this
communication (including any attachments hereto) is confidential and is
intended solely for the personal and confidential use of the individual or
entity to whom it is addressed. If the reader of this message is not the
intended recipient or an agent responsible for delivering it to the
intended recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying, or
unauthorized use of this information, or the taking of any action in
reliance on the contents of this information is strictly prohibited. If you
have received this communication in error, please notify us immediately by
e-mail, and delete the original message. 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

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

<< Seriously? I don't understand why you don't understand what I don't
understand!! >>

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

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

Tim Zielke

2013-06-26 13:05:07 UTC

Permalink

Hi Mike,

Also, for the issue with too many unneeded Development queues, is there an option to have the developers set the RETINTVL appropriately when they create the queue? That would give you another value to know specifically when the queue is no longer needed or could be a candidate to be deleted by an automated housekeeping process.

RETINTVL(integer)
The number of hours from when the queue was defined, after which the queue is no longer needed. The value must be in the range 0 - 999,999,999.
This parameter is supported only on local and model queues.
The CRDATE and CRTIME can be displayed using the DISPLAY QUEUE command.
This information is available for use by an operator or a housekeeping application to delete queues that are no longer required.
Note: The queue manager does not delete queues based on this value, nor does it prevent queues from being deleted if their retention interval is not expired. It is the responsibility of the user to take any required action.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Mike Davidson
Sent: Wednesday, June 26, 2013 7:11 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Housecleaning for MQ

I confess ignorance (with a little stupidity thrown in) on my part for not thinking of Queue Status originally.

However, we are actually looking for values that would persist a Qmgr shutdown for the same reason Gina mentions here. This would be extremely valuable to us - and apparently to others, as well. ;-)

Mike Davidson
TSYS Tech Support - WebsphereMQ
***@TSYS.com

From: GINA MCCARTHY <***@ARROW.COM>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT,
Date: 06/25/2013 02:00 PM
Subject: Re: Housecleaning for MQ
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT>
________________________________

I think itâs a great idea to keep those fields. Why should they refresh when the qmgr gets recycled?

I have production queues that are only used a few times a year. Also, we are going through a large ERP implementation over the last few years so, many production queues are no longer used once the app has been migrated.

We are currently upgrading and replatforming our WMQ distributed environment. Itâs been a bear in trying to determine, in each environment, the last time each of the hundreds of queues were last used. This would have (could be) been a godsend. I am finding about 30% havenât been used in years.

DIS QSTATUS would not have helped in my case.

Gina

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jefferson Lowrey
Sent: Tuesday, June 25, 2013 1:27 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Housecleaning for MQ

Hi Dave -
I don't keep score here. Other places, maybe... ;-)

I think Mike didn't know about this and reject it before asking his question, based on his response to Paul.

I also think that any queue that hasn't been gotten from/written to since the last time the qmgr was restarted is a reasonable candidate for deletion, even in DEV. I also think that it's easy enough to find out when the qmgr was last restarted, and make a determination if it's been too short, and collect data over several days. And, notice, Mike is talking about running the command several times, over a month or six months or etc, and storing the data.

I also think, in Dev, that it's a much more complicated problem than just "nobody's using this queue right now". A set of queues could be unused during several sprints of a development project, but still be required to exist in Dev for a forthcoming sprint. So I'm not sure that there's any data that a queue manager can actually maintain to make up for project management communications and documentation issues.

But the function of DIS QSTATUS is the same function Mike was looking to have added, so I don't think an RFE is a reasonable idea.

Thank you,

Jeff Lowrey

From: "David Awerbuch (BLOOMBERG/ 731 LEXIN)" <***@bloomberg.net<mailto:***@bloomberg.net>>
To: ***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>,
Date: 06/25/2013 11:05 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>>
________________________________

Hi Jeff,

LPUTTIME|LGETTIME
"The time at which the last message was [put to|retrieved from] the queue since the queue manager started. When no [put|get] time is available, perhaps because no message has been [put to|retrieved from] the queue since the queue manager was started, the value is shown as a blank."

Many shops restart their development environments on a regular basis, and this method will not work when the queue manager is started. I can only guess Mike thought of this before submitting his original request.

Mike 1
Jeff 0

Dave

----- Original Message -----
From: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
At: Jun 25 2013 11:52:25
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc12260_.htm

Thank you,

Jeff Lowrey

From: Mike Davidson <***@TSYS.COM<mailto:***@TSYS.COM>>
To: ***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>,
Date: 06/25/2013 09:49 AM
Subject: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>>
________________________________

Hello Everyone,

We have a bad case of "rabbit" queues (for lack of a better term)... Many of our Qmgrs simply have too many unused queues defined, especially for the Dev Qmgrs where developers are allowed to define their own queues for testing. It'd be nice to clean house occasionally, but we're afraid we might delete a queue that's needed by someone.

So I was thinking (watch out) - Wouldn't it be nice if there was a queue-level attribute (or attributes) that reflected a date-time stamp (or even just date) for the last time that queue was read/written to (Get/Put)? - call the attributes (LASTREAD & LASTWRITE, or LASTGET & LASTPUT). Then we could run a report every week, month, or whatever to display the queues not used in the past 6 months/year/whatever and clean up this mess!!

Before I submit such an RFE, I thought I'd run it by you all and get your input on how you currently handle this dilemma, as well as your feelings on such an attribute(s).

Mike Davidson
TSYS Tech Support - WebsphereMQ
***@TSYS.com<mailto:***@TSYS.com>
----------------------------------------- The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

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

________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

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

<< Seriously? I don't understand why you don't understand what I don't understand!! >>

________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

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

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

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

T.Rob

2013-06-26 14:07:13 UTC

Permalink

Wow Paul, this is an oversimplification on a grand scale. I'm a bit
surprised.

Every queue has a control block associated with it in which the operational
status of the queue is stored. Much of WMQ is driven by the API calls made
by connected applications, including the update of that control block.

If the requested data were made to persist in the fashion you describe,
there would be a race condition during which the QMgr could go down without
having updated the value. This is no more reliable than could be achieved
with a simple shell script. Would anyone here consider the requirement met
if IBM were to provide a simple shell script to capture that data? Or is
the requirement specifically to be able to use MQSC and PCF to retrieve the
values and we don't necessarily care that they may not be accurate? The
notion of having an operational statistic and diagnostic value that is
"mostly reliable" would seem to me to be a rather significant change in
design philosophy.

Making the statistic not just persistent but *reliably* persistent would
require elimination of the race condition which adds to the code path of
*every* *API* *call* made within WMQ for the queues where that was enabled.
Making the public API code path longer and adding more points of failure is
also a rather significant change in design philosophy.

WMQ was built with significant instrumentation capabilities to allow things
like Tivoli to capture and record operational aspects. There's an element
of that which addresses the questions of "which features does EVERY customer
need to pay for?" and "which features and functions support a vibrant 3rd
party ecosystem that makes the product more viable and sustainable for all
customers?" Every diagnostic and statistic in the product are paid for by
all customers so the ones that are there either exist because the need to be
there and are merely exposed to the user, or those that are considered so
important that *every* customer should pay to support their maintenance in
the product. Since there are many ways of capturing this data with the
existing instrumentation, even a simple shell script could do it, moving it
to the category of "this is so critical that all customers must pay for it,
and customers with any sort of monitoring tool will just have to pay for it
twice" also seems to me to be a rather change in design philosophy.

The framework to set up cascading defaults from the queue manager down to
each queue to communicate the desired behavior to WMQ in a granular fashion
is about the only part of this request that might not be a big deal and I'm
not entirely sure about that.

-- T.Rob

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Meekin, Paul
Sent: Wednesday, June 26, 2013 3:37 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

Except IBM clearly do see the value in making these values available so I
don't think extending them to persist beyond QMgr starts is any real change
in design philosophy.

In terms of performance, presumably the data is currently kept in memory so
just add a thread to periodically check the values of each queue and update
the value on disk if it's changed.

Paul

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Jefferson Lowrey
Sent: 25 June 2013 20:35
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

And, again, at some point these stats stop being something used for MQ
purposes, and start being used to replace good change management practices.

Particularly outside of a DEV environment, there should be a change
management record that backs up the creation of every queue and describes
it's role, and ties that creation to a specific team and responsible party,
and ideally to the relevant project or product.

Application level backout queues for production apps that are well
functioning and receiving data from well behaved systems could conceivable
go unaccessed for a long time. But that doesn't mean they aren't needed....

Thank you,

Jeff Lowrey

From: "Potkay, Peter M (CTO Architecture + Engineering)"
<Peter.Potkay-***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/25/2013 01:27 PM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

_____

They only need to be written to disk at QM shutdown. Yeah, I guess if there
is an abnormal termination of the QM you can't be sure these stats get
written to disk. So I suppose its performance related that these stats don't
persist. A busy QM with lots of queues would have a tremendous amount of
stats needing to be constantly written to disk.

Peter Potkay

_____

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>

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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

Meekin, Paul

2013-06-26 14:41:12 UTC

Permalink

Hi T. Rob,

Yeah, that's a fair point. I'll make sure I have my morning cuppa before posting in future :)

That said it seems to me to be a useful statistic to have and it is sometimes frustrating to get only half-way there. Of course we all understand the trade-offs and compromises in design and ultimately we have to take the word of the developers that there is a good reason why it has to be that way.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: 26 June 2013 15:07
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

Wow Paul, this is an oversimplification on a grand scale. I'm a bit surprised.

Every queue has a control block associated with it in which the operational status of the queue is stored. Much of WMQ is driven by the API calls made by connected applications, including the update of that control block.

If the requested data were made to persist in the fashion you describe, there would be a race condition during which the QMgr could go down without having updated the value. This is no more reliable than could be achieved with a simple shell script. Would anyone here consider the requirement met if IBM were to provide a simple shell script to capture that data? Or is the requirement specifically to be able to use MQSC and PCF to retrieve the values and we don't necessarily care that they may not be accurate? The notion of having an operational statistic and diagnostic value that is "mostly reliable" would seem to me to be a rather significant change in design philosophy.

Making the statistic not just persistent but *reliably* persistent would require elimination of the race condition which adds to the code path of *every* *API* *call* made within WMQ for the queues where that was enabled. Making the public API code path longer and adding more points of failure is also a rather significant change in design philosophy.

WMQ was built with significant instrumentation capabilities to allow things like Tivoli to capture and record operational aspects. There's an element of that which addresses the questions of "which features does EVERY customer need to pay for?" and "which features and functions support a vibrant 3rd party ecosystem that makes the product more viable and sustainable for all customers?" Every diagnostic and statistic in the product are paid for by all customers so the ones that are there either exist because the need to be there and are merely exposed to the user, or those that are considered so important that *every* customer should pay to support their maintenance in the product. Since there are many ways of capturing this data with the existing instrumentation, even a simple shell script could do it, moving it to the category of "this is so critical that all customers must pay for it, and customers with any sort of monitoring tool will just have to pay for it twice" also seems to me to be a rather change in design philosophy.

The framework to set up cascading defaults from the queue manager down to each queue to communicate the desired behavior to WMQ in a granular fashion is about the only part of this request that might not be a big deal and I'm not entirely sure about that.

-- T.Rob

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Meekin, Paul
Sent: Wednesday, June 26, 2013 3:37 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Housecleaning for MQ

Except IBM clearly do see the value in making these values available so I don't think extending them to persist beyond QMgr starts is any real change in design philosophy.

In terms of performance, presumably the data is currently kept in memory so just add a thread to periodically check the values of each queue and update the value on disk if it's changed.

Paul

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: 25 June 2013 20:35
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Housecleaning for MQ

And, again, at some point these stats stop being something used for MQ purposes, and start being used to replace good change management practices.

Particularly outside of a DEV environment, there should be a change management record that backs up the creation of every queue and describes it's role, and ties that creation to a specific team and responsible party, and ideally to the relevant project or product.

Application level backout queues for production apps that are well functioning and receiving data from well behaved systems could conceivable go unaccessed for a long time. But that doesn't mean they aren't needed....

Thank you,

Jeff Lowrey

From: "Potkay, Peter M (CTO Architecture + Engineering)" <Peter.Potkay-***@public.gmane.org<mailto:Peter.Potkay-***@public.gmane.org>>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80Ties2YCUG/***@public.gmane.orgniwien.ac.at>,
Date: 06/25/2013 01:27 PM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>>
________________________________

They only need to be written to disk at QM shutdown. Yeah, I guess if there is an abnormal termination of the QM you can't be sure these stats get written to disk. So I suppose its performance related that these stats don't persist. A busy QM with lots of queues would have a tremendous amount of stats needing to be constantly written to disk.

Peter Potkay

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

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

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

GINA MCCARTHY

2013-06-26 15:20:07 UTC

Permalink

Peter,

I am ecstatic that you have the privilege of having a monitoring *team*, capable developers, as well a MQ admin team.

We tossed them years ago with the majority of our change control team and our PM team. There is just no $$ to do that anymore. Our change control concentrates on our ERP migration.

Our MQ Infrastructure team, as well as our MQ Monitoring team, consist of 1 FTE. Itâs sad, I know. Pathetic even.

It may not be this bad everywhere. However, I do believe that most donât have it as good as you.

Every MQ tool helps, whether itâs built into the product or a support pac.

Iâve worked with MQ long enough to find creative ways to get the information I need.

It seems that if IBM records this infoâŠis seems it could be a simple change to have it persist?

J

Gina

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, June 26, 2013 8:40 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Housecleaning for MQ

Mike,

Check with your monitoring team. Their tools just might have the ability to record the # of puts and # of gets on a local queue and persist the values for as long as you want in the monitoring toolâs datastore.

Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Mike Davidson
Sent: Wednesday, June 26, 2013 8:11 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Housecleaning for MQ

I confess ignorance (with a little stupidity thrown in) on my part for not thinking of Queue Status originally.

However, we are actually looking for values that would persist a Qmgr shutdown for the same reason Gina mentions here. This would be extremely valuable to us - and apparently to others, as well. ;-)

Mike Davidson
TSYS Tech Support - WebsphereMQ
***@TSYS.com

From: GINA MCCARTHY <***@ARROW.COM>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT,
Date: 06/25/2013 02:00 PM
Subject: Re: Housecleaning for MQ
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT>

________________________________

I think itâs a great idea to keep those fields. Why should they refresh when the qmgr gets recycled?

I have production queues that are only used a few times a year. Also, we are going through a large ERP implementation over the last few years so, many production queues are no longer used once the app has been migrated.

We are currently upgrading and replatforming our WMQ distributed environment. Itâs been a bear in trying to determine, in each environment, the last time each of the hundreds of queues were last used. This would have (could be) been a godsend. I am finding about 30% havenât been used in years.

DIS QSTATUS would not have helped in my case.

Gina

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT <mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> ] On Behalf Of Jefferson Lowrey
Sent: Tuesday, June 25, 2013 1:27 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Housecleaning for MQ

Hi Dave -
I don't keep score here. Other places, maybe... ;-)

I think Mike didn't know about this and reject it before asking his question, based on his response to Paul.

I also think that any queue that hasn't been gotten from/written to since the last time the qmgr was restarted is a reasonable candidate for deletion, even in DEV. I also think that it's easy enough to find out when the qmgr was last restarted, and make a determination if it's been too short, and collect data over several days. And, notice, Mike is talking about running the command several times, over a month or six months or etc, and storing the data.

I also think, in Dev, that it's a much more complicated problem than just "nobody's using this queue right now". A set of queues could be unused during several sprints of a development project, but still be required to exist in Dev for a forthcoming sprint. So I'm not sure that there's any data that a queue manager can actually maintain to make up for project management communications and documentation issues.

But the function of DIS QSTATUS is the same function Mike was looking to have added, so I don't think an RFE is a reasonable idea.

Thank you,

Jeff Lowrey

From: "David Awerbuch (BLOOMBERG/ 731 LEXIN)" <***@bloomberg.net <mailto:***@bloomberg.net> >
To: ***@listserv.meduniwien.ac.at <mailto:***@listserv.meduniwien.ac.at> ,
Date: 06/25/2013 11:05 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <***@listserv.meduniwien.ac.at <mailto:***@listserv.meduniwien.ac.at> >

________________________________

Hi Jeff,

LPUTTIME|LGETTIME
"The time at which the last message was [put to|retrieved from] the queue since the queue manager started. When no [put|get] time is available, perhaps because no message has been [put to|retrieved from] the queue since the queue manager was started, the value is shown as a blank."

Many shops restart their development environments on a regular basis, and this method will not work when the queue manager is started. I can only guess Mike thought of this before submitting his original request.

Mike 1
Jeff 0

Dave

----- Original Message -----
From: ***@LISTSERV.MEDUNIWIEN.AC.AT <mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT <mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
At: Jun 25 2013 11:52:25
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc12260_.htm <http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc12260_.htm>

Thank you,

Jeff Lowrey

From: Mike Davidson <***@TSYS.COM <mailto:***@TSYS.COM> >
To: ***@listserv.meduniwien.ac.at <mailto:***@listserv.meduniwien.ac.at> ,
Date: 06/25/2013 09:49 AM
Subject: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <***@listserv.meduniwien.ac.at <mailto:***@listserv.meduniwien.ac.at> >

________________________________

Hello Everyone,

We have a bad case of "rabbit" queues (for lack of a better term)... Many of our Qmgrs simply have too many unused queues defined, especially for the Dev Qmgrs where developers are allowed to define their own queues for testing. It'd be nice to clean house occasionally, but we're afraid we might delete a queue that's needed by someone.

So I was thinking (watch out) - Wouldn't it be nice if there was a queue-level attribute (or attributes) that reflected a date-time stamp (or even just date) for the last time that queue was read/written to (Get/Put)? - call the attributes (LASTREAD & LASTWRITE, or LASTGET & LASTPUT). Then we could run a report every week, month, or whatever to display the queues not used in the past 6 months/year/whatever and clean up this mess!!

Before I submit such an RFE, I thought I'd run it by you all and get your input on how you currently handle this dilemma, as well as your feelings on such an attribute(s).

Mike Davidson
TSYS Tech Support - WebsphereMQ
***@TSYS.com <mailto:***@TSYS.com>
----------------------------------------- The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you

________________________________

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings <http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe <mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

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

________________________________

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings <http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe <mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

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

<< Seriously? I don't understand why you don't understand what I don't understand!! >>

________________________________

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings <http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe <mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

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

________________________________

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings <http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe <mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

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

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

Jefferson Lowrey

2013-06-26 15:24:57 UTC

Permalink

It is simple to have this persist.

echo "Dis qstatus(*) all"|runmqsc QmgrName > qstats.log

schedule every hour using cron or your favorite scheduler.

Thank you,

Jeff Lowrey

From: GINA MCCARTHY <gimccarthy-***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/26/2013 09:21 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

Peter,

I am ecstatic that you have the privilege of having a monitoring *team*,
capable developers, as well a MQ admin team.

We tossed them years ago with the majority of our change control team and
our PM team. There is just no $$ to do that anymore. Our change control
concentrates on our ERP migration.

Our MQ Infrastructure team, as well as our MQ Monitoring team, consist of
1 FTE. It?s sad, I know. Pathetic even.

It may not be this bad everywhere. However, I do believe that most don?t
have it as good as you.

Every MQ tool helps, whether it?s built into the product or a support pac.

I?ve worked with MQ long enough to find creative ways to get the
information I need.

It seems that if IBM records this info?is seems it could be a simple
change to have it persist?

J

Gina

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, June 26, 2013 8:40 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

Mike,
Check with your monitoring team. Their tools just might have the ability
to record the # of puts and # of gets on a local queue and persist the
values for as long as you want in the monitoring tool?s datastore.

Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Mike Davidson
Sent: Wednesday, June 26, 2013 8:11 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

I confess ignorance (with a little stupidity thrown in) on my part for not
thinking of Queue Status originally.

However, we are actually looking for values that would persist a Qmgr
shutdown for the same reason Gina mentions here. This would be extremely
valuable to us - and apparently to others, as well. ;-)

Mike Davidson
TSYS Tech Support - WebsphereMQ
MikeDavidson-***@public.gmane.org

From: GINA MCCARTHY <gimccarthy-***@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org,
Date: 06/25/2013 02:00 PM
Subject: Re: Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>

I think it?s a great idea to keep those fields. Why should they refresh
when the qmgr gets recycled?

I have production queues that are only used a few times a year. Also, we
are going through a large ERP implementation over the last few years so,
many production queues are no longer used once the app has been migrated.

We are currently upgrading and replatforming our WMQ distributed
environment. It?s been a bear in trying to determine, in each environment,
the last time each of the hundreds of queues were last used. This would
have (could be) been a godsend. I am finding about 30% haven?t been used
in years.

DIS QSTATUS would not have helped in my case.

Gina

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Jefferson Lowrey
Sent: Tuesday, June 25, 2013 1:27 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

Hi Dave -
I don't keep score here. Other places, maybe... ;-)

I think Mike didn't know about this and reject it before asking his
question, based on his response to Paul.

I also think that any queue that hasn't been gotten from/written to since
the last time the qmgr was restarted is a reasonable candidate for
deletion, even in DEV. I also think that it's easy enough to find out
when the qmgr was last restarted, and make a determination if it's been
too short, and collect data over several days. And, notice, Mike is
talking about running the command several times, over a month or six
months or etc, and storing the data.

I also think, in Dev, that it's a much more complicated problem than just
"nobody's using this queue right now". A set of queues could be unused
during several sprints of a development project, but still be required to
exist in Dev for a forthcoming sprint. So I'm not sure that there's any
data that a queue manager can actually maintain to make up for project
management communications and documentation issues.

But the function of DIS QSTATUS is the same function Mike was looking to
have added, so I don't think an RFE is a reasonable idea.

Thank you,

Jeff Lowrey

From: "David Awerbuch (BLOOMBERG/ 731 LEXIN)" <
dawerbuch-AlFclGv/***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/25/2013 11:05 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

Hi Jeff,

LPUTTIME|LGETTIME
"The time at which the last message was [put to|retrieved from] the queue
since the queue manager started. When no [put|get] time is available,
perhaps because no message has been [put to|retrieved from] the queue
since the queue manager was started, the value is shown as a blank."

Many shops restart their development environments on a regular basis, and
this method will not work when the queue manager is started. I can only
guess Mike thought of this before submitting his original request.

Mike 1
Jeff 0

Dave

----- Original Message -----
From: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
At: Jun 25 2013 11:52:25
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc12260_.htm

Thank you,

Jeff Lowrey

From: Mike Davidson <MikeDavidson-MaERPT+***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/25/2013 09:49 AM
Subject: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

Hello Everyone,

We have a bad case of "rabbit" queues (for lack of a better term)... Many
of our Qmgrs simply have too many unused queues defined, especially for
the Dev Qmgrs where developers are allowed to define their own queues for
testing. It'd be nice to clean house occasionally, but we're afraid we
might delete a queue that's needed by someone.

So I was thinking (watch out) - Wouldn't it be nice if there was a
queue-level attribute (or attributes) that reflected a date-time stamp (or
even just date) for the last time that queue was read/written to
(Get/Put)? - call the attributes (LASTREAD & LASTWRITE, or LASTGET &
LASTPUT). Then we could run a report every week, month, or whatever to
display the queues not used in the past 6 months/year/whatever and clean
up this mess!!

Before I submit such an RFE, I thought I'd run it by you all and get your
input on how you currently handle this dilemma, as well as your feelings
on such an attribute(s).

Mike Davidson
TSYS Tech Support - WebsphereMQ
MikeDavidson-***@public.gmane.org
----------------------------------------- The information contained in
this communication (including any attachments hereto) is confidential and
is intended solely for the personal and confidential use of the individual
or entity to whom it is addressed. If the reader of this message is not
the intended recipient or an agent responsible for delivering it to the
intended recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying, or
unauthorized use of this information, or the taking of any action in
reliance on the contents of this information is strictly prohibited. If
you have received this communication in error, please notify us
immediately by e-mail, and delete the original message. 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

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

<< Seriously? I don't understand why you don't understand what I don't
understand!! >>

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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

Paul Clarke

2013-06-26 15:27:12 UTC

Permalink

As usual T.Rob, much of what you say has merit. However, Iâm not sure Iâd be so quick as to say that the notion of hardening âlast usedâ times is so niche that it is not worth the CPU cost. After all, we havenât yet decided what the actual requirement is. I could imagine that the resolution of the âlast usedâ time need only be to the hour or perhaps even the day. In many case people would be interested in queues which havenât been used for months. In which case the cost of hardening an access of a queue only when first touched that day would seem of very little machine cost. Compare that to running a monitor product or script every hour to collect queues being used and I think youâd find the Queue Manager version would be far more efficient. As to how many customers this would benefit, well isnât that the point of the new RFE system ? Why not put it up there and see how many people vote for the values to be hardened.

I think the general idea of not doing something in the base product just because it could be done in a 3rd party product is flawed. I appreciate I am doing myself out of a job here since I write tools such as MO71 and MQSCX precisely because there are deficiencies in the base product. However it is all a matter of priorities, if enough people find a missing feature annoying enough then surely it should be built in to the base product.

Cheers,
Paul.

Paul Clarke
www.mqgem.com

From: T.Rob
Sent: Wednesday, June 26, 2013 3:07 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

Wow Paul, this is an oversimplification on a grand scale. I'm a bit surprised.

Every queue has a control block associated with it in which the operational status of the queue is stored. Much of WMQ is driven by the API calls made by connected applications, including the update of that control block.

If the requested data were made to persist in the fashion you describe, there would be a race condition during which the QMgr could go down without having updated the value. This is no more reliable than could be achieved with a simple shell script. Would anyone here consider the requirement met if IBM were to provide a simple shell script to capture that data? Or is the requirement specifically to be able to use MQSC and PCF to retrieve the values and we don't necessarily care that they may not be accurate? The notion of having an operational statistic and diagnostic value that is "mostly reliable" would seem to me to be a rather significant change in design philosophy.

Making the statistic not just persistent but *reliably* persistent would require elimination of the race condition which adds to the code path of *every* *API* *call* made within WMQ for the queues where that was enabled. Making the public API code path longer and adding more points of failure is also a rather significant change in design philosophy.

WMQ was built with significant instrumentation capabilities to allow things like Tivoli to capture and record operational aspects. There's an element of that which addresses the questions of "which features does EVERY customer need to pay for?" and "which features and functions support a vibrant 3rd party ecosystem that makes the product more viable and sustainable for all customers?" Every diagnostic and statistic in the product are paid for by all customers so the ones that are there either exist because the need to be there and are merely exposed to the user, or those that are considered so important that *every* customer should pay to support their maintenance in the product. Since there are many ways of capturing this data with the existing instrumentation, even a simple shell script could do it, moving it to the category of "this is so critical that all customers must pay for it, and customers with any sort of monitoring tool will just have to pay for it twice" also seems to me to be a rather change in design philosophy.

The framework to set up cascading defaults from the queue manager down to each queue to communicate the desired behavior to WMQ in a granular fashion is about the only part of this request that might not be a big deal and I'm not entirely sure about that.

-- T.Rob

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Meekin, Paul
Sent: Wednesday, June 26, 2013 3:37 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

Except IBM clearly do see the value in making these values available so I donât think extending them to persist beyond QMgr starts is any real change in design philosophy.

In terms of performance, presumably the data is currently kept in memory so just add a thread to periodically check the values of each queue and update the value on disk if itâs changed.

Paul

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: 25 June 2013 20:35
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

And, again, at some point these stats stop being something used for MQ purposes, and start being used to replace good change management practices.

Particularly outside of a DEV environment, there should be a change management record that backs up the creation of every queue and describes it's role, and ties that creation to a specific team and responsible party, and ideally to the relevant project or product.

Application level backout queues for production apps that are well functioning and receiving data from well behaved systems could conceivable go unaccessed for a long time. But that doesn't mean they aren't needed....

Thank you,

Jeff Lowrey

From: "Potkay, Peter M (CTO Architecture + Engineering)" <Peter.Potkay-***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/25/2013 01:27 PM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

--------------------------------------------------------------------------------

They only need to be written to disk at QM shutdown. Yeah, I guess if there is an abnormal termination of the QM you can't be sure these stats get written to disk. So I suppose its performance related that these stats don't persist. A busy QM with lots of queues would have a tremendous amount of stats needing to be constantly written to disk.

Peter Potkay

--------------------------------------------------------------------------------

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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

T.Rob

2013-06-26 15:59:10 UTC

Permalink

Hi Paul,

I'm not suggesting it should not be an RFE. Only that "do it because it's simple" usually isn't a valid reason. If all the discussion centers on "do it because it's simple" then the RFE will never get out of the gate. But if we stop concentrating on how simple we who don't have access to the code believe that it is and start focusing on what the actual requirement is, what the impact is, and how widespread those are, then we have something against which an RFE might reasonably be evaluated. Some of the issues I'd *hope* people consider were listed in my response below.

Â· Is this something *every* customer should pay for?

Â· Is this something that has broad impact?

Â· Is this something worth adding to the code path of the API?

Â· Is this something that can be "mostly" accurate? If so, what's a useful resolution of accuracy? Paul M said "periodically" you proposed hours or days.

Incidentally, I agree that hardening an access of a queue only when first touched that day does seem of very little machine cost. When the queue is created, that value is zero. That's hardened. We cycle the QMgr once a day and this happens before the value is captured. When the QMgr comes up the value is zero. If we cycle late, some value is actually captured. If we cycle early, it isn't updated.

Clearly, the value would need to be captured with a routine shutdown as well.

But that's a lot like a checkpoint. Maybe we capture it *in* the checkpoint. Then it isn't necessarily in the API but is at least in sync with the hardened state of the queue.

Of course, that leads to a discussion of linear vs. circular logging and whether the behavior should be consistent with that.

âŠ

It's a deep rabbit hole once we start talking about how "simple" it is rather than requirements and impacts.

FWIW I also think the general idea of leaving stuff out of the base product because it competes with Tivoli or the 3rd party ecosystem is flawed. Case in point, basic certificate status reporting. Even some basic cert management. My point wasnât to defend the practice but rather to refute the claim that it doesn't represent "any real change in design philosophy." For better or worse, the design philosophy has been to not compete with Tivoli and 3rd party providers. There are exceptions but those require considerable internal political capital and escalation. Believe me, as a guy who campaigned for a decade just to get WMQ to tell me when a cert is about to expire (and finally had to write himself after leaving IBM) I know how hard that can be. Operating on the assumption that it's simple is very lucrative for people who sell blood pressure meds and antacids but not particularly helpful in getting the product updated.

But all this is IMHO and I'm not trying to moderate the list, but hopefully to provide some insight that results in a useable requirements specification.

-- T.Rob

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Paul Clarke
Sent: Wednesday, June 26, 2013 11:27 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

As usual T.Rob, much of what you say has merit. However, Iâm not sure Iâd be so quick as to say that the notion of hardening âlast usedâ times is so niche that it is not worth the CPU cost. After all, we havenât yet decided what the actual requirement is. I could imagine that the resolution of the âlast usedâ time need only be to the hour or perhaps even the day. In many case people would be interested in queues which havenât been used for months. In which case the cost of hardening an access of a queue only when first touched that day would seem of very little machine cost. Compare that to running a monitor product or script every hour to collect queues being used and I think youâd find the Queue Manager version would be far more efficient. As to how many customers this would benefit, well isnât that the point of the new RFE system ? Why not put it up there and see how many people vote for the values to be hardened.

I think the general idea of not doing something in the base product just because it could be done in a 3rd party product is flawed. I appreciate I am doing myself out of a job here since I write tools such as MO71 and MQSCX precisely because there are deficiencies in the base product. However it is all a matter of priorities, if enough people find a missing feature annoying enough then surely it should be built in to the base product.

Cheers,

Paul.

Paul Clarke
www.mqgem.com

From: T.Rob <mailto:t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org>

Sent: Wednesday, June 26, 2013 3:07 PM

To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org

Subject: Re: Housecleaning for MQ

Wow Paul, this is an oversimplification on a grand scale. I'm a bit surprised.

Every queue has a control block associated with it in which the operational status of the queue is stored. Much of WMQ is driven by the API calls made by connected applications, including the update of that control block.

If the requested data were made to persist in the fashion you describe, there would be a race condition during which the QMgr could go down without having updated the value. This is no more reliable than could be achieved with a simple shell script. Would anyone here consider the requirement met if IBM were to provide a simple shell script to capture that data? Or is the requirement specifically to be able to use MQSC and PCF to retrieve the values and we don't necessarily care that they may not be accurate? The notion of having an operational statistic and diagnostic value that is "mostly reliable" would seem to me to be a rather significant change in design philosophy.

Making the statistic not just persistent but *reliably* persistent would require elimination of the race condition which adds to the code path of *every* *API* *call* made within WMQ for the queues where that was enabled. Making the public API code path longer and adding more points of failure is also a rather significant change in design philosophy.

WMQ was built with significant instrumentation capabilities to allow things like Tivoli to capture and record operational aspects. There's an element of that which addresses the questions of "which features does EVERY customer need to pay for?" and "which features and functions support a vibrant 3rd party ecosystem that makes the product more viable and sustainable for all customers?" Every diagnostic and statistic in the product are paid for by all customers so the ones that are there either exist because the need to be there and are merely exposed to the user, or those that are considered so important that *every* customer should pay to support their maintenance in the product. Since there are many ways of capturing this data with the existing instrumentation, even a simple shell script could do it, moving it to the category of "this is so critical that all customers must pay for it, and customers with any sort of monitoring tool will just have to pay for it twice" also seems to me to be a rather change in design philosophy.

The framework to set up cascading defaults from the queue manager down to each queue to communicate the desired behavior to WMQ in a granular fashion is about the only part of this request that might not be a big deal and I'm not entirely sure about that.

-- T.Rob

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Meekin, Paul
Sent: Wednesday, June 26, 2013 3:37 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

Except IBM clearly do see the value in making these values available so I donât think extending them to persist beyond QMgr starts is any real change in design philosophy.

In terms of performance, presumably the data is currently kept in memory so just add a thread to periodically check the values of each queue and update the value on disk if itâs changed.

Paul

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: 25 June 2013 20:35
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

And, again, at some point these stats stop being something used for MQ purposes, and start being used to replace good change management practices.

Particularly outside of a DEV environment, there should be a change management record that backs up the creation of every queue and describes it's role, and ties that creation to a specific team and responsible party, and ideally to the relevant project or product.

Application level backout queues for production apps that are well functioning and receiving data from well behaved systems could conceivable go unaccessed for a long time. But that doesn't mean they aren't needed....

Thank you,

Jeff Lowrey

From: "Potkay, Peter M (CTO Architecture + Engineering)" <Peter.Potkay-***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/25/2013 01:27 PM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

_____

They only need to be written to disk at QM shutdown. Yeah, I guess if there is an abnormal termination of the QM you can't be sure these stats get written to disk. So I suppose its performance related that these stats don't persist. A busy QM with lots of queues would have a tremendous amount of stats needing to be constantly written to disk.

Peter Potkay

_____

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings <http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe <mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

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

_____

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings <http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe <mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

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

_____

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings <http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe <mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

Bob Juch

2013-06-26 15:18:18 UTC

Permalink

Mike,

What do you use for historical reporting of MQ? Might that keep track of usage?

Bob Juch
Juch Services LLC

Post by Mike Davidson
I confess ignorance (with a little stupidity thrown in) on my part for not
thinking of Queue Status originally.
However, we are actually looking for values that would persist a Qmgr
shutdown for the same reason Gina mentions here. This would be extremely
valuable to us - and apparently to others, as well. ;-)
Mike Davidson
TSYS Tech Support - WebsphereMQ
Date: 06/25/2013 02:00 PM
Subject: Re: Housecleaning for MQ
________________________________
I think it’s a great idea to keep those fields. Why should they refresh when
the qmgr gets recycled?
I have production queues that are only used a few times a year. Also, we are
going through a large ERP implementation over the last few years so, many
production queues are no longer used once the app has been migrated.
We are currently upgrading and replatforming our WMQ distributed
environment. It’s been a bear in trying to determine, in each environment,
the last time each of the hundreds of queues were last used. This would have
(could be) been a godsend. I am finding about 30% haven’t been used in
years.
DIS QSTATUS would not have helped in my case.
Gina
Jefferson Lowrey
Sent: Tuesday, June 25, 2013 1:27 PM
Subject: Re: Housecleaning for MQ
Hi Dave -
I don't keep score here. Other places, maybe... ;-)
I think Mike didn't know about this and reject it before asking his
question, based on his response to Paul.
I also think that any queue that hasn't been gotten from/written to since
the last time the qmgr was restarted is a reasonable candidate for deletion,
even in DEV. I also think that it's easy enough to find out when the qmgr
was last restarted, and make a determination if it's been too short, and
collect data over several days. And, notice, Mike is talking about running
the command several times, over a month or six months or etc, and storing
the data.
I also think, in Dev, that it's a much more complicated problem than just
"nobody's using this queue right now". A set of queues could be unused
during several sprints of a development project, but still be required to
exist in Dev for a forthcoming sprint. So I'm not sure that there's any
data that a queue manager can actually maintain to make up for project
management communications and documentation issues.
But the function of DIS QSTATUS is the same function Mike was looking to
have added, so I don't think an RFE is a reasonable idea.
Thank you,
Jeff Lowrey
From: "David Awerbuch (BLOOMBERG/ 731 LEXIN)"
Date: 06/25/2013 11:05 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
________________________________
Hi Jeff,
LPUTTIME|LGETTIME
"The time at which the last message was [put to|retrieved from] the queue
since the queue manager started. When no [put|get] time is available,
perhaps because no message has been [put to|retrieved from] the queue since
the queue manager was started, the value is shown as a blank."
Many shops restart their development environments on a regular basis, and
this method will not work when the queue manager is started. I can only
guess Mike thought of this before submitting his original request.
Mike 1
Jeff 0
Dave
----- Original Message -----
At: Jun 25 2013 11:52:25
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc12260_.htm
Thank you,
Jeff Lowrey
Date: 06/25/2013 09:49 AM
Subject: [MQSERIES] Housecleaning for MQ
________________________________
Hello Everyone,
We have a bad case of "rabbit" queues (for lack of a better term)... Many of
our Qmgrs simply have too many unused queues defined, especially for the Dev
Qmgrs where developers are allowed to define their own queues for testing.
It'd be nice to clean house occasionally, but we're afraid we might delete a
queue that's needed by someone.
So I was thinking (watch out) - Wouldn't it be nice if there was a
queue-level attribute (or attributes) that reflected a date-time stamp (or
even just date) for the last time that queue was read/written to (Get/Put)?
- call the attributes (LASTREAD & LASTWRITE, or LASTGET & LASTPUT). Then we
could run a report every week, month, or whatever to display the queues not
used in the past 6 months/year/whatever and clean up this mess!!
Before I submit such an RFE, I thought I'd run it by you all and get your
input on how you currently handle this dilemma, as well as your feelings on
such an attribute(s).
Mike Davidson
TSYS Tech Support - WebsphereMQ
----------------------------------------- The information contained in this
communication (including any attachments hereto) is confidential and is
intended solely for the personal and confidential use of the individual or
entity to whom it is addressed. If the reader of this message is not the
intended recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this communication
in error and that any review, dissemination, copying, or unauthorized use of
this information, or the taking of any action in reliance on the contents of
this information is strictly prohibited. If you have received this
communication in error, please notify us immediately by e-mail, and delete
the original message. 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
________________________________
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
<< Seriously? I don't understand why you don't understand what I don't
understand!! >>
________________________________
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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Mike Davidson

2013-06-26 15:54:39 UTC

Permalink

RFE 36571

Mike Davidson
TSYS Tech Support - WebsphereMQ
***@TSYS.com

From: Paul Clarke <***@BTINTERNET.COM>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT,
Date: 06/26/2013 11:28 AM
Subject: Re: Housecleaning for MQ
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT>

As usual T.Rob, much of what you say has merit. However, Iâm not sure Iâd
be so quick as to say that the notion of hardening âlast usedâ times is so
niche that it is not worth the CPU cost. After all, we havenât yet decided
what the actual requirement is. I could imagine that the resolution of the
âlast usedâ time need only be to the hour or perhaps even the day. In many
case people would be interested in queues which havenât been used for
months. In which case the cost of hardening an access of a queue only when
first touched that day would seem of very little machine cost. Compare
that to running a monitor product or script every hour to collect queues
being used and I think youâd find the Queue Manager version would be far
more efficient. As to how many customers this would benefit, well isnât
that the point of the new RFE system ? Why not put it up there and see how
many people vote for the values to be hardened.

I think the general idea of not doing something in the base product just
because it could be done in a 3rd party product is flawed. I appreciate I
am doing myself out of a job here since I write tools such as MO71 and
MQSCX precisely because there are deficiencies in the base product.
However it is all a matter of priorities, if enough people find a missing
feature annoying enough then surely it should be built in to the base
product.

Cheers,
Paul.

Paul Clarke
www.mqgem.com

From: T.Rob
Sent: Wednesday, June 26, 2013 3:07 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Housecleaning for MQ

Wow Paul, this is an oversimplification on a grand scale. I'm a bit
surprised.

Every queue has a control block associated with it in which the
operational status of the queue is stored. Much of WMQ is driven by the
API calls made by connected applications, including the update of that
control block.

If the requested data were made to persist in the fashion you describe,
there would be a race condition during which the QMgr could go down
without having updated the value. This is no more reliable than could be
achieved with a simple shell script. Would anyone here consider the
requirement met if IBM were to provide a simple shell script to capture
that data? Or is the requirement specifically to be able to use MQSC and
PCF to retrieve the values and we don't necessarily care that they may not
be accurate? The notion of having an operational statistic and diagnostic
value that is "mostly reliable" would seem to me to be a rather
significant change in design philosophy.

Making the statistic not just persistent but *reliably* persistent would
require elimination of the race condition which adds to the code path of *
every* *API* *call* made within WMQ for the queues where that was enabled.
Making the public API code path longer and adding more points of failure
is also a rather significant change in design philosophy.

WMQ was built with significant instrumentation capabilities to allow
things like Tivoli to capture and record operational aspects. There's an
element of that which addresses the questions of "which features does
EVERY customer need to pay for?" and "which features and functions
support a vibrant 3rd party ecosystem that makes the product more viable
and sustainable for all customers?" Every diagnostic and statistic in the
product are paid for by all customers so the ones that are there either
exist because the need to be there and are merely exposed to the user, or
those that are considered so important that *every* customer should pay to
support their maintenance in the product. Since there are many ways of
capturing this data with the existing instrumentation, even a simple shell
script could do it, moving it to the category of "this is so critical that
all customers must pay for it, and customers with any sort of monitoring
tool will just have to pay for it twice" also seems to me to be a rather
change in design philosophy.

The framework to set up cascading defaults from the queue manager down to
each queue to communicate the desired behavior to WMQ in a granular
fashion is about the only part of this request that might not be a big
deal and I'm not entirely sure about that.

-- T.Rob

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Meekin, Paul
Sent: Wednesday, June 26, 2013 3:37 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Housecleaning for MQ

Except IBM clearly do see the value in making these values available so I
donât think extending them to persist beyond QMgr starts is any real
change in design philosophy.

In terms of performance, presumably the data is currently kept in memory
so just add a thread to periodically check the values of each queue and
update the value on disk if itâs changed.

Paul

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Jefferson Lowrey
Sent: 25 June 2013 20:35
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Housecleaning for MQ

And, again, at some point these stats stop being something used for MQ
purposes, and start being used to replace good change management
practices.

Particularly outside of a DEV environment, there should be a change
management record that backs up the creation of every queue and describes
it's role, and ties that creation to a specific team and responsible
party, and ideally to the relevant project or product.

Application level backout queues for production apps that are well
functioning and receiving data from well behaved systems could conceivable
go unaccessed for a long time. But that doesn't mean they aren't
needed....

Thank you,

Jeff Lowrey

From: "Potkay, Peter M (CTO Architecture + Engineering)" <
***@THEHARTFORD.COM>
To: ***@listserv.meduniwien.ac.at,
Date: 06/25/2013 01:27 PM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <***@listserv.meduniwien.ac.at>

They only need to be written to disk at QM shutdown. Yeah, I guess if
there is an abnormal termination of the QM you can't be sure these stats
get written to disk. So I suppose its performance related that these stats
don't persist. A busy QM with lots of queues would have a tremendous
amount of stats needing to be constantly written to disk.

Peter Potkay

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

-----------------------------------------
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you

Mike Davidson

2013-06-26 17:28:32 UTC

Permalink

Correct me if I'm wrong (as I've proven myself perfectly capable of
being), but that won't help for the hundreds of queues that have been out
there unused for quite some time.

I know chstatus shows such information (LSTMSGDA, LSTMSGTI), but what
about a similar persistent attribute for channels, as well.

Mike Davidson
TSYS Tech Support - WebsphereMQ
***@TSYS.com

From: Jefferson Lowrey <***@US.IBM.COM>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT,
Date: 06/26/2013 12:29 PM
Subject: Re: Housecleaning for MQ
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT>

It is simple to have this persist.

echo "Dis qstatus(*) all"|runmqsc QmgrName > qstats.log

schedule every hour using cron or your favorite scheduler.

Thank you,

Jeff Lowrey

From: GINA MCCARTHY <***@ARROW.COM>
To: ***@listserv.meduniwien.ac.at,
Date: 06/26/2013 09:21 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <***@listserv.meduniwien.ac.at>

Peter,

I am ecstatic that you have the privilege of having a monitoring *team*,
capable developers, as well a MQ admin team.

We tossed them years ago with the majority of our change control team and
our PM team. There is just no $$ to do that anymore. Our change control
concentrates on our ERP migration.

Our MQ Infrastructure team, as well as our MQ Monitoring team, consist of
1 FTE. Itâs sad, I know. Pathetic even.

It may not be this bad everywhere. However, I do believe that most donât
have it as good as you.

Every MQ tool helps, whether itâs built into the product or a support pac.

Iâve worked with MQ long enough to find creative ways to get the
information I need.

It seems that if IBM records this infoâŠis seems it could be a simple
change to have it persist?

J

Gina

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, June 26, 2013 8:40 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Housecleaning for MQ

Mike,
Check with your monitoring team. Their tools just might have the ability
to record the # of puts and # of gets on a local queue and persist the
values for as long as you want in the monitoring toolâs datastore.

Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Mike Davidson
Sent: Wednesday, June 26, 2013 8:11 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Housecleaning for MQ

I confess ignorance (with a little stupidity thrown in) on my part for not
thinking of Queue Status originally.

However, we are actually looking for values that would persist a Qmgr
shutdown for the same reason Gina mentions here. This would be extremely
valuable to us - and apparently to others, as well. ;-)

Mike Davidson
TSYS Tech Support - WebsphereMQ
***@TSYS.com

From: GINA MCCARTHY <***@ARROW.COM>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT,
Date: 06/25/2013 02:00 PM
Subject: Re: Housecleaning for MQ
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT>

I think itâs a great idea to keep those fields. Why should they refresh
when the qmgr gets recycled?

I have production queues that are only used a few times a year. Also, we
are going through a large ERP implementation over the last few years so,
many production queues are no longer used once the app has been migrated.

We are currently upgrading and replatforming our WMQ distributed
environment. Itâs been a bear in trying to determine, in each environment,
the last time each of the hundreds of queues were last used. This would
have (could be) been a godsend. I am finding about 30% havenât been used
in years.

DIS QSTATUS would not have helped in my case.

Gina

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Jefferson Lowrey
Sent: Tuesday, June 25, 2013 1:27 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Housecleaning for MQ

Hi Dave -
I don't keep score here. Other places, maybe... ;-)

I think Mike didn't know about this and reject it before asking his
question, based on his response to Paul.

I also think that any queue that hasn't been gotten from/written to since
the last time the qmgr was restarted is a reasonable candidate for
deletion, even in DEV. I also think that it's easy enough to find out
when the qmgr was last restarted, and make a determination if it's been
too short, and collect data over several days. And, notice, Mike is
talking about running the command several times, over a month or six
months or etc, and storing the data.

I also think, in Dev, that it's a much more complicated problem than just
"nobody's using this queue right now". A set of queues could be unused
during several sprints of a development project, but still be required to
exist in Dev for a forthcoming sprint. So I'm not sure that there's any
data that a queue manager can actually maintain to make up for project
management communications and documentation issues.

But the function of DIS QSTATUS is the same function Mike was looking to
have added, so I don't think an RFE is a reasonable idea.

Thank you,

Jeff Lowrey

From: "David Awerbuch (BLOOMBERG/ 731 LEXIN)" <
***@bloomberg.net>
To: ***@listserv.meduniwien.ac.at,
Date: 06/25/2013 11:05 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <***@listserv.meduniwien.ac.at>

Hi Jeff,

LPUTTIME|LGETTIME
"The time at which the last message was [put to|retrieved from] the queue
since the queue manager started. When no [put|get] time is available,
perhaps because no message has been [put to|retrieved from] the queue
since the queue manager was started, the value is shown as a blank."

Many shops restart their development environments on a regular basis, and
this method will not work when the queue manager is started. I can only
guess Mike thought of this before submitting his original request.

Mike 1
Jeff 0

Dave

----- Original Message -----
From: ***@LISTSERV.MEDUNIWIEN.AC.AT
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
At: Jun 25 2013 11:52:25
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc12260_.htm

Thank you,

Jeff Lowrey

From: Mike Davidson <***@TSYS.COM>
To: ***@listserv.meduniwien.ac.at,
Date: 06/25/2013 09:49 AM
Subject: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <***@listserv.meduniwien.ac.at>

Hello Everyone,

We have a bad case of "rabbit" queues (for lack of a better term)... Many
of our Qmgrs simply have too many unused queues defined, especially for
the Dev Qmgrs where developers are allowed to define their own queues for
testing. It'd be nice to clean house occasionally, but we're afraid we
might delete a queue that's needed by someone.

So I was thinking (watch out) - Wouldn't it be nice if there was a
queue-level attribute (or attributes) that reflected a date-time stamp (or
even just date) for the last time that queue was read/written to
(Get/Put)? - call the attributes (LASTREAD & LASTWRITE, or LASTGET &
LASTPUT). Then we could run a report every week, month, or whatever to
display the queues not used in the past 6 months/year/whatever and clean
up this mess!!

Before I submit such an RFE, I thought I'd run it by you all and get your
input on how you currently handle this dilemma, as well as your feelings
on such an attribute(s).

Mike Davidson
TSYS Tech Support - WebsphereMQ
***@TSYS.com
----------------------------------------- The information contained in
this communication (including any attachments hereto) is confidential and
is intended solely for the personal and confidential use of the individual
or entity to whom it is addressed. If the reader of this message is not
the intended recipient or an agent responsible for delivering it to the
intended recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying, or
unauthorized use of this information, or the taking of any action in
reliance on the contents of this information is strictly prohibited. If
you have received this communication in error, please notify us
immediately by e-mail, and delete the original message. 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

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

<< Seriously? I don't understand why you don't understand what I don't
understand!! >>

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

Potkay, Peter M (CTO Architecture + Engineering)

2013-06-26 17:48:30 UTC

Permalink

Direct link to Mikeâs RFE:

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

I think the current implementation is just fine for problem resolution. I can tell down to the second when the last put or get occurred, impressing or annoying the audience depending on their current opinion as to whether âthe MQ is brokenâ or not.

For chasing down obsolete queues, the new attribute could be called LASTPUTDATE / LASTGETDATE, something like that. For this type of research down to the day would likely be enough as Paul says. Itâs not likely someone is going to look at this value and make a different decision based on the value being 365 days or 364.9897 days. The proposed attribute would need to handle values that showed the year as well. There are queues used once a year for year end batch, for example.

But the MQ Admin has to have some brainpower and apply logic. A queue called APPA.EXCEPTION.QUEUE â I would not give it a second thought if it wasnât used in a year but APPA.REQUEST.QUEUE was used just last week.

Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Mike Davidson
Sent: Wednesday, June 26, 2013 11:55 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Housecleaning for MQ

RFE 36571

Mike Davidson
TSYS Tech Support - WebsphereMQ
***@TSYS.com<mailto:***@TSYS.com>

From: Paul Clarke <***@BTINTERNET.COM<mailto:***@BTINTERNET.COM>>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>,
Date: 06/26/2013 11:28 AM
Subject: Re: Housecleaning for MQ
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>>
________________________________

As usual T.Rob, much of what you say has merit. However, Iâm not sure Iâd be so quick as to say that the notion of hardening âlast usedâ times is so niche that it is not worth the CPU cost. After all, we havenât yet decided what the actual requirement is. I could imagine that the resolution of the âlast usedâ time need only be to the hour or perhaps even the day. In many case people would be interested in queues which havenât been used for months. In which case the cost of hardening an access of a queue only when first touched that day would seem of very little machine cost. Compare that to running a monitor product or script every hour to collect queues being used and I think youâd find the Queue Manager version would be far more efficient. As to how many customers this would benefit, well isnât that the point of the new RFE system ? Why not put it up there and see how many people vote for the values to be hardened.

I think the general idea of not doing something in the base product just because it could be done in a 3rd party product is flawed. I appreciate I am doing myself out of a job here since I write tools such as MO71 and MQSCX precisely because there are deficiencies in the base product. However it is all a matter of priorities, if enough people find a missing feature annoying enough then surely it should be built in to the base product.

Cheers,
Paul.

Paul Clarke
www.mqgem.com

From: T.Rob<mailto:***@IOPTCONSULTING.COM>
Sent: Wednesday, June 26, 2013 3:07 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Housecleaning for MQ

Wow Paul, this is an oversimplification on a grand scale. I'm a bit surprised.

Every queue has a control block associated with it in which the operational status of the queue is stored. Much of WMQ is driven by the API calls made by connected applications, including the update of that control block.

If the requested data were made to persist in the fashion you describe, there would be a race condition during which the QMgr could go down without having updated the value. This is no more reliable than could be achieved with a simple shell script. Would anyone here consider the requirement met if IBM were to provide a simple shell script to capture that data? Or is the requirement specifically to be able to use MQSC and PCF to retrieve the values and we don't necessarily care that they may not be accurate? The notion of having an operational statistic and diagnostic value that is "mostly reliable" would seem to me to be a rather significant change in design philosophy.

Making the statistic not just persistent but *reliably* persistent would require elimination of the race condition which adds to the code path of *every* *API* *call* made within WMQ for the queues where that was enabled. Making the public API code path longer and adding more points of failure is also a rather significant change in design philosophy.

WMQ was built with significant instrumentation capabilities to allow things like Tivoli to capture and record operational aspects. There's an element of that which addresses the questions of "which features does EVERY customer need to pay for?" and "which features and functions support a vibrant 3rd party ecosystem that makes the product more viable and sustainable for all customers?" Every diagnostic and statistic in the product are paid for by all customers so the ones that are there either exist because the need to be there and are merely exposed to the user, or those that are considered so important that *every* customer should pay to support their maintenance in the product. Since there are many ways of capturing this data with the existing instrumentation, even a simple shell script could do it, moving it to the category of "this is so critical that all customers must pay for it, and customers with any sort of monitoring tool will just have to pay for it twice" also seems to me to be a rather change in design philosophy.

The framework to set up cascading defaults from the queue manager down to each queue to communicate the desired behavior to WMQ in a granular fashion is about the only part of this request that might not be a big deal and I'm not entirely sure about that.

-- T.Rob

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Meekin, Paul
Sent: Wednesday, June 26, 2013 3:37 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Housecleaning for MQ

Except IBM clearly do see the value in making these values available so I donât think extending them to persist beyond QMgr starts is any real change in design philosophy.

In terms of performance, presumably the data is currently kept in memory so just add a thread to periodically check the values of each queue and update the value on disk if itâs changed.

Paul

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jefferson Lowrey
Sent: 25 June 2013 20:35
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Housecleaning for MQ

And, again, at some point these stats stop being something used for MQ purposes, and start being used to replace good change management practices.

Particularly outside of a DEV environment, there should be a change management record that backs up the creation of every queue and describes it's role, and ties that creation to a specific team and responsible party, and ideally to the relevant project or product.

Application level backout queues for production apps that are well functioning and receiving data from well behaved systems could conceivable go unaccessed for a long time. But that doesn't mean they aren't needed....

Thank you,

Jeff Lowrey

From: "Potkay, Peter M (CTO Architecture + Engineering)" <***@THEHARTFORD.COM<mailto:***@THEHARTFORD.COM>>
To: ***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>,
Date: 06/25/2013 01:27 PM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>>
________________________________

They only need to be written to disk at QM shutdown. Yeah, I guess if there is an abnormal termination of the QM you can't be sure these stats get written to disk. So I suppose its performance related that these stats don't persist. A busy QM with lots of queues would have a tremendous amount of stats needing to be constantly written to disk.

Peter Potkay

________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

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

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

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

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
----------------------------------------- The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
************************************************************
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.
************************************************************

Jefferson Lowrey

2013-06-26 17:56:52 UTC

Permalink

Well. Nothing will give you back information about past history, because
it's gone. So the little bit I showed won't help you find out how long
ago a queue was last accessed, before the last time the queue manager was
restarted.

It will help you find out that the queue is still not accessed six months
from now.

But again, you should have had some record of someone asking you to create
this queue. And that record should indicate that there's some purpose
that this queue serves - or the name of the queue itself gives some idea
of the purpose that the queue servers (MyApp.Input.Backout is very likely
a backout queue for the input queue being read by MyApp). And even if
you don't have a real change management team and a real MQ admin team and
a real MQ monitoring team, you should have a folder on your corporate file
system with a spreadsheet or text docs or etc. etc. etc. Just because
it's the only way to keep yourself ahead of the game!

And, again, there's a reasonable chance that a number of useful queues -
particularly outside of dev - will not have been accessed for quite a
while, but are still needed. Backout queues as a sterling example.

Lacking all of this information, and needing to decide *today* that a
given queue is not needed, I would put and get disable it, and remove all
authorities to it and update the description to include a "READY TO
DELETE" flag, and let it sit for a month waiting for the screams. Then
I'd schedule a job to remove all queues that had the flag in their
description in one month. Any queue that got screamed about be altered to
be reenabled and the flag removed from the desc. The previously
mentioned RETINVL could be used instead of the description field.

But that's me, and only after other more reasonable approaches had
produced no useful information about who owned the queue and who was using
or not using it.

Likewise the same general principles apply for channels. If you don't
have any purchased monitoring tools, you can do basic things to dump the
output of runmqsc display commands into text files. Or write a little bit
of perl or java to use PCF messages to gather and store the same info in
files or something. That lets you build up a history of usage from which
you can later make decisions, but if the need is to make a decision today
then don't delete the thing, just disable and de-authorize it and mark it
for deletion later. The perl mq modules are heavily slanted towards
supporting MQ administration tasks, with a lesser emphasis on MQ
application development. So there's a lot of additional helper modules
that do useful things - and although perl is ugly and weird and has not
evolved to smell good it may be easier for an MQ admin to learn than Java.
It has significantly better documentation on all classes, with every doc
including specific examples.

Oh, sorry, didn't realize that was a SOAPBOX under my feet.

Thank you,

Jeff Lowrey

From: Mike Davidson <MikeDavidson-MaERPT+***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/26/2013 11:29 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

Correct me if I'm wrong (as I've proven myself perfectly capable of
being), but that won't help for the hundreds of queues that have been out
there unused for quite some time.

I know chstatus shows such information (LSTMSGDA, LSTMSGTI), but what
about a similar persistent attribute for channels, as well.

Mike Davidson
TSYS Tech Support - WebsphereMQ
MikeDavidson-***@public.gmane.org

From: Jefferson Lowrey <jlowrey-rIXRsD/***@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org,
Date: 06/26/2013 12:29 PM
Subject: Re: Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>

It is simple to have this persist.

echo "Dis qstatus(*) all"|runmqsc QmgrName > qstats.log

schedule every hour using cron or your favorite scheduler.

Thank you,

Jeff Lowrey

From: GINA MCCARTHY <gimccarthy-***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/26/2013 09:21 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

Peter,

I am ecstatic that you have the privilege of having a monitoring *team*,
capable developers, as well a MQ admin team.

We tossed them years ago with the majority of our change control team and
our PM team. There is just no $$ to do that anymore. Our change control
concentrates on our ERP migration.

Our MQ Infrastructure team, as well as our MQ Monitoring team, consist of
1 FTE. It?s sad, I know. Pathetic even.

It may not be this bad everywhere. However, I do believe that most don?t
have it as good as you.

Every MQ tool helps, whether it?s built into the product or a support pac.

I?ve worked with MQ long enough to find creative ways to get the
information I need.

It seems that if IBM records this info?is seems it could be a simple
change to have it persist?

J

Gina

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, June 26, 2013 8:40 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

Mike,
Check with your monitoring team. Their tools just might have the ability
to record the # of puts and # of gets on a local queue and persist the
values for as long as you want in the monitoring tool?s datastore.

Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Mike Davidson
Sent: Wednesday, June 26, 2013 8:11 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

I confess ignorance (with a little stupidity thrown in) on my part for not
thinking of Queue Status originally.

However, we are actually looking for values that would persist a Qmgr
shutdown for the same reason Gina mentions here. This would be extremely
valuable to us - and apparently to others, as well. ;-)

Mike Davidson
TSYS Tech Support - WebsphereMQ
MikeDavidson-***@public.gmane.org

From: GINA MCCARTHY <gimccarthy-***@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org,
Date: 06/25/2013 02:00 PM
Subject: Re: Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>

I think it?s a great idea to keep those fields. Why should they refresh
when the qmgr gets recycled?

I have production queues that are only used a few times a year. Also, we
are going through a large ERP implementation over the last few years so,
many production queues are no longer used once the app has been migrated.

We are currently upgrading and replatforming our WMQ distributed
environment. It?s been a bear in trying to determine, in each environment,
the last time each of the hundreds of queues were last used. This would
have (could be) been a godsend. I am finding about 30% haven?t been used
in years.

DIS QSTATUS would not have helped in my case.

Gina

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Jefferson Lowrey
Sent: Tuesday, June 25, 2013 1:27 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

Hi Dave -
I don't keep score here. Other places, maybe... ;-)

I think Mike didn't know about this and reject it before asking his
question, based on his response to Paul.

I also think that any queue that hasn't been gotten from/written to since
the last time the qmgr was restarted is a reasonable candidate for
deletion, even in DEV. I also think that it's easy enough to find out
when the qmgr was last restarted, and make a determination if it's been
too short, and collect data over several days. And, notice, Mike is
talking about running the command several times, over a month or six
months or etc, and storing the data.

I also think, in Dev, that it's a much more complicated problem than just
"nobody's using this queue right now". A set of queues could be unused
during several sprints of a development project, but still be required to
exist in Dev for a forthcoming sprint. So I'm not sure that there's any
data that a queue manager can actually maintain to make up for project
management communications and documentation issues.

But the function of DIS QSTATUS is the same function Mike was looking to
have added, so I don't think an RFE is a reasonable idea.

Thank you,

Jeff Lowrey

From: "David Awerbuch (BLOOMBERG/ 731 LEXIN)" <
dawerbuch-AlFclGv/***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/25/2013 11:05 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

Hi Jeff,

LPUTTIME|LGETTIME
"The time at which the last message was [put to|retrieved from] the queue
since the queue manager started. When no [put|get] time is available,
perhaps because no message has been [put to|retrieved from] the queue
since the queue manager was started, the value is shown as a blank."

Many shops restart their development environments on a regular basis, and
this method will not work when the queue manager is started. I can only
guess Mike thought of this before submitting his original request.

Mike 1
Jeff 0

Dave

----- Original Message -----
From: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
At: Jun 25 2013 11:52:25
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc12260_.htm

Thank you,

Jeff Lowrey

From: Mike Davidson <MikeDavidson-MaERPT+***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/25/2013 09:49 AM
Subject: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

Hello Everyone,

We have a bad case of "rabbit" queues (for lack of a better term)... Many
of our Qmgrs simply have too many unused queues defined, especially for
the Dev Qmgrs where developers are allowed to define their own queues for
testing. It'd be nice to clean house occasionally, but we're afraid we
might delete a queue that's needed by someone.

So I was thinking (watch out) - Wouldn't it be nice if there was a
queue-level attribute (or attributes) that reflected a date-time stamp (or
even just date) for the last time that queue was read/written to
(Get/Put)? - call the attributes (LASTREAD & LASTWRITE, or LASTGET &
LASTPUT). Then we could run a report every week, month, or whatever to
display the queues not used in the past 6 months/year/whatever and clean
up this mess!!

Before I submit such an RFE, I thought I'd run it by you all and get your
input on how you currently handle this dilemma, as well as your feelings
on such an attribute(s).

Mike Davidson
TSYS Tech Support - WebsphereMQ
MikeDavidson-***@public.gmane.org
----------------------------------------- The information contained in
this communication (including any attachments hereto) is confidential and
is intended solely for the personal and confidential use of the individual
or entity to whom it is addressed. If the reader of this message is not
the intended recipient or an agent responsible for delivering it to the
intended recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying, or
unauthorized use of this information, or the taking of any action in
reliance on the contents of this information is strictly prohibited. If
you have received this communication in error, please notify us
immediately by e-mail, and delete the original message. 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

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

<< Seriously? I don't understand why you don't understand what I don't
understand!! >>

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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

GINA MCCARTHY

2013-06-26 18:43:36 UTC

Permalink

I also use the last used date to reason with a (hoarder) developer, who
asked for the definition, that it's time to let go J

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
Behalf Of Jefferson Lowrey
Sent: Wednesday, June 26, 2013 1:57 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

Well. Nothing will give you back information about past history,
because it's gone. So the little bit I showed won't help you find out
how long ago a queue was last accessed, before the last time the queue
manager was restarted.

It will help you find out that the queue is still not accessed six
months from now.

But again, you should have had some record of someone asking you to
create this queue. And that record should indicate that there's some
purpose that this queue serves - or the name of the queue itself gives
some idea of the purpose that the queue servers (MyApp.Input.Backout is
very likely a backout queue for the input queue being read by MyApp).
And even if you don't have a real change management team and a real MQ
admin team and a real MQ monitoring team, you should have a folder on
your corporate file system with a spreadsheet or text docs or etc. etc.
etc. Just because it's the only way to keep yourself ahead of the
game!

And, again, there's a reasonable chance that a number of useful queues -
particularly outside of dev - will not have been accessed for quite a
while, but are still needed. Backout queues as a sterling example.

Lacking all of this information, and needing to decide *today* that a
given queue is not needed, I would put and get disable it, and remove
all authorities to it and update the description to include a "READY TO
DELETE" flag, and let it sit for a month waiting for the screams. Then
I'd schedule a job to remove all queues that had the flag in their
description in one month. Any queue that got screamed about be altered
to be reenabled and the flag removed from the desc. The previously
mentioned RETINVL could be used instead of the description field.

But that's me, and only after other more reasonable approaches had
produced no useful information about who owned the queue and who was
using or not using it.

Likewise the same general principles apply for channels. If you don't
have any purchased monitoring tools, you can do basic things to dump the
output of runmqsc display commands into text files. Or write a little
bit of perl or java to use PCF messages to gather and store the same
info in files or something. That lets you build up a history of usage
from which you can later make decisions, but if the need is to make a
decision today then don't delete the thing, just disable and
de-authorize it and mark it for deletion later. The perl mq modules
are heavily slanted towards supporting MQ administration tasks, with a
lesser emphasis on MQ application development. So there's a lot of
additional helper modules that do useful things - and although perl is
ugly and weird and has not evolved to smell good it may be easier for an
MQ admin to learn than Java. It has significantly better documentation
on all classes, with every doc including specific examples.

Oh, sorry, didn't realize that was a SOAPBOX under my feet.

Thank you,

Jeff Lowrey

From: Mike Davidson <MikeDavidson-MaERPT+***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/26/2013 11:29 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

________________________________

Correct me if I'm wrong (as I've proven myself perfectly capable of
being), but that won't help for the hundreds of queues that have been
out there unused for quite some time.

I know chstatus shows such information (LSTMSGDA, LSTMSGTI), but what
about a similar persistent attribute for channels, as well.

Mike Davidson
TSYS Tech Support - WebsphereMQ
MikeDavidson-***@public.gmane.org

From: Jefferson Lowrey <jlowrey-rIXRsD/***@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org,
Date: 06/26/2013 12:29 PM
Subject: Re: Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>

________________________________

It is simple to have this persist.

echo "Dis qstatus(*) all"|runmqsc QmgrName > qstats.log

schedule every hour using cron or your favorite scheduler.

Thank you,

Jeff Lowrey

From: GINA MCCARTHY <gimccarthy-***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 06/26/2013 09:21 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

________________________________

Peter,

I am ecstatic that you have the privilege of having a monitoring *team*,
capable developers, as well a MQ admin team.

We tossed them years ago with the majority of our change control team
and our PM team. There is just no $$ to do that anymore. Our change
control concentrates on our ERP migration.

Our MQ Infrastructure team, as well as our MQ Monitoring team, consist
of 1 FTE. It's sad, I know. Pathetic even.

It may not be this bad everywhere. However, I do believe that most
don't have it as good as you.

Every MQ tool helps, whether it's built into the product or a support
pac.

I've worked with MQ long enough to find creative ways to get the
information I need.

It seems that if IBM records this info...is seems it could be a simple
change to have it persist?

J

Gina

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org> ] On Behalf Of Potkay, Peter
M (CTO Architecture + Engineering)
Sent: Wednesday, June 26, 2013 8:40 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

Mike,
Check with your monitoring team. Their tools just might have the ability
to record the # of puts and # of gets on a local queue and persist the
values for as long as you want in the monitoring tool's datastore.

Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org> ] On Behalf Of Mike Davidson
Sent: Wednesday, June 26, 2013 8:11 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
Subject: Re: Housecleaning for MQ

I confess ignorance (with a little stupidity thrown in) on my part for
not thinking of Queue Status originally.

However, we are actually looking for values that would persist a Qmgr
shutdown for the same reason Gina mentions here. This would be extremely
valuable to us - and apparently to others, as well. ;-)

Mike Davidson
TSYS Tech Support - WebsphereMQ
MikeDavidson-***@public.gmane.org <mailto:MikeDavidson-***@public.gmane.org>

From: GINA MCCARTHY <gimccarthy-***@public.gmane.org
<mailto:gimccarthy-***@public.gmane.org> >
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org> ,
Date: 06/25/2013 02:00 PM
Subject: Re: Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org> >

________________________________

I think it's a great idea to keep those fields. Why should they refresh
when the qmgr gets recycled?

I have production queues that are only used a few times a year. Also, we
are going through a large ERP implementation over the last few years so,
many production queues are no longer used once the app has been
migrated.

We are currently upgrading and replatforming our WMQ distributed
environment. It's been a bear in trying to determine, in each
environment, the last time each of the hundreds of queues were last
used. This would have (could be) been a godsend. I am finding about 30%
haven't been used in years.

DIS QSTATUS would not have helped in my case.

Gina

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org> ] On Behalf Of Jefferson
Lowrey
Sent: Tuesday, June 25, 2013 1:27 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
Subject: Re: Housecleaning for MQ

Hi Dave -
I don't keep score here. Other places, maybe... ;-)

I think Mike didn't know about this and reject it before asking his
question, based on his response to Paul.

I also think that any queue that hasn't been gotten from/written to
since the last time the qmgr was restarted is a reasonable candidate for
deletion, even in DEV. I also think that it's easy enough to find out
when the qmgr was last restarted, and make a determination if it's been
too short, and collect data over several days. And, notice, Mike is
talking about running the command several times, over a month or six
months or etc, and storing the data.

I also think, in Dev, that it's a much more complicated problem than
just "nobody's using this queue right now". A set of queues could be
unused during several sprints of a development project, but still be
required to exist in Dev for a forthcoming sprint. So I'm not sure
that there's any data that a queue manager can actually maintain to make
up for project management communications and documentation issues.

But the function of DIS QSTATUS is the same function Mike was looking to
have added, so I don't think an RFE is a reasonable idea.

Thank you,

Jeff Lowrey

From: "David Awerbuch (BLOOMBERG/ 731 LEXIN)"
<dawerbuch-AlFclGv/***@public.gmane.org <mailto:dawerbuch-AlFclGv/***@public.gmane.org> >
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org
<mailto:MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org> ,
Date: 06/25/2013 11:05 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org
<mailto:MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org> >

________________________________

Hi Jeff,

LPUTTIME|LGETTIME
"The time at which the last message was [put to|retrieved from] the
queue since the queue manager started. When no [put|get] time is
available, perhaps because no message has been [put to|retrieved from]
the queue since the queue manager was started, the value is shown as a
blank."

Many shops restart their development environments on a regular basis,
and this method will not work when the queue manager is started. I can
only guess Mike thought of this before submitting his original request.

Mike 1
Jeff 0

Dave

----- Original Message -----
From: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
At: Jun 25 2013 11:52:25
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc1226
0_.htm
<http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc122
60_.htm>

Thank you,

Jeff Lowrey

From: Mike Davidson <MikeDavidson-MaERPT+***@public.gmane.org
<mailto:MikeDavidson-MaERPT+***@public.gmane.org> >
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org
<mailto:MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org> ,
Date: 06/25/2013 09:49 AM
Subject: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org
<mailto:MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org> >

________________________________

Hello Everyone,

We have a bad case of "rabbit" queues (for lack of a better term)...
Many of our Qmgrs simply have too many unused queues defined, especially
for the Dev Qmgrs where developers are allowed to define their own
queues for testing. It'd be nice to clean house occasionally, but we're
afraid we might delete a queue that's needed by someone.

So I was thinking (watch out) - Wouldn't it be nice if there was a
queue-level attribute (or attributes) that reflected a date-time stamp
(or even just date) for the last time that queue was read/written to
(Get/Put)? - call the attributes (LASTREAD & LASTWRITE, or LASTGET &
LASTPUT). Then we could run a report every week, month, or whatever to
display the queues not used in the past 6 months/year/whatever and clean
up this mess!!

Before I submit such an RFE, I thought I'd run it by you all and get
your input on how you currently handle this dilemma, as well as your
feelings on such an attribute(s).

Mike Davidson
TSYS Tech Support - WebsphereMQ
MikeDavidson-***@public.gmane.org <mailto:MikeDavidson-***@public.gmane.org>
----------------------------------------- The information contained in
this communication (including any attachments hereto) is confidential
and is intended solely for the personal and confidential use of the
individual or entity to whom it is addressed. If the reader of this
message is not the intended recipient or an agent responsible for
delivering it to the intended recipient, you are hereby notified that
you have received this communication in error and that any review,
dissemination, copying, or unauthorized use of this information, or the
taking of any action in reliance on the contents of this information is
strictly prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original message.
Thank you

________________________________

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=sign
off%20mqseries>

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

________________________________

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=sign
off%20mqseries>

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

<< Seriously? I don't understand why you don't understand what I don't
understand!! >>

________________________________

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=sign
off%20mqseries>

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

________________________________

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=sign
off%20mqseries>

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

************************************************************
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 <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=sign
off%20mqseries>

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

________________________________

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=sign
off%20mqseries>

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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@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

Ram

2013-06-26 22:38:41 UTC

Permalink

MQ already provides enough hooks (for one reset qstats on daily basis would do the job & offers wealth of insight into application behavior) to derive at this info. Sorry ,personally I wouldn't want this implemented to compensate for the functions offered by historical/capacity management vendor tools and practices which are quite prevalent in large organizations dealing with loads of queue's and queue managers. To me it's not a deficiency with in product , as it is ,data points are provided and some computing is required to derive at information.

Ram Ramanathan

Well. Nothing will give you back information about past history, because it's gone. So the little bit I showed won't help you find out how long ago a queue was last accessed, before the last time the queue manager was restarted.
It will help you find out that the queue is still not accessed six months from now.
But again, you should have had some record of someone asking you to create this queue. And that record should indicate that there's some purpose that this queue serves - or the name of the queue itself gives some idea of the purpose that the queue servers (MyApp.Input.Backout is very likely a backout queue for the input queue being read by MyApp). And even if you don't have a real change management team and a real MQ admin team and a real MQ monitoring team, you should have a folder on your corporate file system with a spreadsheet or text docs or etc. etc. etc. Just because it's the only way to keep yourself ahead of the game!
And, again, there's a reasonable chance that a number of useful queues - particularly outside of dev - will not have been accessed for quite a while, but are still needed. Backout queues as a sterling example.
Lacking all of this information, and needing to decide *today* that a given queue is not needed, I would put and get disable it, and remove all authorities to it and update the description to include a "READY TO DELETE" flag, and let it sit for a month waiting for the screams. Then I'd schedule a job to remove all queues that had the flag in their description in one month. Any queue that got screamed about be altered to be reenabled and the flag removed from the desc. The previously mentioned RETINVL could be used instead of the description field.
But that's me, and only after other more reasonable approaches had produced no useful information about who owned the queue and who was using or not using it.
Likewise the same general principles apply for channels. If you don't have any purchased monitoring tools, you can do basic things to dump the output of runmqsc display commands into text files. Or write a little bit of perl or java to use PCF messages to gather and store the same info in files or something. That lets you build up a history of usage from which you can later make decisions, but if the need is to make a decision today then don't delete the thing, just disable and de-authorize it and mark it for deletion later. The perl mq modules are heavily slanted towards supporting MQ administration tasks, with a lesser emphasis on MQ application development. So there's a lot of additional helper modules that do useful things - and although perl is ugly and weird and has not evolved to smell good it may be easier for an MQ admin to learn than Java. It has significantly better documentation on all classes, with every doc including specific examples.
Oh, sorry, didn't realize that was a SOAPBOX under my feet.
Thank you,
Jeff Lowrey
Date: 06/26/2013 11:29 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
Correct me if I'm wrong (as I've proven myself perfectly capable of being), but that won't help for the hundreds of queues that have been out there unused for quite some time.
I know chstatus shows such information (LSTMSGDA, LSTMSGTI), but what about a similar persistent attribute for channels, as well.
Mike Davidson
TSYS Tech Support - WebsphereMQ
Date: 06/26/2013 12:29 PM
Subject: Re: Housecleaning for MQ
It is simple to have this persist.
echo "Dis qstatus(*) all"|runmqsc QmgrName > qstats.log
schedule every hour using cron or your favorite scheduler.
Thank you,
Jeff Lowrey
Date: 06/26/2013 09:21 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
Peter,
I am ecstatic that you have the privilege of having a monitoring *team*, capable developers, as well a MQ admin team.
We tossed them years ago with the majority of our change control team and our PM team. There is just no $$ to do that anymore. Our change control concentrates on our ERP migration.
Our MQ Infrastructure team, as well as our MQ Monitoring team, consist of 1 FTE. Itâs sad, I know. Pathetic even.
It may not be this bad everywhere. However, I do believe that most donât have it as good as you.
Every MQ tool helps, whether itâs built into the product or a support pac.
Iâve worked with MQ long enough to find creative ways to get the information I need.
It seems that if IBM records this infoâŠis seems it could be a simple change to have it persist?
J
Gina
Sent: Wednesday, June 26, 2013 8:40 AM
Subject: Re: Housecleaning for MQ
Mike,
Check with your monitoring team. Their tools just might have the ability to record the # of puts and # of gets on a local queue and persist the values for as long as you want in the monitoring toolâs datastore.
Peter Potkay
Sent: Wednesday, June 26, 2013 8:11 AM
Subject: Re: Housecleaning for MQ
I confess ignorance (with a little stupidity thrown in) on my part for not thinking of Queue Status originally.
However, we are actually looking for values that would persist a Qmgr shutdown for the same reason Gina mentions here. This would be extremely valuable to us - and apparently to others, as well. ;-)
Mike Davidson
TSYS Tech Support - WebsphereMQ
Date: 06/25/2013 02:00 PM
Subject: Re: Housecleaning for MQ
I think itâs a great idea to keep those fields. Why should they refresh when the qmgr gets recycled?
I have production queues that are only used a few times a year. Also, we are going through a large ERP implementation over the last few years so, many production queues are no longer used once the app has been migrated.
We are currently upgrading and replatforming our WMQ distributed environment. Itâs been a bear in trying to determine, in each environment, the last time each of the hundreds of queues were last used. This would have (could be) been a godsend. I am finding about 30% havenât been used in years.
DIS QSTATUS would not have helped in my case.
Gina
Sent: Tuesday, June 25, 2013 1:27 PM
Subject: Re: Housecleaning for MQ
Hi Dave -
I don't keep score here. Other places, maybe... ;-)
I think Mike didn't know about this and reject it before asking his question, based on his response to Paul.
I also think that any queue that hasn't been gotten from/written to since the last time the qmgr was restarted is a reasonable candidate for deletion, even in DEV. I also think that it's easy enough to find out when the qmgr was last restarted, and make a determination if it's been too short, and collect data over several days. And, notice, Mike is talking about running the command several times, over a month or six months or etc, and storing the data.
I also think, in Dev, that it's a much more complicated problem than just "nobody's using this queue right now". A set of queues could be unused during several sprints of a development project, but still be required to exist in Dev for a forthcoming sprint. So I'm not sure that there's any data that a queue manager can actually maintain to make up for project management communications and documentation issues.
But the function of DIS QSTATUS is the same function Mike was looking to have added, so I don't think an RFE is a reasonable idea.
Thank you,
Jeff Lowrey
Date: 06/25/2013 11:05 AM
Subject: Re: [MQSERIES] Housecleaning for MQ
Hi Jeff,
LPUTTIME|LGETTIME
"The time at which the last message was [put to|retrieved from] the queue since the queue manager started. When no [put|get] time is available, perhaps because no message has been [put to|retrieved from] the queue since the queue manager was started, the value is shown as a blank."
Many shops restart their development environments on a regular basis, and this method will not work when the queue manager is started. I can only guess Mike thought of this before submitting his original request.
Mike 1
Jeff 0
Dave
----- Original Message -----
At: Jun 25 2013 11:52:25
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/sc12260_.htm
Thank you,
Jeff Lowrey
Date: 06/25/2013 09:49 AM
Subject: [MQSERIES] Housecleaning for MQ
Hello Everyone,
We have a bad case of "rabbit" queues (for lack of a better term)... Many of our Qmgrs simply have too many unused queues defined, especially for the Dev Qmgrs where developers are allowed to define their own queues for testing. It'd be nice to clean house occasionally, but we're afraid we might delete a queue that's needed by someone.
So I was thinking (watch out) - Wouldn't it be nice if there was a queue-level attribute (or attributes) that reflected a date-time stamp (or even just date) for the last time that queue was read/written to (Get/Put)? - call the attributes (LASTREAD & LASTWRITE, or LASTGET & LASTPUT). Then we could run a report every week, month, or whatever to display the queues not used in the past 6 months/year/whatever and clean up this mess!!
Before I submit such an RFE, I thought I'd run it by you all and get your input on how you currently handle this dilemma, as well as your feelings on such an attribute(s).
Mike Davidson
TSYS Tech Support - WebsphereMQ
----------------------------------------- The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. 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
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
<< Seriously? I don't understand why you don't understand what I don't understand!! >>
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
************************************************************
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
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

Bruce Lerner

2013-06-27 12:23:03 UTC

Permalink

I gather that this thread is about WMQ on distributed systems.

On WMQ for z/OS, SMF statistics and accounting information can be captured
for this and other types of queue usage. SMF record types 115 and 116 are
created for historical reference and capacity planning.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Tim Zielke

2013-06-27 12:35:00 UTC

Permalink

There have been times I wanted something like this for the distributed environment, so I voted for the RFE.

I am wondering though for robustness if the RFE should be for last_opened time. It could be possible there is an application out there that was just opening the queue and doing an inquire on it, that would not be detected with this RFE proposal. The last_opened time would capture an implicit open with an MQPUT1.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, June 26, 2013 12:49 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Housecleaning for MQ

Direct link to Mikeâs RFE:

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

I think the current implementation is just fine for problem resolution. I can tell down to the second when the last put or get occurred, impressing or annoying the audience depending on their current opinion as to whether âthe MQ is brokenâ or not.

For chasing down obsolete queues, the new attribute could be called LASTPUTDATE / LASTGETDATE, something like that. For this type of research down to the day would likely be enough as Paul says. Itâs not likely someone is going to look at this value and make a different decision based on the value being 365 days or 364.9897 days. The proposed attribute would need to handle values that showed the year as well. There are queues used once a year for year end batch, for example.

But the MQ Admin has to have some brainpower and apply logic. A queue called APPA.EXCEPTION.QUEUE â I would not give it a second thought if it wasnât used in a year but APPA.REQUEST.QUEUE was used just last week.

Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Mike Davidson
Sent: Wednesday, June 26, 2013 11:55 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Housecleaning for MQ

RFE 36571

Mike Davidson
TSYS Tech Support - WebsphereMQ
***@TSYS.com<mailto:***@TSYS.com>

From: Paul Clarke <***@BTINTERNET.COM<mailto:***@BTINTERNET.COM>>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>,
Date: 06/26/2013 11:28 AM
Subject: Re: Housecleaning for MQ
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>>
________________________________

As usual T.Rob, much of what you say has merit. However, Iâm not sure Iâd be so quick as to say that the notion of hardening âlast usedâ times is so niche that it is not worth the CPU cost. After all, we havenât yet decided what the actual requirement is. I could imagine that the resolution of the âlast usedâ time need only be to the hour or perhaps even the day. In many case people would be interested in queues which havenât been used for months. In which case the cost of hardening an access of a queue only when first touched that day would seem of very little machine cost. Compare that to running a monitor product or script every hour to collect queues being used and I think youâd find the Queue Manager version would be far more efficient. As to how many customers this would benefit, well isnât that the point of the new RFE system ? Why not put it up there and see how many people vote for the values to be hardened.

I think the general idea of not doing something in the base product just because it could be done in a 3rd party product is flawed. I appreciate I am doing myself out of a job here since I write tools such as MO71 and MQSCX precisely because there are deficiencies in the base product. However it is all a matter of priorities, if enough people find a missing feature annoying enough then surely it should be built in to the base product.

Cheers,
Paul.

Paul Clarke
www.mqgem.com

From: T.Rob<mailto:***@IOPTCONSULTING.COM>
Sent: Wednesday, June 26, 2013 3:07 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Housecleaning for MQ

Wow Paul, this is an oversimplification on a grand scale. I'm a bit surprised.

Every queue has a control block associated with it in which the operational status of the queue is stored. Much of WMQ is driven by the API calls made by connected applications, including the update of that control block.

If the requested data were made to persist in the fashion you describe, there would be a race condition during which the QMgr could go down without having updated the value. This is no more reliable than could be achieved with a simple shell script. Would anyone here consider the requirement met if IBM were to provide a simple shell script to capture that data? Or is the requirement specifically to be able to use MQSC and PCF to retrieve the values and we don't necessarily care that they may not be accurate? The notion of having an operational statistic and diagnostic value that is "mostly reliable" would seem to me to be a rather significant change in design philosophy.

Making the statistic not just persistent but *reliably* persistent would require elimination of the race condition which adds to the code path of *every* *API* *call* made within WMQ for the queues where that was enabled. Making the public API code path longer and adding more points of failure is also a rather significant change in design philosophy.

WMQ was built with significant instrumentation capabilities to allow things like Tivoli to capture and record operational aspects. There's an element of that which addresses the questions of "which features does EVERY customer need to pay for?" and "which features and functions support a vibrant 3rd party ecosystem that makes the product more viable and sustainable for all customers?" Every diagnostic and statistic in the product are paid for by all customers so the ones that are there either exist because the need to be there and are merely exposed to the user, or those that are considered so important that *every* customer should pay to support their maintenance in the product. Since there are many ways of capturing this data with the existing instrumentation, even a simple shell script could do it, moving it to the category of "this is so critical that all customers must pay for it, and customers with any sort of monitoring tool will just have to pay for it twice" also seems to me to be a rather change in design philosophy.

The framework to set up cascading defaults from the queue manager down to each queue to communicate the desired behavior to WMQ in a granular fashion is about the only part of this request that might not be a big deal and I'm not entirely sure about that.

-- T.Rob

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Meekin, Paul
Sent: Wednesday, June 26, 2013 3:37 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Housecleaning for MQ

Except IBM clearly do see the value in making these values available so I donât think extending them to persist beyond QMgr starts is any real change in design philosophy.

In terms of performance, presumably the data is currently kept in memory so just add a thread to periodically check the values of each queue and update the value on disk if itâs changed.

Paul

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jefferson Lowrey
Sent: 25 June 2013 20:35
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Housecleaning for MQ

And, again, at some point these stats stop being something used for MQ purposes, and start being used to replace good change management practices.

Particularly outside of a DEV environment, there should be a change management record that backs up the creation of every queue and describes it's role, and ties that creation to a specific team and responsible party, and ideally to the relevant project or product.

Application level backout queues for production apps that are well functioning and receiving data from well behaved systems could conceivable go unaccessed for a long time. But that doesn't mean they aren't needed....

Thank you,

Jeff Lowrey

From: "Potkay, Peter M (CTO Architecture + Engineering)" <***@THEHARTFORD.COM<mailto:***@THEHARTFORD.COM>>
To: ***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>,
Date: 06/25/2013 01:27 PM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>>
________________________________

They only need to be written to disk at QM shutdown. Yeah, I guess if there is an abnormal termination of the QM you can't be sure these stats get written to disk. So I suppose its performance related that these stats don't persist. A busy QM with lots of queues would have a tremendous amount of stats needing to be constantly written to disk.

Peter Potkay

________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

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

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

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

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
----------------------------------------- The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you

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

Mike Davidson

2013-06-27 18:26:53 UTC

Permalink

Thanks everyone for the input/suggestions/"Amens"...

While I do understand that there are other avenues we could pursue, such
as the ones that have been mentioned by folks - I am certain that we (and
others) would benefit by such a queue/channel attribute. If you agree -
get out there and vote. ;-)
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=36571

Several suggestions alluded to forcing misbehaved developers to follow
good, well-defined practices/procedures... please tell us your secret to
growing such developers.

Mike Davidson
TSYS Tech Support - WebsphereMQ
***@TSYS.com

From: Paul Clarke <***@BTINTERNET.COM>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT,
Date: 06/26/2013 11:28 AM
Subject: Re: Housecleaning for MQ
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT>

As usual T.Rob, much of what you say has merit. However, Iâm not sure Iâd
be so quick as to say that the notion of hardening âlast usedâ times is so
niche that it is not worth the CPU cost. After all, we havenât yet decided
what the actual requirement is. I could imagine that the resolution of the
âlast usedâ time need only be to the hour or perhaps even the day. In many
case people would be interested in queues which havenât been used for
months. In which case the cost of hardening an access of a queue only when
first touched that day would seem of very little machine cost. Compare
that to running a monitor product or script every hour to collect queues
being used and I think youâd find the Queue Manager version would be far
more efficient. As to how many customers this would benefit, well isnât
that the point of the new RFE system ? Why not put it up there and see how
many people vote for the values to be hardened.

I think the general idea of not doing something in the base product just
because it could be done in a 3rd party product is flawed. I appreciate I
am doing myself out of a job here since I write tools such as MO71 and
MQSCX precisely because there are deficiencies in the base product.
However it is all a matter of priorities, if enough people find a missing
feature annoying enough then surely it should be built in to the base
product.

Cheers,
Paul.

Paul Clarke
www.mqgem.com

From: T.Rob
Sent: Wednesday, June 26, 2013 3:07 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Housecleaning for MQ

Wow Paul, this is an oversimplification on a grand scale. I'm a bit
surprised.

Every queue has a control block associated with it in which the
operational status of the queue is stored. Much of WMQ is driven by the
API calls made by connected applications, including the update of that
control block.

If the requested data were made to persist in the fashion you describe,
there would be a race condition during which the QMgr could go down
without having updated the value. This is no more reliable than could be
achieved with a simple shell script. Would anyone here consider the
requirement met if IBM were to provide a simple shell script to capture
that data? Or is the requirement specifically to be able to use MQSC and
PCF to retrieve the values and we don't necessarily care that they may not
be accurate? The notion of having an operational statistic and diagnostic
value that is "mostly reliable" would seem to me to be a rather
significant change in design philosophy.

Making the statistic not just persistent but *reliably* persistent would
require elimination of the race condition which adds to the code path of *
every* *API* *call* made within WMQ for the queues where that was enabled.
Making the public API code path longer and adding more points of failure
is also a rather significant change in design philosophy.

WMQ was built with significant instrumentation capabilities to allow
things like Tivoli to capture and record operational aspects. There's an
element of that which addresses the questions of "which features does
EVERY customer need to pay for?" and "which features and functions
support a vibrant 3rd party ecosystem that makes the product more viable
and sustainable for all customers?" Every diagnostic and statistic in the
product are paid for by all customers so the ones that are there either
exist because the need to be there and are merely exposed to the user, or
those that are considered so important that *every* customer should pay to
support their maintenance in the product. Since there are many ways of
capturing this data with the existing instrumentation, even a simple shell
script could do it, moving it to the category of "this is so critical that
all customers must pay for it, and customers with any sort of monitoring
tool will just have to pay for it twice" also seems to me to be a rather
change in design philosophy.

The framework to set up cascading defaults from the queue manager down to
each queue to communicate the desired behavior to WMQ in a granular
fashion is about the only part of this request that might not be a big
deal and I'm not entirely sure about that.

-- T.Rob

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Meekin, Paul
Sent: Wednesday, June 26, 2013 3:37 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Housecleaning for MQ

Except IBM clearly do see the value in making these values available so I
donât think extending them to persist beyond QMgr starts is any real
change in design philosophy.

In terms of performance, presumably the data is currently kept in memory
so just add a thread to periodically check the values of each queue and
update the value on disk if itâs changed.

Paul

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Jefferson Lowrey
Sent: 25 June 2013 20:35
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Housecleaning for MQ

And, again, at some point these stats stop being something used for MQ
purposes, and start being used to replace good change management
practices.

Particularly outside of a DEV environment, there should be a change
management record that backs up the creation of every queue and describes
it's role, and ties that creation to a specific team and responsible
party, and ideally to the relevant project or product.

Application level backout queues for production apps that are well
functioning and receiving data from well behaved systems could conceivable
go unaccessed for a long time. But that doesn't mean they aren't
needed....

Thank you,

Jeff Lowrey

From: "Potkay, Peter M (CTO Architecture + Engineering)" <
***@THEHARTFORD.COM>
To: ***@listserv.meduniwien.ac.at,
Date: 06/25/2013 01:27 PM
Subject: Re: [MQSERIES] Housecleaning for MQ
Sent by: MQSeries List <***@listserv.meduniwien.ac.at>

They only need to be written to disk at QM shutdown. Yeah, I guess if
there is an abnormal termination of the QM you can't be sure these stats
get written to disk. So I suppose its performance related that these stats
don't persist. A busy QM with lots of queues would have a tremendous
amount of stats needing to be constantly written to disk.

Peter Potkay

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

-----------------------------------------
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you

Bob Juch

2013-06-27 19:38:32 UTC

Permalink

Mike,

The secret to growing well-behaved developers is to not let them use
your queue managers, even for development, without approving their
design and examining their API code. Then you don't trust them to code
following their design and double-check before their code is migrated
into IST, UAT, and production systems. That's what I did at Citibank
(and by proxy with some of yours at that time).

Bob Juch
Juch Services LLC

Post by Mike Davidson
Thanks everyone for the input/suggestions/"Amens"...
While I do understand that there are other avenues we could pursue, such as
the ones that have been mentioned by folks - I am certain that we (and
others) would benefit by such a queue/channel attribute. If you agree - get
out there and vote. ;-)
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=36571
Several suggestions alluded to forcing misbehaved developers to follow good,
well-defined practices/procedures... please tell us your secret to growing
such developers.
Mike Davidson
TSYS Tech Support - WebsphereMQ
Date: 06/26/2013 11:28 AM
Subject: Re: Housecleaning for MQ
________________________________
As usual T.Rob, much of what you say has merit. However, I’m not sure I’d be
so quick as to say that the notion of hardening ‘last used’ times is so
niche that it is not worth the CPU cost. After all, we haven’t yet decided
what the actual requirement is. I could imagine that the resolution of the
‘last used’ time need only be to the hour or perhaps even the day. In many
case people would be interested in queues which haven’t been used for
months. In which case the cost of hardening an access of a queue only when
first touched that day would seem of very little machine cost. Compare that
to running a monitor product or script every hour to collect queues being
used and I think you’d find the Queue Manager version would be far more
efficient. As to how many customers this would benefit, well isn’t that the
point of the new RFE system ? Why not put it up there and see how many
people vote for the values to be hardened.
I think the general idea of not doing something in the base product just
because it could be done in a 3rd party product is flawed. I appreciate I am
doing myself out of a job here since I write tools such as MO71 and MQSCX
precisely because there are deficiencies in the base product. However it is
all a matter of priorities, if enough people find a missing feature annoying
enough then surely it should be built in to the base product.
Cheers,
Paul.
Paul Clarke
www.mqgem.com
From: T.Rob
Sent: Wednesday, June 26, 2013 3:07 PM
Subject: Re: Housecleaning for MQ
Wow Paul, this is an oversimplification on a grand scale. I'm a bit
surprised.
Every queue has a control block associated with it in which the operational
status of the queue is stored. Much of WMQ is driven by the API calls made
by connected applications, including the update of that control block.
If the requested data were made to persist in the fashion you describe,
there would be a race condition during which the QMgr could go down without
having updated the value. This is no more reliable than could be achieved
with a simple shell script. Would anyone here consider the requirement met
if IBM were to provide a simple shell script to capture that data? Or is
the requirement specifically to be able to use MQSC and PCF to retrieve the
values and we don't necessarily care that they may not be accurate? The
notion of having an operational statistic and diagnostic value that is
"mostly reliable" would seem to me to be a rather significant change in
design philosophy.
Making the statistic not just persistent but *reliably* persistent would
require elimination of the race condition which adds to the code path of
*every* *API* *call* made within WMQ for the queues where that was enabled.
Making the public API code path longer and adding more points of failure is
also a rather significant change in design philosophy.
WMQ was built with significant instrumentation capabilities to allow things
like Tivoli to capture and record operational aspects. There's an element
of that which addresses the questions of "which features does EVERY customer
need to pay for?" and "which features and functions support a vibrant 3rd
party ecosystem that makes the product more viable and sustainable for all
customers?" Every diagnostic and statistic in the product are paid for by
all customers so the ones that are there either exist because the need to be
there and are merely exposed to the user, or those that are considered so
important that *every* customer should pay to support their maintenance in
the product. Since there are many ways of capturing this data with the
existing instrumentation, even a simple shell script could do it, moving it
to the category of "this is so critical that all customers must pay for it,
and customers with any sort of monitoring tool will just have to pay for it
twice" also seems to me to be a rather change in design philosophy.
The framework to set up cascading defaults from the queue manager down to
each queue to communicate the desired behavior to WMQ in a granular fashion
is about the only part of this request that might not be a big deal and I'm
not entirely sure about that.
-- T.Rob
Meekin, Paul
Sent: Wednesday, June 26, 2013 3:37 AM
Subject: Re: Housecleaning for MQ
Except IBM clearly do see the value in making these values available so I
don’t think extending them to persist beyond QMgr starts is any real change
in design philosophy.
In terms of performance, presumably the data is currently kept in memory so
just add a thread to periodically check the values of each queue and update
the value on disk if it’s changed.
Paul
Jefferson Lowrey
Sent: 25 June 2013 20:35
Subject: Re: Housecleaning for MQ
And, again, at some point these stats stop being something used for MQ
purposes, and start being used to replace good change management practices.
Particularly outside of a DEV environment, there should be a change
management record that backs up the creation of every queue and describes
it's role, and ties that creation to a specific team and responsible party,
and ideally to the relevant project or product.
Application level backout queues for production apps that are well
functioning and receiving data from well behaved systems could conceivable
go unaccessed for a long time. But that doesn't mean they aren't needed....
Thank you,
Jeff Lowrey
From: "Potkay, Peter M (CTO Architecture + Engineering)"
Date: 06/25/2013 01:27 PM
Subject: Re: [MQSERIES] Housecleaning for MQ
________________________________
They only need to be written to disk at QM shutdown. Yeah, I guess if there
is an abnormal termination of the QM you can't be sure these stats get
written to disk. So I suppose its performance related that these stats don't
persist. A busy QM with lots of queues would have a tremendous amount of
stats needing to be constantly written to disk.
Peter Potkay
________________________________
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
----------------------------------------- The information contained in this
communication (including any attachments hereto) is confidential and is
intended solely for the personal and confidential use of the individual or
entity to whom it is addressed. If the reader of this message is not the
intended recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this communication
in error and that any review, dissemination, copying, or unauthorized use of
this information, or the taking of any action in reliance on the contents of
this information is strictly prohibited. If you have received this
communication in error, please notify us immediately by e-mail, and delete
the original message. Thank you

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Tim Zielke

2013-07-05 15:55:50 UTC

Permalink

One thing to add about examining the API code is that we have started to use the Application Activity Trace. I believe that became available with 7.1. We just used it to flush out a significant performance issue for one of our new MQ applications where they were doing a GET without a WAIT, and they were building in an unnecessary 5-10 second delay in the application flow.

This doc does a good job in going over the Application Activity Trace. -> http://www.ibm.com/developerworks/websphere/library/techarticles/1306_bushby/1306_bushby.html

One note though. There is a current bug in the Application Activity Trace where a null pointer is being dereferenced and the queue manager can receive internal errors or crash when the Application Activity Trace is turned on. However, IBM does have a fix for it. -> http://www-01.ibm.com/support/docview.wss?uid=swg1IC83723

Thanks,
Tim

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Bob Juch
Sent: Thursday, June 27, 2013 2:39 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Housecleaning for MQ

Mike,

The secret to growing well-behaved developers is to not let them use
your queue managers, even for development, without approving their
design and examining their API code. Then you don't trust them to code
following their design and double-check before their code is migrated
into IST, UAT, and production systems. That's what I did at Citibank
(and by proxy with some of yours at that time).

Bob Juch
Juch Services LLC

Post by Mike Davidson
Thanks everyone for the input/suggestions/"Amens"...
While I do understand that there are other avenues we could pursue, such as
the ones that have been mentioned by folks - I am certain that we (and
others) would benefit by such a queue/channel attribute. If you agree - get
out there and vote. ;-)
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=36571
Several suggestions alluded to forcing misbehaved developers to follow good,
well-defined practices/procedures... please tell us your secret to growing
such developers.
Mike Davidson
TSYS Tech Support - WebsphereMQ
Date: 06/26/2013 11:28 AM
Subject: Re: Housecleaning for MQ
________________________________
As usual T.Rob, much of what you say has merit. However, I'm not sure I'd be
so quick as to say that the notion of hardening 'last used' times is so
niche that it is not worth the CPU cost. After all, we haven't yet decided
what the actual requirement is. I could imagine that the resolution of the
'last used' time need only be to the hour or perhaps even the day. In many
case people would be interested in queues which haven't been used for
months. In which case the cost of hardening an access of a queue only when
first touched that day would seem of very little machine cost. Compare that
to running a monitor product or script every hour to collect queues being
used and I think you'd find the Queue Manager version would be far more
efficient. As to how many customers this would benefit, well isn't that the
point of the new RFE system ? Why not put it up there and see how many
people vote for the values to be hardened.
I think the general idea of not doing something in the base product just
because it could be done in a 3rd party product is flawed. I appreciate I am
doing myself out of a job here since I write tools such as MO71 and MQSCX
precisely because there are deficiencies in the base product. However it is
all a matter of priorities, if enough people find a missing feature annoying
enough then surely it should be built in to the base product.
Cheers,
Paul.
Paul Clarke
www.mqgem.com
From: T.Rob
Sent: Wednesday, June 26, 2013 3:07 PM
Subject: Re: Housecleaning for MQ
Wow Paul, this is an oversimplification on a grand scale. I'm a bit
surprised.
Every queue has a control block associated with it in which the operational
status of the queue is stored. Much of WMQ is driven by the API calls made
by connected applications, including the update of that control block.
If the requested data were made to persist in the fashion you describe,
there would be a race condition during which the QMgr could go down without
having updated the value. This is no more reliable than could be achieved
with a simple shell script. Would anyone here consider the requirement met
if IBM were to provide a simple shell script to capture that data? Or is
the requirement specifically to be able to use MQSC and PCF to retrieve the
values and we don't necessarily care that they may not be accurate? The
notion of having an operational statistic and diagnostic value that is
"mostly reliable" would seem to me to be a rather significant change in
design philosophy.
Making the statistic not just persistent but *reliably* persistent would
require elimination of the race condition which adds to the code path of
*every* *API* *call* made within WMQ for the queues where that was enabled.
Making the public API code path longer and adding more points of failure is
also a rather significant change in design philosophy.
WMQ was built with significant instrumentation capabilities to allow things
like Tivoli to capture and record operational aspects. There's an element
of that which addresses the questions of "which features does EVERY customer
need to pay for?" and "which features and functions support a vibrant 3rd
party ecosystem that makes the product more viable and sustainable for all
customers?" Every diagnostic and statistic in the product are paid for by
all customers so the ones that are there either exist because the need to be
there and are merely exposed to the user, or those that are considered so
important that *every* customer should pay to support their maintenance in
the product. Since there are many ways of capturing this data with the
existing instrumentation, even a simple shell script could do it, moving it
to the category of "this is so critical that all customers must pay for it,
and customers with any sort of monitoring tool will just have to pay for it
twice" also seems to me to be a rather change in design philosophy.
The framework to set up cascading defaults from the queue manager down to
each queue to communicate the desired behavior to WMQ in a granular fashion
is about the only part of this request that might not be a big deal and I'm
not entirely sure about that.
-- T.Rob
Meekin, Paul
Sent: Wednesday, June 26, 2013 3:37 AM
Subject: Re: Housecleaning for MQ
Except IBM clearly do see the value in making these values available so I
don't think extending them to persist beyond QMgr starts is any real change
in design philosophy.
In terms of performance, presumably the data is currently kept in memory so
just add a thread to periodically check the values of each queue and update
the value on disk if it's changed.
Paul
Jefferson Lowrey
Sent: 25 June 2013 20:35
Subject: Re: Housecleaning for MQ
And, again, at some point these stats stop being something used for MQ
purposes, and start being used to replace good change management practices.
Particularly outside of a DEV environment, there should be a change
management record that backs up the creation of every queue and describes
it's role, and ties that creation to a specific team and responsible party,
and ideally to the relevant project or product.
Application level backout queues for production apps that are well
functioning and receiving data from well behaved systems could conceivable
go unaccessed for a long time. But that doesn't mean they aren't needed....
Thank you,
Jeff Lowrey
From: "Potkay, Peter M (CTO Architecture + Engineering)"
Date: 06/25/2013 01:27 PM
Subject: Re: [MQSERIES] Housecleaning for MQ
________________________________
They only need to be written to disk at QM shutdown. Yeah, I guess if there
is an abnormal termination of the QM you can't be sure these stats get
written to disk. So I suppose its performance related that these stats don't
persist. A busy QM with lots of queues would have a tremendous amount of
stats needing to be constantly written to disk.
Peter Potkay
________________________________
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
----------------------------------------- The information contained in this
communication (including any attachments hereto) is confidential and is
intended solely for the personal and confidential use of the individual or
entity to whom it is addressed. If the reader of this message is not the
intended recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this communication
in error and that any review, dissemination, copying, or unauthorized use of
this information, or the taking of any action in reliance on the contents of
this information is strictly prohibited. If you have received this
communication in error, please notify us immediately by e-mail, and delete
the original message. Thank you