MQ Standard Security Exit is a solution that allows a company to control and restrict who is accessing a WebSphere MQ resource. The security exit will operate with WebSphere MQ v6.0, v7.0, v7.1, or v7.5 in Windows, IBM i (OS/400), Unix, and Linux environments. It works with Server Connection, Receiver, Requestor, and Cluster-Receiver channels of WebSphere MQ queue manager. The MQ Standard Security Exit solution is comprised of a server-side security exit.
MQ Channel Encryption (MQCE) is a solution that provides AES encryption for message data flowing between WebSphere MQ (WMQ) resources. It operates with Sender, Receiver, Server, Requestor, Cluster-Sender, Cluster-Receiver, Server Connection, and Client Connection channels of the WMQ queue managers. It is a simple drop-in solution and can be configured as a queue manager channel message exit or as a channel sender/receive exit pair.
MQ Message Encryption (MQME) is a solution that provides encryption for WebSphere MQ message data while it resides in a queue and in the MQ logs. It uses AES and offers the ability to control who accesses protected queues. This control is obtained through the use of UserID grouping, and group files are similar to the Unix /etc/group file. It also has the ability to generate and validate messages using a SHA-2 digital signature.
MQ Auditor is a solution that allows a company to audit and track all MQ API calls performed by MQ applications that are connected to a queue manager. The API Exit operates with WebSphere MQ v7.0, v7.1, or v7.5 in Windows, Unix, IBM i, and Linux environments. Under WMQ v5.3 and higher, MQA audits the following MQ API calls: MQCONN, MQCONNX, MQOPEN, MQGET, MQPUT, MQPUT1, MQINQ, MQSET, MQCLOSE, MQDISC, MQBACK, MQBEGIN, and MQCMIT. Under WMQ v220.127.116.11 and higher, MQA audits the above calls as well as the following calls: XASTART, XAEND, XAOPEN, XACLOSE, XACOMMIT, XACOMPLETE XAFORGET, XAPREPARE, XARECOVER, XAROLLBACK, AX_REG, and AX_UNREG. Under WMQ v7.0 and higher, MQA also audits the following additional MQ API calls: MQCALLBACK, MQCB, MQCTL, MQSTAT, MQSUB, and MQSUBRQ.
Universal File Mover (UFM) manages the transfer of files. The user combines a series of Action commands to create the UFM Workflow XML file. These Action commands define which actions are to be taken, the order of the actions, and how errors are to be handled. UFM processes the Action commands as per the UFM Workflow XML file. UFM currently contains 41 Action commands. These action commands fall into five categories: WebSphere MQ Actions, Network Actions, File Actions, Control Actions, and Other Actions. UFM can transfer files in one of five ways, using WebSphere MQ, FTP, SFTP, SCP, or HTTP.
The Message Multiplexer (MMX) application will get a message from a WebSphere MQ queue and output it to one or more queues. Context information is maintained across the message put(s). MMX can move messages from a single source queue to (up to) 99 target queues. Messages put to each target queue are an exact replicate of the original message from the source queue (including the message's MQMD). MMX performs each MQGET and the subsequent "n" MQPUT(s) under a Unit of Work (UOW), so that message integrity is kept.
The Message Router (MRTR) application will move a message from a central WebSphere MQ queue to a specific application WebSphere MQ queue. The destination queue that the message will be placed into will be based on a keyword in the message. Context information is maintained. MRTR will look in the message for a Start Keyword and an End Keyword. The value between these two keywords is the Keyword Value (inifile Token). MRTR will search its ini file for that particular Keyword Value. The field value associated with the looked-up keyword value is the destination queue name. MRTR performs each MQGET and the subsequent MQPUT under a Unit of Work (UOW) so that message integrity is kept.
PyMQI is a Python library for working with WebSphere MQ (formerly known as MQSeries) implementing MQI and PCF protocols. It allows one to connect to queues, put, browse, get messages, and to programmatically administer MQ objects. PyMQI has been used in production environments for several years and is known to work on Linux, Windows, Solaris, AIX, and HP-UX with queue managers running on Linux, Windows, Solarix, AIX, HP-UX, and z/OS mainframe.
The MQ Channel Monitor application is a software package designed to gather and to display the status of MQ channels of the queue manager. It displays 16 columns of channel status information. The display is automatically refreshed every 60 seconds (default value). The user can alter this refresh rate. By default, all of the channels of the queue manager that currently have a status will be displayed. The user can define filters so that only particular channels will have their status displayed. MQCM can connect to a queue manager in 3 possible ways: locally in binding mode; remotely using a Client Channel Definition Table (CCDT); and remotely using an MQ XML file. MQCM supports both forms of MQ security: SSL for connecting to remote queue managers, and 3rd party security exit for connecting to remote queue managers.
MQWhat is a tool for documenting which MQ components are installed and active on a particular server. Since MQ component information is contained in various files and/or output by MQ programs, MQWhat is designed to collect and summarize the MQ information and present the information to the user's screen in a concise manner.