IBM Websphere MQ mqclient.ini - One place for all your client configuration - Middleware News

For the last few releases, there has been the concept of a ini file for the client, just like qm.ini, but called mqclient.ini. It's purpose is to provide a single file which includes all the configuration for the client and for this reason it includes various items that were previously configured by means of environment variables. The table below summaries these items.

The mqclient.ini file allows you to gather together all your client configuration into one file, easier to deploy, keep a backup of, and replace when changes are required, rather than a random selection of environment variables. A great idea.

nvironment Variable	mqclient.ini stanza	mqclient.ini value	Description
MQCCSID	CHANNELS	CCSID	The coded character set number to be used
MQCHLLIB	CHANNELS	ChannelDefinitionDirectory	The directory path to the file containing the CCDT
MQCHLTAB	CHANNELS	ChannelDefinitionFile	The name of the file containing the CCDT
MQSERVER	CHANNELS	ServerConnectionParms	The location of the MQ server and the communication method to be used
MQCERTLABL	SSL	CertificateLabel	Defines the certificate label
MQCERTVPOL	SSL	CertificateValPolicy	Determines the type of certificate validation used
MQSSLCRYP	SSL	SSLCryptoHardware	The parameter string required to configure PKCS #11 cryptographic hardware
MQSSLFIPS	SSL	SSLFipsRequired	Whether only FIPS-certified algorithms are to be used
MQSSLKEYR	SSL	SSLKeyRepository	The location of the key repository that holds the user's digital certificate
MQSSLPROXY	SSL	SSLHTTPProxyName	The HTTP Proxy server that is to be used by GSKit for OCSP checks
MQSSLRESET	SSL	SSLKeyResetCount	The number of unencrypted bytes sent and received before the secret key is renegotiated
MQSUITEB	SSL	EncryptionPolicySuiteB	Whether Suite B compliant cryptography is to be used
MQIPADDRV	TCP	IPAddressVersion	Specifies which IP protocol to use for a channel connection
MQTCPTIMEOUT	TCP	Connect_Timeout	How long MQ waits for a TCP connect call
MQNAME	NETBIOS	LocalName	The name by which this computer is known on the LAN

Configuring a client using a configuration file Configure your clients using attributes in a text file. These attributes can be overridden by environment variables or in other platform-specific ways. You configure your WebSphere® MQ MQI clients using a text file, similar to the queue manager configuration file, qm.ini, used on UNIX and Linux platforms. The file contains a number of stanzas, each of which contains a number of lines of the format attribute-name=value . In this documentation, this file is referred to as the WebSphere MQ MQI client configuration file; its file name is generally mqclient.ini, but you can choose to give it another name. Configuration information in this file applies to all platforms, and to clients using the MQI, WebSphere MQ classes for Java™, WebSphere MQ classes for JMS, WebSphere MQ classes for .NET, and XMS. The configuration features apply to all connections a client application makes to any queue managers, rather than being specific to an individual connection to a queue manager. Attributes relating to a connection to an individual queue manager can be configured programmatically, for example by using an MQCD structure, or by using a Client Channel Definition Table (CCDT). Environment variables which were supported in releases of WebSphere MQ earlier than Version 7.0 continue to be supported, and where such an environment variable matches an equivalent value in the client configuration file, the environment variable overrides the client configuration file value. For a client application using WebSphere MQ classes for JMS, you can also override the client configuration file in the following ways: setting properties in the JMS configuration file setting Java system properties, which also overrides the JMS configuration file For the .NET client, you can also override the client configuration file and the equivalent environment variables using the .NET application configuration file. Note that you cannot set up multiple channel connections using the client configuration file. Example client configuration file #* Module Name: mqclient.ini *# #* Type : WebSphere MQ MQI client configuration file *# # Function : Define the configuration of a client *# #* *# #*******************************************************************# #* Notes : *# #* 1) This file defines the configuration of a client *# #* *# #*******************************************************************# ClientExitPath: ExitsDefaultPath=/var/mqm/exits ExitsDefaultPath64=/var/mqm/exits64 TCP: Library1=DLLName1 KeepAlive = Yes ClntSndBuffSize=32768 ClntRcvBuffSize=32768 Connect_Timeout=0 MessageBuffer: MaximumSize=-1 Updatepercentage=-1 PurgeTime=0 LU62: TPName Library1=DLLName1 Library2=DLLName2 PreConnect: Module=amqldapi Function=myFunc Data=ldap://myLDAPServer.com:389/cn=wmq,ou=ibm,ou=com Sequence=1 CHANNELS: DefRecon=YES ServerConnectionParms=SALES.SVRCONN/TCP/hostname.x.com(1414)

