Skip to main content

PCF commands - Middleware News

PCF commands


The purpose of WebSphere MQ programmable command format (PCF) commands is to allow administration tasks to be programmed into an administration program. In this way you can create queues, process definitions, channels, and namelists, and change queue managers, from a program.

PCF commands cover the same range of functions provided by MQSC commands. You can write a program to issue PCF commands to any queue manager in the network from a single node. In this way, you can both centralize and automate administration tasks.

Each PCF command is a data structure that is embedded in the application data part of a WebSphere MQ message. Each command is sent to the target queue manager using the MQI function MQPUT in the same way as any other message. The command server on the queue manager receiving the message interprets it as a command message and runs the command. To get the replies, the application issues an MQGET call and the reply data is returned in another data structure. The application can then process the reply and act accordingly.
Note: Unlike MQSC commands, PCF commands and their replies are not in a text format that you can read.

Briefly, these are some of the things needed to create a PCF command message:

Message descriptor
This is a standard WebSphere MQ message descriptor, in which:

* Message type (MsqType) is MQMT_REQUEST.
* Message format (Format) is MQFMT_ADMIN.

Application data
Contains the PCF message including the PCF header, in which:

* The PCF message type (Type) specifies MQCFT_COMMAND.
* The command identifier specifies the command, for example, Change Queue (MQCMD_CHANGE_Q).

For a complete description of the PCF data structures and how to implement them, see WebSphere MQ Programmable Command Formats and Administration Interface.

PCF object attributes

Object attributes in PCF are not limited to eight characters as they are for MQSC commands. They are shown in this book in italics. For example, the PCF equivalent of RQMNAME is RemoteQMgrName.

Escape PCFs

Escape PCFs are PCF commands that contain MQSC commands within the message text. You can use PCFs to send commands to a remote queue manager. For more information about using escape PCFs, see WebSphere MQ Programmable Command Formats and Administration Interface.

Using the MQAI to simplify the use of PCFs

The MQAI is an administration interface to WebSphere MQ that is available on the AIX(R), HP-UX, Linux, Solaris, and Windows platforms.

It performs administration tasks on a queue manager through the use of data bags. Data bags allow you to handle properties (or parameters) of objects in a way that is easier than using PCFs.

Use the MQAI:

To simplify the use of PCF messages
The MQAI is an easy way to administer WebSphere MQ; you do not have to write your own PCF messages, avoiding the problems associated with complex data structures.

To pass parameters in programs written using MQI calls, the PCF message must contain the command and details of the string or integer data. To do this, you need several statements in your program for every structure, and memory space must be allocated. This task can be long and laborious.

Programs written using the MQAI pass parameters into the appropriate data bag and you need only one statement for each structure. The use of MQAI data bags removes the need for you to handle arrays and allocate storage, and provides some degree of isolation from the details of the PCF.

To implement self-administering applications and administration tools
For example, the Active Directory Services Interfaces provided by WebSphere MQ for Windows use the MQAI.

To handle error conditions more easily
It is difficult to get return codes back from PCF commands, but the MQAI makes it easier for the program to handle error conditions.

After you have created and populated your data bag, you can send an administration command message to the command server of a queue manager, using the mqExecute call, which waits for any response messages. The mqExecute call handles the exchange with the command server and returns responses in a response bag.

For more information about using the MQAI, and PCFs in general, see WebSphere MQ Programmable Command Formats and Administration Interface.

Active Directory Services Interfaces

Active Directory Service Interfaces (ADSI) support allows client applications to use a common set of Component Object Model (COM) interfaces to communicate with, and control, any application that implements them.

Unlike tools written using other WebSphere MQ administration interfaces, those that use the ADSI are not limited to manipulating WebSphere MQ servers. The same tool can control Windows, Lotus(R) Notes(TM), or any application implementing the ADSI.

WebSphere MQ support for the ADSI is implemented through the use of the IBMMQSeries namespace.

Any programming language that supports the COM interfaces can be used to implement ADSI clients.



For more information about Component Object Model (COM) interfaces, see WebSphere MQ for Windows Using the Component Object Model Interface.

Client connection channels in the Active Directory

On Windows 2000, WebSphere MQ publishes client connection channels in the Active Directory to provide dynamic client-server binding.

When CLNTCONN channels are defined, they are written into a binary file called amqclchl.tab. If the client channels use the TCP/IP protocol, the WebSphere MQ server also publishes them in the Active Directory. When the WebSphere MQ client determines how to connect to the server, it looks for a relevant CLNTCONN definition using the following search order:

1. MQSERVER environment variable
2. amqclchl.tab file
3. Active Directory

This order means that any current applications are not affected by the change. You can think of these entries in the Active Directory as records in the amqclchl.tab file, and the WebSphere MQ client processes them in the same way.

Comments

adsrerrapop

Popular posts from this blog

Troubleshooting Java/JMS SSL Configurations - Middleware News

 This document is intended to help diagnose WebSphere MQ V7 Java™ or JMS SSL setup errors. It lists most of the common configuration errors that can cause an SSL connection from a Java/JMS client to a queue manager to fail, and gives the course of action to resolve the problem. In each case the error can be diagnosed by a combination of the error seen in the client log - either a console output, trace file or SystemOut.log file - and the queue manager's error logs. The document is quite long, so the easiest way to find the potential error is to search for one of the errors seen in this list, then filter this list using the error from the opposite end of the channel. All cases here assume that 2-way authentication is being attempted (SSLCAUTH set to REQUIRED on the queue manager's SVRCONN channel). This is the default, and the errors are very similar for 1-way authentication (SSLCAUTH set to OPTIONAL). Symptom Instructions on collecting documentation...

IBM Websphere MQ interview Questions Part 5

MQ Series: - It is an IBM web sphere product which is evolved in 1990’s. MQ series does transportation from one point to other. It is an EAI tool (Middle ware) VERSIONS:-5.0, 5.1, 5.3, 6.0, 7.0(new version). The currently using version is 6.2 Note: – MQ series supports more than 35+ operating systems. It is platform Independent. For every OS we have different MQ series software’s. But the functionality of MQ series Default path for installing MQ series is:- C: programfiles\BM\clipse\SDK30 C: programfiles\IBM\WebsphereMQ After installation it will create a group and user. Some middleware technologies are Tibco, SAP XI. MQ series deals with two things, they are OBJECTS, SERVICES. In OBJECTS we have • QUEUES • CHANNELS • PROCESS • AUTHENTICATION • QUERY MANAGER. In SERVICES we have LISTENERS. Objects: – objects are used to handle the transactions with the help of services. QUEUE MANAGER maintains all the objects and services. QUEUE: – it is a database structure ...

Using telnet to test connectivity between IBM Websphere MQ Client and MQ server - Middleware News

You are having trouble connecting a WebSphere MQ client to a MQ server, receiving errors that you can not connect to the MQ queue manager. One of the first things to determine is if the two machines can communicate, and using the telnet tool is one way to accomplish it. Symptom Receiving errors which state that a queue manager is not found or not available. Connection errors. For example: AMQ9213, AMQ9524, AMQ9202 or AMQ9508 or MQRC =2059 0x0000080b MQRC_Q_MGR_NOT_AVAILABLE. Please note, this is by no means an exclusive list of errors related to this type a problem but just a sample of some of the more common error messages and codes that might occur. Cause One possible cause is that the two machines can not communicate. May be the IP address or hostname was not properly specified by the MQ client. The port number might be incorrect. A queue manager is not running at the desired host. The queue manager could be running, but the corresponding listener is not runnin...