Potkay, Peter M (CTO Architecture + Engineering)
2013-12-06 13:59:31 UTC
Please vote for this one if you think it's a good idea.
Here is the direct link to cast your vote:
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=42528
Description:
A queue manager gets many of its characteristics from the qm.ini file. Environment variables set for the mqm ID also dictate how the Queue Manager behaves. Currently there is no way for an MQ Admin to know what all these values are with an MQ Client based tool. The MQ Admin is forced to log onto the server, or rely on a local agent to be installed on the MQ server that they then interact with.
This Request For Enhancement is to have the Queue Manager allow suitably authorized MQ Client based applications to read these attributes. A running Queue Manager knows what all the characteristics are for its logging details (type, size, number, buffer, etc). Could the Queue Manager dump all these attributes that are not available via runmqsc into a new queue (maybe SYSTEM.QM.INI.VALUES) upon start up and allow only suitably authorized apps to read the message(s) on this queue? If the messages are persistent and small, maybe keep old ones on the queue and just add a new one each time the QM restarts, to provide an Audit trail or History of what parameters this Queue manager ran with.
If the Queue Manager is aware of what environment variables are set, it would be helpful to have those values captured as well. For example, is MQS_REPORT_NOAUTH set to TRUE.
Use case:
An MQ Admin using MQ Explorer, MO71 or some other tool (if those tools were enhanced to take advantage of this) could then remotely see the values of all the qm.ini related parameters the QM is running with. MQ Client based applications that already allow an MQ Admin to compare multiple QMs based off of PCF commands/responses would be able to fully compare 2 or more queue managers without the MQ Admin having to log onto each server to complete the job.
Business justification:
Easier and more complete auditing of the MQ environment to gauge consistency and adherence to standards for your shop
Peter Potkay
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
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
Here is the direct link to cast your vote:
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=42528
Description:
A queue manager gets many of its characteristics from the qm.ini file. Environment variables set for the mqm ID also dictate how the Queue Manager behaves. Currently there is no way for an MQ Admin to know what all these values are with an MQ Client based tool. The MQ Admin is forced to log onto the server, or rely on a local agent to be installed on the MQ server that they then interact with.
This Request For Enhancement is to have the Queue Manager allow suitably authorized MQ Client based applications to read these attributes. A running Queue Manager knows what all the characteristics are for its logging details (type, size, number, buffer, etc). Could the Queue Manager dump all these attributes that are not available via runmqsc into a new queue (maybe SYSTEM.QM.INI.VALUES) upon start up and allow only suitably authorized apps to read the message(s) on this queue? If the messages are persistent and small, maybe keep old ones on the queue and just add a new one each time the QM restarts, to provide an Audit trail or History of what parameters this Queue manager ran with.
If the Queue Manager is aware of what environment variables are set, it would be helpful to have those values captured as well. For example, is MQS_REPORT_NOAUTH set to TRUE.
Use case:
An MQ Admin using MQ Explorer, MO71 or some other tool (if those tools were enhanced to take advantage of this) could then remotely see the values of all the qm.ini related parameters the QM is running with. MQ Client based applications that already allow an MQ Admin to compare multiple QMs based off of PCF commands/responses would be able to fully compare 2 or more queue managers without the MQ Admin having to log onto each server to complete the job.
Business justification:
Easier and more complete auditing of the MQ environment to gauge consistency and adherence to standards for your shop
Peter Potkay
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
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