MQCSP Password Protection in IBM Websphere MQ V8 - Middleware News

The MQCSP structure enables the authorization service to authenticate a user ID and password from the client. We can specify the MQCSP connection security parameters structure on an MQCONNX call. Prior to Websphere MQ version 8 the passwords from client to the queue manager were sent across the network in plain text if SSL/TLS encryption is not used which is insecure. MQ version 8 provides options to send passwords that are included in the MQCSP structure protected by using websphere MQ functionality or by using SSL/TLS encryption.

This password protection mechanism is applicable to MQ version 8 queue managers, MQI C clients, java & JMS clients and .NET clients. Password protection is used when all of the following conditions are met:
-Both ends of the connection are using WebSphere MQ version 8.0.
-The channel is not using SSL/TLS encryption.
-If the client is WebSphere MQ Explorer and user identification compatibility mode is not enabled, which is not the default. This condition is applicable only to WebSphere MQ Explorer.
-If the client is a Java or JMS application and the useM

QCSPauthentication configuration setting is set to true, which is not the default. This condition is applicable only to Java and JMS client applications.

MQ version 8 provides supports 2 password protection algorithms
-"null" algorithm which sends password as plain text which is seen in all MQ versions
-"real" password protection algorithm which uses Triple DES(3DES) based encryption.
By default, passwords will automatically be protected whenever both ends of the client/server connection are running MQ 8.0 or higher. MQ version 8 provides control over configuration settings via "PasswordProtection" attribute. The value of the PasswordProtection attribute in the Channels section of client and queue manager .ini configuration files can take one of three values:
COMPATIBLE
 This is the default value. When communicating with MQ 8.0 we must be negotiating a real password protection algorithm. When using MQ 7.5 or lower versions, null password protection algorithm can be used for interoperability purpose.
ALWAYS
 When communicating with MQ 8.0 we must be negotiating a real password protection algorithm. With this method we cannot communicate with MQ 7.5 or lower versions.
OPTIONAL
 Any mutually-supported password protection algorithm is allowed.

Following link provides possible forms of connection for each attribute of PasswordProtection
 http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q118710_.htm?lang=en

Password protection mechanism doesn't provide wide variety of encryption algorithms as in SSL/TLS encryption. With SSL/TLS encryption being used, the user has option of choosing the encryption type. SSL encryption is still the preferred method over WebSphere MQ password protection, especially when the network between the client and queue manager is untrusted, as SSL/TLS encryption is more secure. Password protection mechanism is suitable for the customers who don't use SSL as this overheads with certificate management.

Connection authentication using MQCSP requires changes to be done on both client and the server. Application changes with connection authentication
MQI : For an application using MQI to connect to queue manger, MQCONNX call and MQCSP structure should be used. Sample C fragment code for connection authentication
                char *QMName = "queue_manager";
                char *Userid = "user_id";
                char *Password = "password";
                MQCNO cno = {MQCNO_DEFAULT};
                MQCSP csp = {MQCSP_DEFAULT};
                cno.SecurityParmsPtr = &csp;
                cno.Version = MQCNO_VERSION_5;
                csp.AuthenticationType = MQCSP_AUTH_USER_ID_AND_PWD;
                csp.CSPuser IDPtr = Userid;
                csp.CSPuser IDLength = strlen(Userid);
                csp.CSPPasswordPtr = Password;
                csp.CSPPasswordLength = strlen(csp.CSPPasswordPtr);
                MQCONNX(QMName, &cno, &Hcon, &CompCode, &CReason);
              
Object-oriented languages: such as the Java classes, properties are set before connecting to the queue manager. Java code fragment for connection authentication
                String QMName = "queue_manager";
                String Userid = "user_id";
                String Password = "password";
                Hashtable h = new Hashtable();
                h.put(MQConstants.USER_ID_PROPERTY, Userid);
                h.put(MQConstants.PASSWORD_PROPERTY, Password);
                h.put(MQConstants.USE_MQCSP_AUTHENTICATION_PROPERTY, true);
                MQQueueManager qMgr = new MQQueueManager(QMName,h)
              
or the MQEnvironment property class can also be used
                String QMName = "queue_manager";
                String Userid = "user_id";
                String Password = "password";
                MQEnvironment.properties = new Hashtable();
                MQEnvironment.userID = Userid;
                MQEnvironment.password =Password;
                MQQueueManager qMgr = new MQQueueManager(QMName);
              
JMS & XMS: Connection methods take user id and password parameters
                connectionFactory.createConnection(Userid,Password)

Information on configuring the server queue manager to check authenticity of the supplied user id and password provided by client application can be seen here
 http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q113250_.htm?lang=en
With above changes on both client and the server, the password will be sent protected if both ends of connection are using MQ version 8.

IBM Websphere MQ - AD020000 AMQ6119 rc=27 File too large, when sending data to and starting the queue manager - Middleware News

You have WebSphere MQ v5.3 CSD04 or MQ 6 or MQ 7.0 installed on AIX with 6 queue managers created. Two queue managers are sending queue managers and the remaining 4 are receiving queue managers. When the sender send data to the receiving queue manager, that queue manager reject the data and produce the following error and the FDC listed below.

AMQ6119 with rc=27 meaning EFBIG "File too big" on both Sending and Receiving queue managers.

Cause

Probe AD020000 is caused by an attempt to increase the queue file size beyond the Operating System limit (ulimit).

Resolving the problem

Increase the /etc/security/limits to go beyond 1GB.
Three things have to occur to over come the 1 GB limit:

1. Enable large file support.
2. Increase the ulimit values to match the MQ limit or to unlimited.
3. Create the queue after you have enabled large file support.

As stated from the System Administration Guide - "Enabling large queues WebSphere MQ Version 5.3 supports queues larger than 2 GB. On AIX, HP-UX, Linux, and Solaris systems, you need to explicitly enable large file support before you can create queue files larger than 2 GB. See your operating system documentation for information on how to do this."

Additional information The FDC file produced numerous errors:
Probe Id :- AD020000
Component :- adiSetFSize
CMVC level :- p530-05-L030926
Program Name :- amqzlaa0_nd
Major Errorcode :- xecF_E_UNEXPECTED_SYSTEM_RC
Minor Errorcode :- OK
Probe Type :- MSGAMQ6119
Probe Severity :- 2
Probe Description :- AMQ6119: An internal WebSphere MQ error has occurred (Rc=27 from ftruncate)
FDCSequenceNumber :- 1626
Comment1 :- Rc=27 from ftruncate
Comment2 :- File too large
------------------------------------------------------------------
MQM Function Stack
zlaMainThread
zlaProcessMessage
zlaProcessMQIRequest
zlaMQPUT
zsqMQPUT
kpiMQPUT
kqiPutIt
kqiPutMsgSegments
apiPutMessage
aqmPutMessage
aqhPutMessage
aqqWriteMsg
aqqWriteMsgData
aqpWriteDataBuffers
adhResize
adiSetFSize
xcsFFST

IBM Websphere MQ History

Developed in Scotland, Telecommunications Access Method (TCAM) came along in 1971 with the birth of TSO. It supported asynchronous messaging, as with MQ. TCAM 3.0 added in reusable disk message queues for recovery soon thereafter, as with MQ. A high-level PL/I program could be used to access TRANSIENT datasets (dynamic message queues). Reading a message from a transient dataset resulted in that message is removed from the queue, as with a non-browse READ with MQ. With the advent of computers, IBM saw an opportunity to apply new technology to the need for message switching. In the early 1960s, IBM marketed computer-like devices, such as the 7740 and 7750 message switching systems.

The IBM System/360 was announced in April 1964 and with it came communication access methods such as BTAM and QTAM (Basic and Queued Telecommunications Access Methods). In the late 1960s, still another communication access method became available and it was known as TCAM, the Telecommunications Access Method. TCAM offered its users a more advanced form of message switching or message routing. TCAM was widely accepted, especially in the financial and brokerage industries.

In the late 1960s, transaction management systems came into being, each trying to achieve a leadership position in the industry. Within IBM, CICS and IMS were chosen as strategic products to address the need for transaction management. Within both CICS and IMS, each had its version of message switching, IMS being a front-end queued system and CICS having its Transient Data facility as the possible basis for message switching.

CICS established itself as a popular transaction management system in the 1968-1971 timeframe, those users who had adopted TCAM for its message handling capabilities, now wanted a combined use of TCAM with CICS. In December 1971, IBM announced CICS support of TCAM as part of the CICS/OS-Standard product, to be delivered in December 1972. For interested customers, this enabled them to use TCAM for its message handling strengths and also have TCAM-connected terminals or computers interface with CICS online applications.

In January 1973, TCAM continued to be supported by CICS/OS-Standard Version 2.3. However, TCAM support was omitted from the initial release of CICS/VS, announced in February 1973 and delivered in June 1974. Needless to say, many CICS-TCAM customers were not happy with that product direction.

With considerable pressure from CICS-TCAM customers, the CICS support of TCAM was reinstated in the CICS/VS 1.1 product, as of September 1974. In addition to the previous DCB support, with this reinstatement of TCAM support, CICS began to support TCAM access via VTAM, also known as the ACB support. CICS TCAM ACB support was discontinued as of the CICS/ESA Version 3 product in 1990.

In 1992, IBM announced a new product family called WebSphere MQ. WebSphere MQ was to be the extension of TCAM functionality from IBM-only systems to all other platforms. WebSphere MQ had an architecture which enabled heterogeneous systems to communicate with each other (e.g. IBM, HP, Sun, Tandem, etc). WebSphere MQ can be used with CICS systems to send and receive data to/from any other MQ-eligible system. WebSphere MQ can be used to initiate work in a CICS system or a CICS transaction can initiate work in another CICS or non-CICS system.

WebSphere MQ now supports 80 different environments and has become the leading message switching/routing product in the industry.

IBM Websphere MQ Features

WebSphere MQ provides assured one-time delivery of messages across a wide variety of platforms. The product emphasizes reliability and robustness of message traffic, and ensures that a message should never be lost if MQ is appropriately configured.

It needs to be remembered that a message in the context of MQ has no implication other than a gathering of data. MQ is very generalized and can be used as a robust substitute for many forms of intercommunication. For example, it can be used to implement reliable delivery of large files as a substitute for FTP.

MQ provides application designers a mechanism to achieve non-time-dependent architecture. Messages can be sent from one application to another, regardless of whether the applications are running at the same time. If a message receiver application is not running when a sender sends it a message, the queue manager will hold the message until the receiver asks for it. Ordering of all messages is preserved, by default this is in FIFO Order of receipt at the local queue within priority of the message.

It provides a means for transforming data between different architectures and protocols, such as Big Endian to Little Endian, or EBCDIC to ASCII. This is accomplished through the use of message data "exits". Exits are compiled applications which run on the queue manager host, and are executed by the WebSphere MQ software at the time data transformation is needed.

WebSphere MQ allows receipt of messages to "trigger" other applications to run, and thus provides the framework for a message driven architecture.

It implements the JMS standard API, and also has its own proprietary API, known as the Message Queuing Interface.

Unlike email, MQ itself is responsible for determining the destination of messages by the definition of queues, so processing of sent messages can be moved to a different application at a different destination. MQ provides a robust routing architecture, allowing messages to be routed via alternative paths around a network of MQ managers. MQ can be implemented as a cluster, where multiple MQ implementations share the processing of messages to allow higher performance and load balancing.

Oracle Fusion Middleware Components

Oracle Fusion Middleware Components

Enterprise Application Server Weblogic Server Oracle Application Server Integration & Process Management BPEL Process Manager Business Activity Monitoring Business Rules Enterprise Connectivity (Adapters) Enterprise Messaging Service Enterprise Service Bus Oracle Application server B2B Service Registry Web Services Manager Development Tools Application Development Framework JDeveloper SOA Suite TopLink Forms Services Developer Suite Business Intelligence Business Intelligence 10g[7] Business Activity Monitoring Discoverer Data Hubs BI Publisher Reports Services Systems Management Enterprise Manager 10g Web Services Manager User Interaction Beehive Collaboration Suite Portal Oracle Webcenter Real-Time Collaboration Unified Messaging Workspaces Content Management Web content management Records management Enterprise search Digital asset management Email archiving Identity management Identity Management Enterprise Single sign-on Identity Manager Oracle Access Manager Oracle Adaptive Access Manager Grid Infrastructure Services Registry Application Server Security

IBM Websphere MQ Processes

IBM Websphere MQ Processes

Processes AMQMTRBN . amqhasmn.exe - the logger. amqmsrvn.exe - COM server. amqmtbrn.exe - . amqpcsea.exe - the command server. amqrmppa.exe - channel process. amqrrmfa.exe - repository process (for clusters). amqsvc.exe - . amqxssvn.exe - shared memory server(s). amqzdmaa.exe - deferred message processor.amqzfuma.exe - OAM process. amqzlaa0.exe - queue manager agents (LQM agents). amqzllp0.exe - checkpoint processor. amqzxma0.exe - processing controller. runmqchi.exe - channel initiator. runmqlsr.exe - listener.


Description of MQ tasks :When a queue manager is running, you see some or all of the following batch jobs running under the QMQM user profile in the MQ subsystem.Job name Function AMQALMPX The checkpoint processor that periodically takes journal checkpoints. AMQCLMAA Non-threaded TCP/IP listener. AMQCRSTA TCP/IP-invoked channel responder. AMQCRS6B LU62 receiver channel and client connection (see note). AMQFCXBA Broker worker job. AMQPCSEA PCF command processor. Handles PCF and remote administration requests. AMQRMPPA Channel process pooling job. AMQRRMFA Repository manager for clusters. AMQZDMAA Deferred message handler. AMQZFUMA Object authority manager (OAM). AMQZLAA0 Queue manager agents that perform the bulk of the work for applications that connect to the queue manager using MQCNO_STANDARD_BINDING. AMQZLAS0 Queue manager agent. AMQZXMA0 The execution controller is the first job started by the queue manager. Deals with MQCONN requests. Starts agent processes to process MQ API calls. AMQZMGR0 Process controller. Used to start up and manage listeners and services. AMQZMUC0 Utility manager. Do critical utilities, as the journal chain manager. AMQZMUR0 Utility manager. Do critical utilities, as the journal chain manager. RUNMQBRK Broker control job. RUNMQCHI The channel initiator. RUNMQCHL Sender channel job that is started for each sender channel. RUNMQDLQ Dead letter queue handler. RUNMQLSR Threaded TCP/IP listener. RUNMQTRM Trigger monitor.End the processes in the following order:amqzmuc0 Critical process manager amqzxma0 Execution controller amqzfuma OAM process amqzlaa0 LQM agents amqzlsa0 LQM agents amqzmur0 Restartable process manager amqrmppa Process pooling process amqrrmfa The repository process (for clusters) amqzdmaa Deferred message processor amqpcsea The command server
Posted by Block for Websphere MQ at 4:08 AM 0 comments
Labels: IBM Websphere MQ

What is Channel?
A channel is a communication link used by distributed queue managers. There are two categories of channel in MQ: Message channels, which are unidirectional, and transfer messages from one queue manager to another. MQI channels, which are bidirectional, and transfer MQI calls from a MQ client to a queue manager, and responses from a queue manager to a MQ client. There are two types of MQI channel : server-connection and client-connection. MQ 6.0, "Application Programming Guide", SC34-6595-01, page 45 [65/601] The definition of each end of a message channel can be one of the following types: Sender Receiver Server Requester Cluster sender Cluster receiver Do not confuse message channels with MQI channels. There are two types of MQI channel : server-connection and client-connection. A message channel is defined using one of these types defined at one end, and a compatible type at the other end. Possible combinations are: Sender - Receiver Requester - Server Requester - Sender (callback) Server - Receiver (server is used as a sender) Client-connection with Server-connection Cluster sender-cluster receiver MQ v 6.0, "Intercommunication", SC34-6587, page 8 [30/573]. Server / Requester use Supose we have this environment, where firewall prevents QM2 to start a normal Sender-Receiver channel from QM2.TO.QM1, but not TCP connections from QM1 to QM2. .-----. .---. .-----. QM1 <===== F <======= QM2 .-----. .---. .-----. We shall use a SERVER channel at QM2 and a REQUESTER channel at QM1. In this way, the data can flow from QM2 to QM1, and the channel is started from QM1. SVRCONN A server connection channel object defines the name of a channel that a client can use to connect to a queue manager and the attributes of the MCA that hosts that connection. CLNTCONN This is different to all other channel types, because it is never used by the queue manager itself. Instead, an entry is added to a client channel definition table (CCDT) file, which can be distributed to other machines and used by client applications to configure their MCAs. How to start A channel can be caused to start transmitting messages in one of four ways. It can be: Started by an operator (not receiver, cluster-receiver or server-connection channels). Triggered from the transmission queue (sender, and fully-qualified server channels only). You will need to prepare the necessary objects for triggering channels. Started from an application program (not receiver, cluster-receiver or server-connection channels). Started remotely from the network by a sender, cluster-sender, requester, server, or client-connection channel. Receiver, cluster-receiver and possibly server and requester channel transmissions, are started this way; so are server-connection channels. The channels themselves must already be started (that is, enabled). In Windows systems, start a listener as a background process at the receiver end of each channel. On the source queue manager, type: runmqlsr -t TCP -m source.queue.manager On the target queue manager, type: runmqlsr -t TCP -m target.queue.manager Then start the channels, again as background processes: On the source queue manager, type: runmqchl -c source.to.target -m source.queue.manager On the target queue manager, type: runmqchl -c target.to.source -m target.queue.manager System Administration, page 63 [87 of 567] Auto-Magic If you want the first message put in the queue DESA4 to start the associated transmit channel DESA3.DESA4, then define the queue this way : def ql(DESA4) usage(xmitq) maxmsgl(104857600) + trigger TRIGTYPE(EVERY) TRIGDPTH(1) + trigdata(DESA3.DESA4) + /* channel name */ initq(SYSTEM.CHANNEL.INITQ) replace /* mandatory */ The TrigData attribute must contain the name of the channel to be triggered. The InitQ must be SYSTEM.CHANNEL.INITQ