Middleware News

Introduction to Web Services - Middleware News

2012-01-26T07:49:00.000-08:00

Introduction to Web Services - Middleware News

What is "CHANGE MANAGEMENT"? - Middleware News

2012-01-26T07:08:00.000-08:00

What is "CHANGE MANAGEMENT"? - Middleware News

Using WebSphere MQ Explorer as a read-only viewer - Middleware News

2012-01-18T07:39:00.000-08:00

Using WebSphere MQ Explorer as a read-only viewer - Middleware News

The WebSphere MQ Explorer GUI provides a user-friendly way to administer your queue managers.

With a little work, you can use it as a read-only ‘viewer’ instead. If you have some staff who don’t have authority to make changes to the WMQ network, but need them to be able to monitor what is happening, this would let them use WMQ Explorer to do it. If your staff without authority to make changes are the ones with less WebSphere MQ experience, then this might be a useful approach.

In this post I’ll walk through the steps required to set this up for a single queue manager, and highlight a couple of potential problems to watch out for.

Steps to carry out on the machine hosting the queue manager

Create a user – making sure that the user is not a member of the mqm group
Start a channel listener for the queue manager
Create a server-connection (SVRCONN) channel on the queue manager – setting the MCAUSER attribute to the username defined in step 1
Use setmqaut to specify which objects you want the user to be able to see

What permissions do you need to grant?

Firstly, you need permission to connect to the queue manager:

setmqaut -m YOUR_QUEUE_MANAGER -t qmgr -p YOUR_USER_NAME +connect +inq +dsp

Next, you need to give permission to the queues that WMQ Explorer will need:

setmqaut -m YOUR_QUEUE_MANAGER -t q -n SYSTEM.DEFAULT.MODEL.QUEUE -p YOUR_USER_NAME +get +browse +inq
setmqaut -m YOUR_QUEUE_MANAGER -t q -n SYSTEM.ADMIN.COMMAND.QUEUE -p YOUR_USER_NAME +get +browse +inq +put
setmqaut -m YOUR_QUEUE_MANAGER -t q -n SYSTEM.MQEXPLORER.REPLY.MODEL -p YOUR_USER_NAME +inq +browse +get +dsp

setmqaut -m YOUR_QUEUE_MANAGER -t q -n 'AMQ.**' -p YOUR_USER_NAME +all
setmqaut -m YOUR_QUEUE_MANAGER -t q -n 'MQAI.**' -p YOUR_USER_NAME +all

Then, you could give access to all objects of a certain type – such as being able to display all channels:

setmqaut -m YOUR_QUEUE_MANAGER -t channel -n '**' -p YOUR_USER_NAME +dsp

You might want to include additional permissions, such as the ability to browse messages on queues, or inquire their attributes:

setmqaut -m YOUR_QUEUE_MANAGER -t q -n '**' -p YOUR_USER_NAME +dsp +inq +browse

See the System Administration Guide section on setmqaut for more detail on the options available.

Steps to carry out on the WebSphere MQ Explorer machine

Right-click on ‘Queue Managers’ and choose ‘Show Queue Manager’
Click on the ‘Add’ button
Enter the queue manager name and click ‘Next’
Fill in the hostname of the machine hosting the queue manager, the TCP port number for the channel listener you started, and the name of the server-connection channel you created
Click Finish

WebSphere MQ problems and workarounds - Middleware News

2012-01-18T07:26:00.001-08:00

WebSphere MQ problems and workarounds - Middleware News

You might encounter these WebSphere MQ problems, and use these workarounds:

Problem: JMS message send errors occur with WebSphere global security enabled on AIX.

An issue has been identified with the Java Virtual Machine (JVM) bundled with WebSphere Application Server Version 5.1.1 for AIX systems that causes socket errors on the network connection used to secure access to embedded messaging queues. This can cause JMS message sends to fail with an error similar to the following error in the WebSphere logs:

MQJMS2008: failed to open MQ queue WQ_itim_wf

The following error will also be present in the WebSphere jmsserver logs:

MSGS0504E: An JMS Server security service thread experienced a socket exception:
java.net.SocketException: Socket closed

Workaround: It is recommended that all Tivoli Identity Manager applications running on AIX systems should install WebSphere APAR PK07924, which corrects the issue in the JVM. Apply this APAR after installing Fix Pack 1 for WebSphere Application Server Version 5.1, which also updates the WebSphere Application Server JVM. APAR PK07924 is available on the WebSphere Application Server support site:

http://www.ibm.com/software/webservers/appserv/was/support/
Problem: On a Windows system, during DSML feed activity with Tivoli Identity Manager account provisioning enabled, the WebSphere embedded messaging fails. Error messages describe failure to open a queue, a lack of permission to access a resource, or Java Message Service errors. You might see a WebSphere embedded messaging error similar to this message:

AMQ9181 The response set by the exit is not valid.

Workaround: On all cluster members, set the ephemeral port range to the maximum value of 65534. For more information on problems connecting to TCP/IP ports above 5000, refer to the following Web site:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;196271
Problem: When you install Tivoli Identity Manager on Windows Server 2003, the WebSphere Embedded Messaging Publish and Subscribe service is not started. Attempting to start it manually causes an error and the following message:

Could not start the Websphere Embedded Messaging Publish and
Subscribe WAS__server1 service on Local Computer.
Error 1075: The dependency service does not exist or has been
marked for deletion

Workaround: Ignore the message and continue. Tivoli Identity Manager does not require the Websphere Embedded Messaging Publish and Subscribe service. Do not attempt to start the service.
Problem: An error occurs creating the queue manager. The error in the Amqerr*.log file is the following:

AMQ9213: A communications error for TCP/IP occurred.
EXPLANATION:
An unexpected error occurred in communications.
ACTION:
The return code from the TCP/IP (ioctlsocket) call was 10038 (X'2736'). Record
these values and tell the systems administrator.

Workaround:

The 10038 return code indicates that the WebSphere MQ listener pool has had trouble passing the initial socket from the listener to the pool. This is rather common in environments that have a firewall. To work around the problem, disable the pool with the following environment variable:

set MQNOREMPOOL=1

MQJE001: Completion Code '2', Reason '2495' when using WebSphere Application Server 7.0.0.5 with WebSphere MQ - Middleware News

2012-01-15T08:21:00.000-08:00

MQJE001: Completion Code '2', Reason '2495' when using WebSphere Application Server 7.0.0.5 with WebSphere MQ - Middleware News

Problem(Abstract)

You are using WebSphere Application Server 7.0.0.5 and you see the following errors in the SystemErr.log file:

... SystemErr R com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2495'.
... SystemErr R MQJE001: Completion Code '2', Reason '2495'.

The MQ return code 2495 has the following short name:

$ mqrc 2495
2495 0x000009bf MQRC_MODULE_NOT_FOUND

You also see the following in the SystemOut.log file:

... FfdcProvider I com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: FFDC Incident emitted on /usr/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/ffdc/server1_6880688_09.10.19_04.52.57.1421628786892879991737.txt com.ibm.ejs.jms.JMSRegistration.installBundle 571
[10/19/09 4:52:57:283 EDT] 00000000 JMSRegistrati E WMSG1603E: An internal error occurred. It was not possible to register the WebSphere MQ JMS client with the application server due to exception org.osgi.framework.BundleException: An error occurred trying to read the bundle
at org.eclipse.osgi.internal.baseadaptor.BundleInstall.begin(BundleInstall.java:94)
at org.eclipse.osgi.framework.internal.core.Framework.installWorkerPrivileged(Framework.java:823)

You look at the FFDC file and this is the main information:

... FFDC Exception:org.osgi.framework.BundleException SourceId:com.ibm.ejs.jms.JMSRegistration.installBundle ProbeId:571 Reporter:com.ibm.ejs.jms.JMSRegistrationHelper@2e822e82
org.osgi.framework.BundleException: An error occurred trying to read the bundle
at org.eclipse.osgi.internal.baseadaptor.BundleInstall.begin(BundleInstall.java:94)
...
Caused by: java.io.IOException: The directory "/usr/IBM/WebSphere/AppServer/profiles/AppSrv01/configuration/org.eclipse.osgi/bundles/131/1" could not be created
at org.eclipse.osgi.internal.baseadaptor.BundleInstall.begin(BundleInstall.java:68)
... 41 more

Cause

The issue happened after applying the latest fix pack for WebSphere Application Server.
The following script was executed as a last step for adjusting the WebSphere MQ resource adapter
configuration when migrating profiles between maintenance level 7.0.0.0 and later levels:
/usr/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/osgiCfgInit.sh

For more information see:

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.soafep.multiplatform.doc/info/ae/ae/tmm_mig.html

WebSphere Application Server Version 7.0
Adjusting the WebSphere MQ resource adapter configuration when migrating profiles between maintenance level 7.0.0.0 and later levels

This script initialized the configuration and changed the owner/group of the subdirectory org.eclipse.osgi in the following directory to the user who runs the script, say "root":
/usr/IBM/WebSphere/AppServer/profiles/AppSrv01/configuration

$ ls -l
drwxr-xr-x 3 mqm mqm 4096 Oct 20 00:18 org.eclipse.core.runtime
drwxr-xr-x 3 root system 256 Oct 20 00:18 org.eclipse.osgi
drwxr-xr-x 3 mqm mqm 256 Oct 20 00:18 org.eclipse.update

Miscellaneous:

In this scenario, the user "mqm" was used to perform the first system tasks that resulted in the ownership of the above files by "mqm:mqm". Then the script was run from the user "root" and the updated file had a file ownership changed to "root:system". Then when the application server was started under the user "mqm", the mixture of file ownership for these files caused the problem.

If all the system administration tasks and the starting of the application servers were done under the user "root" then there will not be a conflict with the ownership of the files.
Resolving the problem
Change the owner/group for the files to the user that is mentioned in the Process
execution properties of the WebSphere Application Server environment, for the subdirectory org.eclipse.osgi in the directory:

/usr/IBM/WebSphere/AppServer/profiles/AppSrv01/configuration

In this example the owner/group should be "mqm":

$ ls -l
drwxr-xr-x 3 mqm mqm 4096 Oct 20 00:18 org.eclipse.core.runtime
drwxr-xr-x 3 mqm mqm 256 Oct 20 00:18 org.eclipse.osgi
drwxr-xr-x 3 mqm mqm 256 Oct 20 00:18 org.eclipse.update

ITIL - A Simple Explanation - Middleware News

2012-01-09T06:27:00.000-08:00

ITIL - A Simple Explanation - Middleware News

WebSphere MQ Advanced Message Security - Middleware News

2012-01-09T06:21:00.000-08:00

WebSphere MQ Advanced Message Security - Middleware News

WebSphere MQ Telemetry - Middleware News

2012-01-09T06:14:00.000-08:00

WebSphere MQ Telemetry - Middleware News

Enabling SSL in an existing WebSphere MQ cluster - Middleware News

2012-01-05T04:37:00.000-08:00

Enabling SSL in an existing WebSphere MQ cluster - Middleware News

Enabling SSL in an Existing WebSphere MQ Cluster

Creating Mq Cluster

IBM Websphere MQ Channel Long-Term History attributes - Middleware News

2011-12-27T19:59:00.000-08:00

IBM Websphere MQ Channel Long-Term History attributes - Middleware News

Use the Channel Long-Term History attributes to detect channel performance problems. This attribute group provides channel performance information for each monitored channel within a queue manager. These attributes are informational only; they cannot be used to create situations.

Batches Complete The number of logical units of work (LUWs) that this channel has processed after it is initialized. This attribute is not available for CICS® channels. Valid format is an integer.

Buffers Received The total number of buffers that are received during the current interval or aggregation period. Valid format is an integer.

Buffers Sent The total number of buffers that are sent during the current interval or aggregation period. Valid format is an integer.

Bytes Received The total number of bytes that are received during the current interval or aggregation period. Valid format is an integer.

Bytes Sent The total number of bytes that are sent during the current interval or aggregation period. Valid format is an integer.

Channel Name The name of this channel. Valid format is an alphanumeric string of up to 20 case-sensitive characters.

Channel Status The current operational status of the channel. "n/a" means the channel is not currently active (thus no short-term history data is available) but was active in the recent past (thus long-term history data is available).

For CICS channels, status is either In-Doubt or the CICS status (Conn_Not_Def, Out_Service, Going_Out, Released, Obtaining, Acquired, Freeing, or Available).

Valid values are as follows:

n/a = 0,
Binding = 1,
Starting = 2,
Running = 3,
Stopping = 4,
Retrying = 5,
Stopped = 6,
Requesting = 7,
Paused = 8,
Initializing = 13,
Inactive = 101,
Conn_Not_Def = 200,
Out_Service = 201,
Going_Out = 202,
Released = 203,
Obtaining = 204,
Acquired = 205,
Freeing = 206,
Available = 207,
Unknown = 255.

Channel Type The type that is assigned to the channel (SDR for sender, SVR for server, RCVR for receiver, RQSTR for requester, CLNTCONN for client connection, SVRCONN for server connection, CLUSRCVR for cluster receiver, or CLUSSDR for cluster sender) when it is created. Valid values are as follows:

n/a = 0,
SDR = 1,
SVR = 2,
RCVR = 3,
RQSTR = 4,
CLNTCONN = 6,
SVRCONN = 7,
CLUSRCVR = 8,
CLUSSDR = 9.

Connection Name The name of the physical or logical connection that this channel uses to transmit or receive data. This name is formed from the connection type (IP for TCP/IP, LU for LU6.2, or NETBIOS) and the connection address. Valid format is an alphanumeric string of up to 264 case-sensitive characters. If multiple connections are configured for the channel, this attribute is displayed as a comma separated list of system names.

CurBatch LUW ID The identifier that is assigned to the current logical unit of work (LUW). If a sender channel is in doubt, this is the problem batch. This attribute is not available for CICS channels. Valid format is an alphanumeric string of up to 16 case-sensitive characters.

CurBatch Messages The number of messages that are processed for the current logical unit of work (LUW). If a sender channel is in doubt, this is the number of messages that are currently in doubt. This attribute is not available for CICS channels. Valid format is an integer.

CurMsg SeqNo The number of the last message that is sent for the logical unit of work (LUW) that the in-doubt channel is currently processing. This attributes is not available for CICS channels. Valid format is an integer.

Cur Defn Indicates whether the queue or channel is currently defined on the monitored queue manager. Valid values are No = 0 and Yes = 1.

Current Action State The current action that is being performed by the channel. Valid values are as follows:

n/a = -1,
Other = 0,
End_Of_Batch = 100,
Sending = 200,
Receiving = 300,
Serializing = 400,
Resynching = 500,
Heartbeating = 600,
Security_exit = 700,
Receive_exit = 800,
Sending_exit = 900,
Message_exit = 1000,
Retry_exit = 1100,
Channel_definition_exit = 1200,
Net_connection = 1250,
SSL_hand_shaking = 1300,
Name_server = 1400,
MQPut = 1500,
MQGet = 1600,
MQI_Call = 1700,
Compressing = 1800.
Default Header Compression The default techniques for header data compression that are supported by the channel. Valid values are as follows:
n/a = -1,
None = 0,
Run_Length_Encoding_Compression = 1,
ZLIB_Encoding_Speed_Compression = 2,
ZLIB_Encoding_High_Compression = 4,
System = 8,
Any = 268435455.
Default Message Compression The default techniques for message data compression that are supported by the channel. Valid values are as follows:
n/a = -1,
None = 0,
Run_Length_Encoding_Compression = 1,
ZLIB_Encoding_Speed_Compression = 2,
ZLIB_Encoding_High_Compression = 4,
System = 8,
Any = 268435455.

Host Name The name of the system on which this queue manager is running. On z/OS® systems, this is the SMF ID. Valid format is an alphanumeric string of up to 48 case-sensitive characters.

In-Doubt Status Indicates whether this channel is in doubt. Valid values are No = 0, Yes = 1, and n/a = 255. A channel is considered in doubt when a logical unit of work (LUW) has been sent and the channel is waiting for an acknowledgment that the LUW has been successfully received.

Interval Length The interval time over which statistics were taken. Valid format is a character string in the form MMM:SS where M = Minute, S = Second.

Interval Time The size of the current sampling interval, in hundredths of seconds. For example, .50 is half a second. This value is determined by the control parameters that are set when configuring the WebSphere® MQ Monitoring agent; it is usually specified as 60.00 (60 seconds). Valid format is a decimal (formatted to 2 decimal places).

Last Header Compression The last techniques for header data compression that are supported by the channel. Valid values are as follows:
n/a = -1,
None = 0,
Run_Length_Encoding_Compression = 1,
ZLIB_Encoding_Speed_Compression = 2,
ZLIB_Encoding_High_Compression = 4,
System = 8,
Any = 268435455.
Last Message Compression The last techniques for message data compression that are supported by the channel. Valid values are as follows:
n/a = -1,
None = 0,
Run_Length_Encoding_Compression = 1,
ZLIB_Encoding_Speed_Compression = 2,
ZLIB_Encoding_High_Compression = 4,
System = 8,
Any = 268435455.

Last Send Date & Time The date and time that the last message is sent to the current channel/connection name combination. This attribute is not available for CICS channels. Standard 16-character date/time format (CYYMMDDHHMMSSmmm), where:

C

Century (0 for 20th, 1 for 21st)

YY

Year

MM

Month

DD

Day

HH

Hour

MM

Minute

SS

Second

mmm

Millisecond

Local Address The local communications address for the channel. The value returned depends on the TRPRYPE value of the channel (currently only TCP/IP is supported). Valid format is an alphanumeric string of up to 48 case-sensitive characters.

Long Term Batch Size The long-term number of messages in a batch. Valid format is an integer.

Long Term Compression Rate Long-term compression rate that is achieved to the nearest percentage. Valid format is a floating point number with a range from -1 - 100.

Long Term Compression Time Long-term amount of time per message, in microseconds, spent during compression or decompression. Valid format is an integer.

Long Term Exit Time Long term of the time that is taken executing user exits per message. Valid format is an integer.

Long Term Net Time Long term time of a network operation. The amount of time, in microseconds, to send a request to the remote end of the channel and receive a response. Valid format is an integer.

Long Term XmitQ Time The long-term transmission queue time. The time, in microseconds, that messages remain on the transmission queue before being retrieved. The time is measured from when the message is put onto the transmission queue until it is retrieved to be sent on the channel and, therefore, includes any interval that is caused by a delay in the putting applications. Valid format is an integer.

LUW Last Committed The identifier of the last-committed logical unit of work (LUW). Valid format is an alphanumeric string of up to 16 case-sensitive characters.

MCA Job Name (non z/OS systems only) The MCA job name string that is associated with a channel that uniquely identifies that channel. This name is provided to differentiate (along with Connection Name) between multiple active channel connections that can be defined to the same queue manager. Valid format is an alphanumeric string of up to 28 case-sensitive characters.

MCA Status The status of the message channel agent. Valid values are Stopped = 0, Running = 3.

Message Count The number of messages that are sent or received on this channel during the current interval or aggregation period. For the Interval Summary row in the Recent Channel report, this count is the sum of all the message counts in the subsequent rows. This attribute is not available for CICS channels. Valid format is an integer.

Origin Node The WebSphere MQ Monitoring agent-assigned name of the node on which the data for the queue manager originates.

On z/OS systems, this name takes the form qmgr:smfid:MQESA, where qmgr is the name of the queue manager and smfid is the z/OS system ID or SMF ID.

On distributed systems, this name takes the form qmgr::MQ. If the host ID value is specified by the SET AGENT command, this name takes the form qmgr:hostid:MQ. Valid format is an alphanumeric string of up to 128 case-sensitive characters.

QMgr Name The name that is assigned to this queue manager. Valid format is an alphanumeric string of up to 48 case-sensitive characters.

Remote Partner Application Name The name of the client application at the remote end of the channel. This parameter applies only to server-connection channels. Valid format is an alphanumeric string of up to 48 characters.

Remote Qmgr Name The name that is assigned to the queue manager or queue sharing group of the remote system. This parameter does not apply to server-connection channels, where no values are returned. Valid format is an alphanumeric string of up to 48 case-sensitive characters.

Sample Date & Time The date and time of the sample. Standard 16-character date/time format (CYYMMDDHHMMSSmmm), where:

C

Century (0 for 20th, 1 for 21st)

YY

Year

MM

Month

DD

Day

HH

Hour

MM

Minute

SS

Second

mmm

Millisecond

SeqNo Last Committed The number of the last-committed message within the last-committed logical unit of work (LUW). Valid format is an integer.

Short Retries The number of short retry intervals that are completed after the channel goes into retry state because of a connection failure. The maximum number of short retries is defined during channel definition using the SHORTRTY keyword. The time interval in seconds for short retries is defined during channel definition using the SHORTTMR keyword.

If the channel continually fails to connect after reaching the maximum number of short retry attempts, the WebSphere MQ Monitoring agent attempts long retries using the longer interval defined. If this value is non-zero while the channel is not currently retrying, it gives the most recent retry information that is being returned as the current channel status by WebSphere MQ.

This value is not available for CICS channels. Valid format is an integer.

Short Term Batch Size The short-term number of messages in a batch. Valid format is an integer.

Short Term Compression Rate Short-term compression rate that is achieved to the nearest percentage. Valid format is a floating point number with a range from -1 - 100.

Short Term Compression Time Short-term amount of time per message, in microseconds, spent during compression or decompression. Valid format is an integer.

Short Term Exit Time Short-term of the time that is taken executing user exits per message. Valid format is an integer.

Short Term Net Time Short-term time of a network operation. The amount of time (in microseconds) to send a request to the remote end of the channel and receive a response. Valid format is an integer.

Short Term XmitQ Time Short-term transmission queue time. The time, in microseconds, that messages remain on the transmission queue before being retrieved. The time is measured from when the message is put onto the transmission queue until it is retrieved to be sent on the channel and, therefore, includes any interval that is caused by a delay in the putting applications. Valid format is an integer.

SSL Key Count The number of successful SSL secret key resets that occurred for this channel instance since the channel starts. Valid format is an integer.

SSL Key Date & Time The date and time of the previous successful SSL secret key reset. Standard 16-character date/time format (CYYMMDDHHMMSSmmm), where:

C

Century (0 for 20th, 1 for 21st)

YY

Year

MM

Month

DD

Day

HH

Hour

MM

Minute

SS

Second

mmm

Millisecond

Start Date & Time The start date and time of the sample. Standard 16-character date/time format (CYYMMDDHHMMSSmmm), where:

C

Century (0 for 20th, 1 for 21st)

YY

Year

MM

Month

DD

Day

HH

Hour

MM

Minute

SS

Second

mmm

Millisecond

Transmit KB/Sec The transmission rate (in kilobytes per second) over the latest interval. This attribute is not available for CICS channels. Valid format is a decimal (formatted to 2 decimal places).

XmitQ Depth The number of messages on the transmission queue that are associated with this channel. Valid format is an integer.

The following attributes are available for WebSphere MQ version 6.0 and later only.

XmitQ Messages Available The number of messages that are available. Valid format is an integer.

User Stop Request Indicates whether user stop request is outstanding. Valid values are n/a = -1, Stop_Not_Requested = 0, Stop_Requested = 1.

Websphere MQ Message Summary attributes - Middleware News

2011-12-27T19:02:00.000-08:00

Websphere MQ Message Summary attributes - Middleware News

Use the Message Summary attributes to detect problems with messages. This group provides the backout count (which if high can indicate a problem), the correlation and message IDs, the message expiration time, the message length, message type (which can be request, reply, report, or datagram), persistence (which indicates whether the message is recoverable), priority (which can be used for selective retrieval), date and time the message was created, and the reply-to queue and queue manager names. These attributes are informational only; they cannot be used to create situations.

If multiple headers are generated, subsequent headers are prefixed with the IBM® WebSphere® MQ ID of the associated header. For example, subsequent dead letter queue headers are prefixed with DLH and subsequent transmit queue headers are prefixed with XQH. For more information, see the IBM WebSphere MQ Application Programming Reference manual.

Accounting Token The accounting token of the message. Valid format is an alphanumeric string of up to 32 case-sensitive characters.

Appl ID The application name (on z/OS®, the application identifier) of the application that put the message on the queue. Valid format is an alphanumeric string of up to 12 case-sensitive characters.

Appl Origin The application origin data of the message. Valid format is an alphanumeric string of up to 4 case-sensitive characters.

Appl Type The application type of the application that put the message on the queue. Valid format is an integer. Valid values are as follows:

Unknown = -1,
NoContext = 0,
CICS® = 1,
MVS = 2,
IMS™ = 3,
OS2 = 4,
DOS = 5,
UNIX® = 6,
QMGR = 7,
OS400 = 8,
WINDOWS = 9,
CICS_VSE = 10,
WINDOWS_NT = 11,
VMS = 12,
GUARDIAN = 13,
VOS = 14,
IMS_BRIDGE = 19,
XCF = 20,
CICS_BRIDGE = 21,
NOTES_AGENT = 22,
SYSTEMEXT = 35,
USER = 65536

Application Identity Data The application identity data of the message. Valid format is an alphanumeric string of up to 32 case-sensitive characters.

Backout Count The backout count of the message. A high value might indicate a problem. Valid format is an integer.

Coded CharSetID The coded character set identifier, CCSID, of the message. Valid format is an integer.

Correlation ID The correlation identifier of the message, in hexadecimal character format. Valid format is an alphanumeric string of up to 48 case-sensitive characters.

Correlation ID (Char) The correlation identifier of the message. Valid format is an alphanumeric string of up to 24 characters.

Dest QMgr The destination queue manager of the message. Valid format is an alphanumeric string of up to 48 characters.

Dest Queue The destination queue of the message. Valid format is an alphanumeric string of up to 48 characters.

DLQ Appl ID The application name (or on z/OS, the application identifier) of the application that put the message on the dead-letter queue. Valid format is an alphanumeric string of up to 28 characters.

DLQ Appl Type The application type of the application that put the message on the dead-letter queue. Valid format is an integer. Valid values are as follows:

Unknown = -1,
NoContext = 0,
CICS = 1,
MVS = 2,
IMS = 3,
OS2 = 4,
DOS = 5,
UNIX = 6,
QMGR = 7,
OS400 = 8,
WINDOWS = 9,
CICS_VSE = 10,
WINDOWS_NT = 11,
VMS = 12,
GUARDIAN = 13,
VOS = 14,
IMS_BRIDGE = 19,
XCF = 20,
CICS_BRIDGE = 21,
NOTES_AGENT = 22,
USER = 65536

DLQ Put Date & Time The date and time the message is put on the dead-letter queue. Standard 16-character date/time format (CYYMMDDHHMMSSmmm), where:

C

Century (0 for 20th, 1 for 21st)

YY

Year

MM

Month

DD

Day

HH

Hour

MM

Minute

SS

Second

mmm

Millisecond

Encoding The encoding value of the message comparing with Origin Encoding. Valid format is an integer.

Expire (Secs) The expiration of the message, in seconds. Valid format is an integer.

Feedback Code The feedback code of the message. Valid format is an integer.

Format Name The format name of the message. Valid format is an alphanumeric string of up to 8 case-sensitive characters.

Group ID The group identifier for segmented or group messages. Valid format is an alphanumeric string of up to 48 characters.

Host Name The name of the system on which this queue manager is running. On z/OS systems, this is the SMF ID. Valid format is an alphanumeric string of up to 48 case-sensitive characters.

Message ID The message identifier of the message. Valid format is an alphanumeric string of up to 48 case-sensitive characters.

Message Tag Cyclic redundancy check (CRC) for message descriptor (MQMD) in hexadecimal characters. Valid format is an alphanumeric string of up to 8 characters.

Msg Length The length of the message. Valid format is an integer.

Msg Type The message type (can be request, reply, report, or datagram). Valid format is an integer. Valid values are
Request = 1,
Reply = 2,
Report = 4,
Datagram = 8,
Appl = 65536
Origin CharSetID The coded character set identifier, CCSID, of the original message. Valid format is an integer.

Origin Encoding The encoding value of the original message. Valid format is an integer.

Origin Format The format name of the original message. Valid format is an alphanumeric string of up to 8 case-sensitive characters.

Origin Node The WebSphere MQ Monitoring agent-assigned name of the node on which the data for the queue manager originates.

On z/OS systems, this name takes the form qmgr:smfid:MQESA, where qmgr is the name of the queue manager, and smfid is the z/OS system ID or SMF ID.

On distributed systems, this name takes the form qmgr::MQ. If the host ID value is specified by the SET AGENT command, this name takes the form qmgr:hostid:MQ. Valid format is an alphanumeric string of up to 128 case-sensitive characters.

Persistence Indicates whether the message is persistent. Valid values are No = 0, Yes = 1. This indicates whether the message is recoverable.

Priority The priority of the message. Valid format is an integer.

Put Date & Time The date and time that the message is put on the queue. Standard 16-character date/time format (CYYMMDDHHMMSSmmm), where:

C

Century (0 for 20th, 1 for 21st)

YY

Year

MM

Month

DD

Day

HH

Hour

MM

Minute

SS

Second

mmm

Millisecond

QMgr Name The name that is assigned to this queue manager. Valid format is an alphanumeric string of up to 48 case-sensitive characters.

Queue Name The name of the queue that is specified in the MQOPEN call (MQOD_ObjectName) of the application. Valid format is an alphanumeric string of up to 48 case-sensitive characters.

Reason Code The reason code for the message. This indicates why the message is undeliverable. Valid format is an integer.

Valid values are as follows:

None = 0,
(KMQW000W)263-Channel_Fail_Retry = 263,
(KMQW000W)264-Channel_Fail = 264,
(KMQW000W)265-Appl_Cannot_Be_Started = 265,
(KMQW000W)266-Trigger_Msg_Error = 266,
(KMQW000W)267-Appl_Type_Error = 267,
(KMQW000W)268-Stopped_By_Msg_Exit = 268,
(KMQW000W)271-Xmit_Q_Msg_Error = 271,
(KMQW000W)2003-Backed_Out = 2003,
(KMQW000W)2009-Connection_Broken = 2009,
(KMQW000W)2012-Environment_Error = 2012,
(KMQW000W)2030-Msg_Too_Big_For_Q = 2030,
(KMQW000W)2031-Msg_Too_Big_For_Q_Mgr = 2031,
(KMQW000W)2035-Not_Authorized = 2035,
(KMQW000W)2048-Persistent_Not_Allowed = 2048,
(KMQW000W)2051-Put_Inhibited = 2051,
(KMQW000W)2052-Q_Deleted = 2052,
(KMQW000W)2053-Q_Full = 2053,
(KMQW000W)2056-Q_Space_Not_Available = 2056,
(KMQW000W)2057-Q_Type_Error = 2057,
(KMQW000W)2063-Security_Error = 2063,
(KMQW000W)2082-Unknown_Alias_Base_Q = 2082,
(KMQW000W)2085-Unknown_Object_Name = 2085,
(KMQW000W)2086-Unknown_Object_Q_Mgr = 2086,
(KMQW000W)2087-Unknown_Remote_Q_Mgr = 2087,
(KMQW000W)2098-Context_Not_Available = 2098,
(KMQW000W)2101-Object_Damaged = 2101,
(KMQW000W)2102-Resource_Problem = 2102,
(KMQW000W)2150-DBCS_Error = 2150,
(KMQW000W)2192-Pageset_Full = 2192,
(KMQW000W)2193-Pageset_Error = 2193,
(KMQW000W)2195-Unexpected_Error = 2195,
(KMQW000W)2203-Connection_Stopping = 2203,
(KMQW000W)2204-Adapter_Not_Available = 2204,
(KMQW000W)2208-File_System_Error = 2208,
(KMQW000W)2218-Msg_Too_Big_For_Channel = 2218,
(KMQW000W)2223-Q_Mgr_Not_Active = 2223,
(KMQW000W)2228-Channel_Not_Available = 2228,
(KMQW000W)2230-Channel_Error = 2230,
(KMQW000W)2249-Msg_Flags_Error = 2249,
(KMQW000W)2285-Service_Not_Available = 2285,
(KMQW000W)2289-Service_Error = 2289

Reply to QMgr The name of the reply-to queue manager. Valid format is an alphanumeric string of up to 48 case-sensitive characters.

Reply to Queue The name of the reply-to queue. Valid format is an alphanumeric string of up to 48 case-sensitive characters.

Report Options The report options. Valid format is an integer.

Segmented or Group Message Indicates whether the message is a Segmented or Group message, or both. Valid values include No = 0, Segment = 1, Group = 2, Group_Segment = 3.

Status The status of the open or get. Valid format is an integer of up to 4 digits.

Valid values are
OK = 0,
(KMQW000W)2001-Alias_Base_Q_Type_Error = 2001,
(KMQW000W)2004-Buffer_Error = 2004,
(KMQW000W)2005-Buffer_Length_Error = 2005,
(KMQW000W)2009-Connection_Broken = 2009,
(KMQW000W)2010-Data_Length_Error = 2010,
(KMQW000W)2011-Dynamic_Q_Name_Error = 2011,
(KMQW000W)2016-Get_Inhibited = 2016,
(KMQW000W)2017-Handle_Not_Available = 2017,
(KMQW000W)2018-Hconn_Error = 2018,
(KMQW000W)2019-Hobj_Error = 2019,
(KMQW000W)2024-Syncpoint_Limit_Reached = 2024,
(KMQW000W)2026-MD_Error = 2026,
(KMQW000W)2033-No_Msg_Available = 2033,
(KMQW000W)2034-No_Msg_Under_Cursor = 2034,
(KMQW000W)2035-Not_Authorized = 2035,
(KMQW000W)2036-Not_Open_For_Browse = 2036,
(KMQW000W)2037-Not_Open_For_Input = 2037,
(KMQW000W)2041-Object_Changed = 2041,
(KMQW000W)2042-Object_In_Use = 2042,
(KMQW000W)2043-Object_Type_Error = 2043,
(KMQW000W)2044-OD_Error = 2044,
(KMQW000W)2045-Option_Not_Valid_For_Type = 2045,
(KMQW000W)2046-Options_Error = 2046,
(KMQW000W)2052-Q_Deleted = 2052,
(KMQW000W)2057-Q_Type_Error = 2057,
(KMQW000W)2058-Q_Mgr_Name_Error = 2058,
(KMQW000W)2059-Q_Mgr_Not_Available = 2059,
(KMQW000W)2062-Second_Mark_Not_Allowed = 2062,
(KMQW000W)2063-Security_Error = 2063,
(KMQW000W)2069-Signal_Outstanding = 2069,
(KMQW000W)2070-Signal_Request_Accepted = 2070,
(KMQW000W)2071-Storage_Not_Available = 2071,
(KMQW000W)2079-Truncated_Msg_Accepted = 2079,
(KMQW000W)2080-Truncated_Msg_Failed = 2080,
(KMQW000W)2082-Unknown_Alias_Base_Q = 2082,
(KMQW000W)2085-Unknown_Object_Name = 2085,
(KMQW000W)2086-Unknown_Object_Q_Mgr = 2086,
(KMQW000W)2087-Unknown_Remote_Q_Mgr = 2087,
(KMQW000W)2091-Xmit_Q_Type_Error = 2091,
(KMQW000W)2092-Xmit_Q_Usage_Error = 2092,
(KMQW000W)2099-Signal1_Error = 2099,
(KMQW000W)2100-Object_Already_Exists = 2100,
(KMQW000W)2101-Object_Damaged = 2101,
(KMQW000W)2102-Resource_Problem = 2102,
(KMQW000W)2109-Suppressed_By_Exit = 2109,
(KMQW000W)2110-Format_Error = 2110,
(KMQW000W)2111-Source_CCSID_Error = 2111,
(KMQW000W)2112-Source_Integer_Enc_Error = 2112,
(KMQW000W)2113-Source_Decimal_Enc_Error = 2113,
(KMQW000W)2114-Source_Float_Enc_Error = 2114,
(KMQW000W)2115-Target_CCSID_Error = 2115,
(KMQW000W)2116-Target_Integer_Enc_Error = 2116,
(KMQW000W)2117-Target_Decimal_Enc_Error = 2117,
(KMQW000W)2118-Target_Float_Enc_Error = 2118,
(KMQW000W)2119-Not_Converted = 2119,
(KMQW000W)2120-Converted_Msg_Too_Big = 2120,
(KMQW000W)2130-Adapter_Serv_Load_Error = 2130,
(KMQW000W)2133-Adapter_Conv_Load_Error = 2133,
(KMQW000W)2136-Multiple_Reasons = 2136,
(KMQW000W)2140-CICS_Wait_Failed = 2140,
(KMQW000W)2152-Object_Name_Error = 2152,
(KMQW000W)2153-Object_Q_Mgr_Name_Error = 2153,
(KMQW000W)2154-Recs_Present_Error = 2154,
(KMQW000W)2155-Object_Records_Error = 2155,
(KMQW000W)2156-Response_Records_Error = 2156,
(KMQW000W)2157-ASID_Mismatch = 2157,
(KMQW000W)2161-Q_Mgr_Quiescing = 2161,
(KMQW000W)2162-Q_Mgr_Stopping = 2162,
(KMQW000W)2183-API_Exit_Load_Error = 2183,
(KMQW000W)2184-Remote_Q_Name_Error = 2184,
(KMQW000W)2186-GMO_Error = 2186,
(KMQW000W)2192-Pageset_Full = 2192,
(KMQW000W)2193-Pageset_Error = 2193,
(KMQW000W)2194-Name_Not_Valid_For_Type = 2194,
(KMQW000W)2195-Unexpected_Error = 2195,
(KMQW000W)2196-Unknown_Xmit_Q = 2196,
(KMQW000W)2197-Unknown_Def_Xmit_Q = 2197,
(KMQW000W)2198-Def_Xmit_Q_Type_Error = 2198,
(KMQW000W)2199-Def_Xmit_Q_Usage_Error = 2199,
(KMQW000W)2201-Name_In_Use = 2201,
(KMQW000W)2202-Connection_Quiescing = 2202,
(KMQW000W)2203-Connection_Stopping = 2203,
(KMQW000W)2204-Adapter_Not_Available = 2204,
(KMQW000W)2209-No_Msg_Locked = 2209,
(KMQW000W)2217-Connection_Not_Authorized = 2217,
(KMQW000W)2219-Call_In_Progress = 2219,
(KMQW000W)2241-Incomplete_Group = 2241,
(KMQW000W)2242-Incomplete_Msg = 2242,
(KMQW000W)2243-Inconsistent_CCSIDs = 2243,
(KMQW000W)2244-Inconsistent_Encodings = 2244,
(KMQW000W)2245-Inconsistent_UOW = 2245,
(KMQW000W)2246-Invalid_Msg_Under_Cursor = 2246,
(KMQW000W)2247-Match_Options_Error = 2247,
(KMQW000W)2255-UOW_Not_Available = 2255,
(KMQW000W)2256-Wrong_GMO_Version = 2256,
(KMQW000W)2257-Wrong_MD_Version = 2257,
(KMQW000W)2259-Inconsistent_Browse = 2259,
(KMQW002E)Unsupported_CCSID_Found = 9002,
(KMQW005E)Insufficient_Storage = 9005,
(KMQW008E)Not_Allowed_By_MSGACCESS = 9008,
(KMQW009E)Agent_Timeout_Occurred = 9009

User Identifier The user identifier that is used for MQ requests that must be authenticated to the terminal user. Valid format is an alphanumeric string of up to 12 case-sensitive characters.

ISO 20022 made simple - Middleware News

2011-12-21T22:07:00.001-08:00

ISO 20022 made simple - Middleware News

Watch - Business Intelligence @ SWIFT - Middleware News

2011-12-21T22:03:00.001-08:00

Watch - Business Intelligence @ SWIFT - Middleware News

SWIFT for banks - Middleware News

2011-12-21T21:58:00.000-08:00

SWIFT for banks - Middleware News

The maths behind international banking codes (IBAN's) - Middleware News

2011-12-21T21:55:00.000-08:00

The maths behind international banking codes (IBAN's) - Middleware News

MQGET for SYSTEM.ADMIN.COMMAND.QUEUE failed with reason code 2071 - Middleware News

2011-12-14T14:02:00.000-08:00

MQGET for SYSTEM.ADMIN.COMMAND.QUEUE failed with reason code 2071 - Middleware News

Command server fails to start or fails shortly after it receives a message in the SYSTEM.ADMIN.COMMAND.QUEUE. No FDC files are generated. the error received is AMQ8506:
Command server MQGET failed with reason code 2071.

EXPLANATION:

An MQGET request by the command server, for the WebSphere MQ queue SYSTEM.ADMIN.COMMAND.QUEUE, failed with reason code 2071.

Symptom

2071 0x00000817 MQRC_STORAGE_NOT_AVAILABLE

Cause

Well designed MQ server applications typically assume a relatively small initial buffer size, and then heuristically tune the required buffer size based upon the sizes of the messages consumed. For example both the repository manager and the pubsub broker adopt such a scheme.

The MQ command server however allocates a fixed size buffer based upon the MAXMSGL defined for the SYSTEM.ADMIN.COMMAND.QUEUE and then issues it's MQGET's using this buffer size. Because the commands accepted by the command server are not intrinsically big, and the default MAXMSGL for SYSTEM.ADMIN.COMMAND.QUEUE is only 9000 bytes, then this simplistic scheme is generally adequate in this scenario.

However if a very large MAXMSGL is set for SYSTEM.ADMIN.COMMAND.QUEUE, then this would be a relatively inefficient design, as the command server would allocate a very large buffer and the queue manager would interpret this as a hint that very large messages were going to be processed.

If the max message length for the SYSTEM.ADMIN.COMMAND.QUEUE is increased, the command server allocates a larger buffer when reading messages from this queue. If it is significantly increased, say from 4 to 100 MB, the "data" ulimit for the process can be insufficient, causing it to crash.

Resolving the problem

***** PLEASE READ THIS CAREFULLY ******
Do not alter MAXMSGL set for SYSTEM.ADMIN.COMMAND.QUEUE Certain system objects are managed exclusively by the queue manager and should never be modified under any circumstance. However here are some workarounds to get the command server to start. Any of these should work.
*********************************************

In /etc/security/limits, increase the "data" ulimit for the account used to start the queue manager (usually root) to 192 MB or greater. Setting the data segment size (ulimit -d) to unlimited will resolve the issue. Note that the value is configured in 512 byte blocks, and -1 means unlimited.

In runmqsc, reset the MAXMSGL attribute on the SYSTEM.ADMIN.COMMAND.QUEUE to 4194304.
In runmqsc, decrease the queue manager's MAXMSGL attribute to something like 33554432, depending on the "data" ulimit value.

Channels intermittently go into a status of INITIALIZING - Middleware News

2011-12-14T13:59:00.000-08:00

Channels intermittently go into a status of INITIALIZING - Middleware News

You see that intermittently your channels go into a status of INITIALIZING. To resolve the problem, you have to end the queue manager and IPL the system.

Symptom

You receive RC2071: 2071 0x00000817 MQRC_STORAGE_NOT_AVAILABLE

FDC has the following information:

Probe Id :- ZX010020
Application Name :- MQM
Component :- zxcCreateParmFile
Program Name :- AMQZXMA0 QMQM
Major Errorcode :- xecF_E_UNEXPECTED_SYSTEM_RC
Minor Errorcode :- OK
Probe Type :- MSGAMQ6119
Probe Severity :- 2
Probe Description :- AMQ6119: An internal MQSeries error
has occurred(The value specified for the argument is not
correct.: fopen:
/QIBM/UserData/mqm/qmgrs/QM_DBQFMSP1/startprm/ip5684:)
Comment1:- The value specified for the argument
is not correct.: fopen: /Q

Cause

The existence of ip## files in the startprm directory. It appears the ip## file
was orphaned by either a shutdown that did not end cleanly, or by a job that abended.

Resolving the problem

To resolve the WMQ concern, stop all channels and use the RMVLNK command to delete the ip## object(s). After the ip## objects have been deleted you should be able to restart the channels.

Additional information

The purposes of the ip* files:

When the execution controller (AMQZXMA0) starts an agent for an application, it needs to pass more parameters than are shown on the agent's command line, so, the EC writes them to a file in the queue manager's 'startprm' subdirectory called 'ip##' (where the ## starts at one and increases by one). It contains all of the agent's parameters. The agent is then started and given the name of it's initialization parameter file on the command line, which it opens, reads, and deletes.

Note: Originally the enduser encountered the problem when they attempted to rename the ip## object under the startprm sub-directory. They received messages MCH3402, CPDA1CC and CPFA0A2. This indicates a possible problem in the Integrated file system, and should be reported to the Rochester Support Team.

AMQ5615 on queue manager start up after running security programs - Middleware News

2011-12-14T13:55:00.001-08:00

AMQ5615 on queue manager start up after running security programs - Middleware News

You run an application that altered file permissions. You reboot the server, and now the WebSphere MQ queue manager will not start. You receive the following error message:

AMQ5615 - Default objects cannot be created. rc 2071

2071 0x00000817 MQRC_STORAGE_NOT_AVAILABLE

The return code indicates a shortage of storage, however the system has plenty of space and you are able to create new qmgrs and objects.

Cause

Altered file permissions on the queue manager directories.

Resolving the problem

Restore file permissions for the queue manager to the original settings to provide the mqm group and users the access required. The security tab for the directory/file properties should show the mqm group with full control.
The mqm group needs full access to the data, log and code directories.

WebSphere MQ Dumps and FFSTs are written to the following locations - Middleware News

2011-12-14T13:53:00.000-08:00

WebSphere MQ Dumps and FFSTs are written to the following locations - Middleware News

Directions for finding WebSphere MQ Dump and FFST records.

Resolving the problem

Dumps and FFST records contain important information that can be used in problem solving. If you have a WebSphere MQ problem, you may receive Dumps and FFSTs, that record details related to the failure.
Select one of the following platforms to find the location of the MQ Dumps and FFSTs:

HP NSS
i5/OS
OpenVMS
UNIX and Linux
VSE
Windows
z/OS

HP NSS

FFSTs are located in the following directory:

/var/mqm/errors

These errors are normally severe, unrecoverable errors, and indicate either a configuration problem with the system or a WebSphere MQ internal error.

The files are named AMQccppppp.nn.FDC, where cc is the number of the CPU in which the process that reported the error was running, ppppp is the process identification number (PIN) of the process that reported the error, and nn is a sequence number, normally 0.

i5/OS

FFSTs are located in the following directory:

/QIBM/UserData/mqm/errors

The files are named AMQnnnnnnnn_mm.FDC, where: nnnnnnnn is the process id reporting the error, and mm is a sequence number, normally 0.

OpenVMS

FFSTs are located in the following directory:

MQS_ROOT:[MQM.ERRORS]AMQ.FDC
Where PID is the process id of the MQ process which generated the FFST.

These errors are normally severe, unrecoverable errors and indicate either a configuration problem with the system or a WebSphere MQ internal error.

UNIX and Linux

FFSTs are located in the following directory:

/var/mqm/errors

The files are named AMQnnnnnnnn_mm.FDC, where: nnnnnnnn Is the process id reporting the error mm Is a sequence number, normally 0

VSE

Dumps are normally stored by z/VSE in the VSE dump library.

Windows

FFSTs are located in the following directory:

c:\Program Files\IBM\WebSphere MQ\errors

The files are named AMQnnnnnnnn_mm.FDC, where: nnnnnnnn Is the process id reporting the error mm Is a sequence number, normally 0

Note: This is the default directory path, however it may have been changed at install time.

z/OS

Dumps are located in the system dump data set.

Example of a dump title:

CSQ1,ABN=5C6-00E20016,U=SYSOPR ,C=R3600.701.MMC -CSQMTRG2,M=CSQGFRCV, LOC=CSQSLD1 .CSQSVSTK+0000057AF

WebSphere MQ error logs - Middleware News

2011-12-14T13:50:00.000-08:00

WebSphere MQ error logs - Middleware News

Directions to find WebSphere MQ and MQSeries error logs.

Note: The MQ error logs are by default located in the following directories, however it may have been changed at install time:

Resolving the problem

The messages that are recorded in the error logs and job logs are the most important information that you can provide when reporting an MQ problem.
Select one of the following platforms to find the location of the MQ error logs:

HP NSS
i5/OS
OpenVMS
UNIX and Linux
VSE
Windows
z/OS

HP NSS

The WebSphere MQ for HP NSS error logs are located in the following directories:

/var/mqm/errors
/var/mqm/qmgrs//errors

The error log files are named; AMQERR01.LOG, AMQERR02.LOG and AMQERR03.LOG.

Notes:
If the queue manager name is not known then the error message is written to an error log file in the errors subdirectory. For example, if the default prefix is /usr/ibm/wmq/GA/var/mqm, the error message is written to an error log file in the directory /usr/ibm/wmq/GA/var/mqm/errors
If the queue manager name is known, then the error message is written to an error log file in the queue manager’s errors directory.

i5/OS

The WebSphere MQ for i5/OS error logs are located in the following directories:

/QIBM/UserData/mqm/qmgrs//errors
/QIBM/UserData/mqm/qmgrs/&SYSTEM

The error log files are named; AMQERR01.LOG, AMQERR02.LOG and AMQERR03.LOG.

OpenVMS

The WebSphere MQ HP OpenVMS error logs are located in the following directories:

MQS_ROOT:[MQM.ERRORS]AMQERR01.LOG
MQS_ROOT:[MQM.QMGRS.QMgrName.ERRORS]AMQERR01.LOG
MQS_ROOT:[MQM.QMGRS.$SYSTEM.ERRORS]AMQERR01.LOG
- The error log files are named; AMQERR01.LOG, AMQERR02.LOG and AMQERR03.LOG.

MQS_ROOT:[MQM.ERROR]VMSERR.LOG

Notes:

If an error has occurred with a client application: MQS_ROOT:[MQM.ERRORS]AMQERR01.LOG
If the queue manager name is known and the queue manager is available: MQS_ROOT:[MQM.QMGRS.QMgrName.ERRORS]AMQERR01.LOG
If the queue manager is not available: MQS_ROOT:[MQM.QMGRS.$SYSTEM.ERRORS]AMQERR01.LOG

UNIX and Linux

The WebSphere MQ for UNIX error logs are located in the following directories:

/var/mqm/errors
/var/mqm/qmgrs//errors
/var/mqm/qmgrs/@SYSTEM/errors (not used at V6 and higher)

The error log files are named; AMQERR01.LOG, AMQERR02.LOG and AMQERR03.LOG.
Back to top

VSE

MQSeries uses the SYSTEM.LOG queue defined in the global system definition as its primary message log and additional informational messages are output to the VSE console. Typically, these detail starting, stopping, and initializing MQSeries for VSE If the SYSTEM.LOG queue is unavailable, the messages are directed to the CICS CSMT log.

These messages should always be reviewed carefully for any error messages. The type of messages included in the SYSTEM.LOG queue can now be controlled by using the ’Log and Trace Settings’.

Refer to the MQSeries for VSE System Management Guide, “Queue Manager Log and Trace Settings” on page 74 for details. Note that the types of messages put to the SYSTEM.LOG queue can be controlled
using the LOG SETTINGS. When trying to resolve problems, ensure that all messages of all severity are
selected to be logged. You can view the contents of the system log using the Master Terminal transaction (MQMT) option 4 (Browse Queue Records).

Windows

The WebSphere MQ for Windows error logs are located in the following directories. This is the default directory path, however it may have been changed at install time:

c:\Program Files\IBM\WebSphere MQ\errors
c:\Program Files\IBM\WebSphere MQ\qmgrs\\errors
c:\Program Files\IBM\WebSphere MQ\qmgrs\@SYSTEM\errors (not used at V6 and higher)

The error log files are named; AMQERR01.LOG, AMQERR02.LOG and AMQERR03.LOG.

z/OS

The WebSphere MQ for OS/390 and z/OS job logs are located in the following:

Syslog
MSTR job log
CHIN job log

The job logs are named; xxxxMSTR, and xxxxCHIN. Where xxxx is the WMQ subsystem identifier (ssid).

In the AIX error log, there are errors with label AMQFFSTx, such as AMQFFST1 AMQFFST2 AMQFFST3 AMQFFST4 - Middleware News

2011-12-14T11:26:00.000-08:00

You see in the AIX error log, errors with a label format of AMQFFSTx, such as AMQFFST1, AMQFFST3, AMQFFST4.

Symptom

An example is shown below:

LABEL: AMQFFST3
IDENTIFIER: 8xxxxxxx
Date/Time: Sun Dec 31 11:31:18 EST
Sequence Number: 3770
Machine Id: 00FFFFFF
Node Id: pppppdc
Class: S
Type: UNKN
Resource Name: MQSeries NONE
Description
SOFTWARE PROGRAM ABNORMALLY TERMINATED
Probable Causes
UNDETERMINED
Failure Causes
SOFTWARE PROGRAM
Recommended Actions
REVIEW DETAILED DATA
CONTACT APPROPRIATE SERVICE REPRESENTATIVE
Detail Data
DETECTING MODULE
xcsCloseEventSem
SOFTWARE ERROR CODE
0000 0001
FILE NAME
/var/mqm/errors/AMQ30656.0.FDC
Cause
Sometimes, WebSphere MQ errors will cause the AIX operating system to put entries into the AIX error log that have the label of AMQFFSTx, such as AMQFFST1, AMQFFST3, AMQFFST4.
Resolving the problem
For more details on the MQ problem, review the file mentioned at the end of the error entry in the AIX errpt, such as:
FILE NAME
/var/mqm/errors/AMQ30656.0.FDC

When an abnormal situation happens, MQ creates an FDC (First Data Capture) file using FFST (First Failure Support Technology) in /var/mqm/errors and it is important to view this FDC file to find out more information on the abnormal situation.

WEBSPHERE MQ V6 QUEUE MANAGER ON OPENVMS DOES NOT START LISTENER OR OTHER SERVICES AT STARTUP DUE TO KN246001 FDC IN AMQZXMA0.EXE - Middleware News

2011-12-14T11:05:00.000-08:00

WEBSPHERE MQ V6 QUEUE MANAGER ON OPENVMS DOES NOT START LISTENER OR OTHER SERVICES AT STARTUP DUE TO KN246001 FDC IN AMQZXMA0.EXE - Middleware News

Error Description:

WebSphere MQ v6 queue managers use a program called the process
manager (AMQZMGR0.EXE) to start and monitor services such as
listeners and the command server. In certain environments this
process manager can fail to start queue manager services due to
an unexpected condition. The queue manager may generate FDCs
showing symptoms like the following:
.
Probe Id :- KN246001
Component :- kpiAncillaryProcessStartup
Program Name :- AMQZXMA0.EXE
Major Errorcode :- zrcX_INVALID_OBJECT_TYPE
VMS Errorcode :- -RMS-E-FNF, file not found (00018292)
.
Probe Id :- KN246002
Component :- kpiAncillaryProcessStartup
Program Name :- AMQZXMA0.EXE
Major Errorcode :- ocmRC_UNEXPECTED_CSV_STATE
VMS Errorcode :- -RMS-E-FNF, file not found (00018292)
.
Probe Id :- ZT208001
Component :- zupSetProcessState
Program Name :- RUNMQLSR.EXE
Major Errorcode :- zrcX_PROCESS_NOT_RUNNING
VMS Errorcode :- -RMS-E-FNF, file not found (00018292)
.
.
The process manager itself may not generate any FDC entries, but
a Websphere MQ trace during queue manager startup will show this
program ending shortly after the following pattern:
.
-{ zxpProcessMessage
--{ xcsSimplePipeRead
--} xcsSimplePipeRead rc=OK
Expected 1716 bytes got 1432 bytes
0x0000: 5a535354 35210000 03000000 00000000 |ZSST5!
...
--{ xcsSimplePipeWrite
--} xcsSimplePipeWrite rc=OK
--{ xcsDisconnectSimplePipe
...
--} xcsDisconnectSimplePipe rc=OK
-} zxpProcessMessage rc=OK

Local fix

Problem summary

It is observed that in some cases of third party software
usage as a transport layer, users issuing STRMQM command are
unable to perform remote administration. In Queue Manager
startup, the processes such as "Command Server", "Channel
Initiators", and "Listeners" are not spawned automatically.
As a result remote administration is not possible.
.
In this particular scenario when third party software is
used partial reads are likely to happen. When the partial
read happens, the control comes out of the read loop in the
code and the data read is not equal to the expected bytes.
At later stages a check is made for verifying the number of
bytes read. Since the number of bytes read is not meeting the
expected value, MQ functionality will be not be rendered.
This problem is likely to be noticed when Process Software
"Multinet V5.3" is installed on the system.

Problem conclusion

The common services component of MQ has been changed to fix
these partial reads. The loop containing the read() calls is
modified to ensure that complete data over the socket is read.
The fix for this APAR will be included in next fixpack release
on OpenVMS Alpha and Itanium.
.
In order to make this fix functional, it is mandatory to define
below the mentioned logical before queue manager start.
.
The command to define the logical: AMQ_SUPPORT_MULTINET :
.
$ Define /system AMQ_SUPPORT_MULTINET "1"

Limiting RUNMQSC authority for certain users - Middleware News

2011-12-14T11:02:00.000-08:00

Limiting RUNMQSC authority for certain users - Middleware News

You want to provide limited access to RUNMQSC for non-mqm users. You want to make sure that they can only DISPLAY information about a queue manager and the queue manager's objects.

Cause

WebSphere MQ is configured so that only "mqm" users can use runmqsc. The runmqsc program is shipped with the following permission settings:

-r-sr-s--- 1 mqm mqm

Resolving the problem

Create a non mqm user

setmqaut -m -t qmgr -p +dsp +connect

Create a copy of runmqsc with execute permission set to all. When the permissions are changed to -r-sr-sr-x this means any user can run runmqsc but when it runs, it runs as user mqm, group mqm due to the Set-user-ID-on-execution and Set-group-ID-on-execution permissions.

cd /var/mqm/qmgrs//@ipcc
chmod +r AMQCLCHL.TAB
chmod +r AMQRFCDA.DAT

SWIFT MT 100 and 102 and 200 and 205 and 201 and 202 and 299 and 203 and 202 and 204? - Middleware News

2011-12-12T13:23:00.000-08:00

SWIFT MT 100 and 102 and 200 and 205 and 201 and 202 and 299 and 203 and 202 and 204? - Middleware News

The MT100 is an Interbank Message Which Basically the Sending Bank Advises the Receiving Bank to Expect Fun...

Queue status - Middleware News

2011-12-09T09:16:00.000-08:00

Queue status - Middleware News

For queue status, the following information is always returned for each queue that satisfies the selection criteria, except where indicated:

Queue name
Type of information returned (TYPE parameter)
On platforms other than z/OS®, current queue depth (CURDEPTH parameter)
On z/OS only, the queue-sharing group disposition (QSGDISP parameter)

The following parameters can be specified for TYPE(QUEUE) to request additional information for each queue. If a parameter is specified that is not relevant for the queue, operating environment, or type of status information requested, that parameter is ignored.

CURDEPTH
The current depth of the queue, that is, the number of messages on the queue. This includes both committed messages and uncommitted messages.
IPPROCS
The number of handles that are currently open for input for the queue (either input-shared or input-exclusive). This does not include handles that are open for browse.

For shared queues, the number returned applies only to the queue manager generating the reply. The number is not the total for all the queue managers in the queue-sharing group.
LGETDATE
The date on which the last message was retrieved from the queue since the queue manager started. A message being browsed does not count as a message being retrieved. When no get date is available, perhaps because no message has been retrieved from the queue since the queue manager was started, the value is shown as a blank. For queues with QSGDISP(SHARED), the value shown is for measurements collected on this queue manager only.

This parameter is also displayed when you specify the MONITOR parameter.

A value is only displayed for this parameter if MONQ is set to a value other than OFF for this queue.
LGETTIME
The time at which the last message was retrieved from the queue since the queue manager started. A message being browsed does not count as a message being retrieved. When no get time is available, perhaps because no message has been retrieved from the queue since the queue manager was started, the value is shown as a blank. For queues with QSGDISP(SHARED), the value shown is for measurements collected on this queue manager only.

This parameter is also displayed when you specify the MONITOR parameter.

A value is only displayed for this parameter if MONQ is set to a value other than OFF for this queue.
LPUTDATE
The date on which the last message was put to the queue since the queue manager started. When no put date is available, perhaps because no message has been put to the queue since the queue manager was started, the value is shown as a blank. For queues with QSGDISP(SHARED), the value shown is for measurements collected on this queue manager only.

This parameter is also displayed when you specify the MONITOR parameter.

A value is only displayed for this parameter if MONQ is set to a value other than OFF for this queue.
LPUTTIME
The time at which the last message was put to the queue since the queue manager started. When no put time is available, perhaps because no message has been put to the queue since the queue manager was started, the value is shown as a blank. For queues with QSGDISP(SHARED), the value shown is for measurements collected on this queue manager only.

This parameter is also displayed when you specify the MONITOR parameter.

A value is only displayed for this parameter if MONQ is set to a value other than OFF for this queue.
MEDIALOG
The log extent or journal receiver needed for media recovery of the queue. On queue managers on which circular logging is in place, MEDIALOG is returned as a null string.

This is valid on AIX®, HP-UX, Linux, i5/OS®, Solaris, and Windows.
MONQ
Current level of monitoring data collection for the queue.

This parameter is also displayed when you specify the MONITOR parameter.
MSGAGE
Age, in seconds, of the oldest message on the queue. The maximum displayable value is 999 999 999; if the age exceeds this value, 999 999 999 is displayed.

This parameter is also displayed when you specify the MONITOR parameter.

A value is only displayed for this parameter if MONQ is set to a value other than OFF for this queue.
OPPROCS
This is the number of handles that are currently open for output for the queue.

For shared queues, the number returned applies only to the queue manager generating the reply. The number is not the total for all the queue managers in the queue-sharing group.
QSGDISP
Indicates the disposition of the queue. The value displayed is one of the following:

QMGR
The object was defined with QSGDISP(QMGR).
COPY
The object was defined with QSGDISP(COPY).
SHARED
The object was defined with QSGDISP(SHARED).

This parameter is valid on z/OS only.

For shared queues, if the CF structure used by the queue is unavailable or has failed, the status information might be unreliable.

You cannot use QSGDISP as a filter keyword.
QTIME
Interval, in microseconds, between messages being put on the queue and then being destructively read. The maximum displayable value is 999 999 999; if the interval exceeds this value, 999 999 999 is displayed.

The interval is measured from the time that the message is placed on the queue until it is retrieved by an application and, therefore, includes any interval caused by a delay in committing by the putting application.
Two values are displayed:

A value based on recent activity over a short period of time.
A value based on activity over a longer period of time.

These values depend on the configuration and behavior of your system, as well as the levels of activity within it, and serve as an indicator that your system is performing normally. A significant variation in these values may indicate a problem with your system. For queues with QSGDISP(SHARED), the values shown are for measurements collected on this queue manager only.

This parameter is also displayed when you specify the MONITOR parameter.

A value is only displayed for this parameter if MONQ is set to a value other than OFF for this queue.
UNCOM
Indicates whether there are any uncommitted changes (puts and gets) pending for the queue. The value displayed is one of the following:

YES

On z/OS, there are one or more uncommitted changes pending.
NO
There are no uncommitted changes pending.
n
On platforms other than z/OS, an integer value indicating how many uncommitted changes are pending.

For shared queues, the value returned applies only to the queue manager generating the reply. The value does not apply to all the queue managers in the queue-sharing group.

Removing a cluster queue from a queue manager - Middleware News

2011-12-09T09:11:00.001-08:00

Removing a cluster queue from a queue manager - Middleware News

Note: For changes to a cluster to be propagated throughout the cluster, at least one full repository must always be available. Ensure that your repositories are available before starting this task.
Scenario:

The INVENTORY cluster has been set up as described in Task 3: Adding a new queue manager that hosts a queue. It contains four queue managers. LONDON and NEWYORK both hold full repositories. PARIS and TORONTO hold partial repositories. The inventory application runs on the systems in New York and Toronto and is driven by the arrival of messages on the INVENTQ queue.
Because of reduced workload, you no longer want to run the inventory application in Toronto. You want to disable the INVENTQ queue hosted by the queue manager TORONTO, and have TORONTO feed messages to the INVENTQ queue in NEWYORK.
Network connectivity exists between all four systems.
The network protocol is TCP.

Procedure

Follow these steps to move a full repository to another queue manager.
1. Indicate that the queue is no longer available
To remove a queue from a cluster, remove the cluster name from the local queue definition. Do this from queue manager TORONTO, using the ALTER QLOCAL command and specifying a blank cluster name, like this:

ALTER QLOCAL(INVENTQ) CLUSTER(' ')

2. Check that the queue is no longer available
On a full repository queue manager, either LONDON or NEWYORK , check that the queue is no longer hosted by queue manager TORONTO by issuing the following command:

DIS QCLUSTER (INVENTQ)

You should see only the queue hosted by NEWYORK.
3. Disable the queue
Disable the INVENTQ queue at TORONTO so that no further messages can be written to it:

ALTER QLOCAL(INVENTQ) PUT(DISABLED)

Now messages in transit to this queue using MQOO_BIND_ON_OPEN will go to the dead-letter queue. You need to stop all applications from putting messages explicitly to the queue on this queue manager.
4. Monitor the queue until it is empty

Monitor the queue using the DISPLAY QUEUE command and specifying the attributes IPPROCS, OPPROCS, and CURDEPTH, or use the WRKMQMQSTS command on i5/OS®. When the number of input processes, the number of output processes, and the current depth of the queue are all zero, you can be sure that the queue is empty.
5. Monitor the channel to ensure there are no in-doubt messages
To be sure that there are no in-doubt messages on the channel TO.TORONTO, monitor the cluster-sender channel called TO.TORONTO on each of the other queue managers. To do this, issue the DISPLAY CHSTATUS command specifying the INDOUBT parameter from each queue manager:

DISPLAY CHSTATUS(TO.TORONTO) INDOUBT

If there are any in-doubt messages, you must resolve them before proceeding. For example, you might try issuing the RESOLVE channel command or stopping and restarting the channel.
6. Delete the local queue
When you are satisfied that there are no more messages to be delivered to the inventory application at TORONTO, you can delete the queue:

DELETE QLOCAL(INVENTQ)

The cluster set up by this task is similar to that set up by the previous task, except that the INVENTQ queue is no longer available at queue manager TORONTO.

When you take the queue out of service (step 1), the TORONTO queue manager sends a message to the two full repository queue managers notifying them of the change in status. The full repository queue managers pass on this information to other queue managers in the cluster that have requested updates to information concerning the INVENTQ.

Now when a queue manager has a message to put on the INVENTQ queue, its updated partial repository indicates that the INVENTQ queue is available only at the NEWYORK queue manager, and so the message is sent there.

You can now remove the inventory application from the system in Toronto, to avoid duplication and save space on the system.

In this task description there is only one queue to remove and only one cluster to remove it from.
Suppose that there were many queues referring to a namelist containing many cluster names. For example, the TORONTO queue manager might host not only the INVENTQ, but also the PAYROLLQ, SALESQ, and PURCHASESQ. TORONTO makes these queues available in all the appropriate clusters, INVENTORY, PAYROLL, SALES, and PURCHASES. To do this, TORONTO defines a namelist of the cluster names:

DEFINE NAMELIST(TOROLIST)
DESCR('List of clusters TORONTO is in')
NAMES(INVENTORY, PAYROLL, SALES, PURCHASES)

and specifies this namelist on each queue definition, like this:

DEFINE QLOCAL(INVENTQ) CLUSNL(TOROLIST)
DEFINE QLOCAL(PAYROLLQ) CLUSNL(TOROLIST)
DEFINE QLOCAL(SALESQ) CLUSNL(TOROLIST)
DEFINE QLOCAL(PURCHASESQ) CLUSNL(TOROLIST)

Now suppose that you want to remove all those queues from the SALES cluster, because the SALES operation is to be taken over by the PURCHASES operation. All you need to do is alter the TOROLIST namelist to remove the name of the SALES cluster from it.
If you want to remove a single queue from one of the clusters in the namelist, create a new namelist, containing the remaining list of cluster names, and then alter the queue definition to use the new namelist. To remove the PAYROLLQ from the INVENTORY cluster:

Create a new namelist:

DEFINE NAMELIST(TOROSHORTLIST)
DESCR('List of clusters TORONTO is in other than INVENTORY')
NAMES(PAYROLL, SALES, PURCHASES)

Alter the PAYROLLQ queue definition:

ALTER QLOCAL(PAYROLLQ) CLUSNL(TOROSHORTLIST)

Messages do not appear when expected - Middleware News

2011-12-09T09:10:00.000-08:00

Messages do not appear when expected - Middleware News

If messages do not appear on the queue when you are expecting them, check for the following:

Has the message been put onto the queue successfully?
Did WebSphere® MQ issue a return and reason code for the MQPUT, for example:

Has the queue been defined correctly, for example is MAXMSGL large enough? (reason code 2030).
Can applications put messages on to the queue (is the queue enabled for MQPUT calls)? (reason code 2051).
Is the queue already full? This could mean that an application could not put the required message on to the queue (reason code 2053).

Is the queue a shared queue?

Have Coupling Facility structures been defined successfully in the CFRM policy data set? Messages held on shared queues are stored inside a Coupling Facility.
Have you activated the CFRM policy?

Is the queue a cluster queue?
If it is, there might be multiple instances of the queue on different queue managers. This means the messages could be on a different queue manager.

Did you want the message to go to a cluster queue?
Is your application designed to work with cluster queues?
Did the message get put to a different instance of the queue from that expected?

Check any cluster-workload exit programs to see that they are processing messages as intended.
Do your gets fail?

Does the application need to take a syncpoint?

If messages are being put or got within syncpoint, they are not available to other tasks until the unit of recovery has been committed.
Is the time interval on the MQGET long enough?

If you are using distributed processing, you should allow for reasonable network delays, or problems at the remote end.
Was the message you are expecting defined as persistent?

If not, and the queue manager has been restarted, the message will have been deleted. Shared queues are an exception because nonpersistent messages survive a queue manager restart.
Are you waiting for a specific message that is identified by a message or correlation identifier (MsgId or CorrelId)?

Check that you are waiting for a message with the correct MsgId or CorrelId. A successful MQGET call sets both these values to that of the message got, so you might need to reset these values to get another message successfully.

Also check if you can get other messages from the queue.
Can other applications get messages from the queue?

If so, has another application already retrieved the message?

If the queue is a shared queue, check that applications on other queue managers are not getting the messages.

If you cannot find anything wrong with the queue, and the queue manager itself is running, make the following checks on the process that you expected to put the message on to the queue:

Did the application get started?

If it should have been triggered, check that the correct trigger options were specified.
Is a trigger monitor running?
Was the trigger process defined correctly (both to WebSphere MQ for z/OS® and CICS® or IMS™)?
Did it complete correctly?

Look for evidence of an abend, (for example, in the CICS log).
Did the application commit its changes, or were they backed out?

Look for messages in the CICS log indicating this.

If multiple transactions are serving the queue, they might occasionally conflict with one another. For example, one transaction might issue an MQGET call with a buffer length of zero to find out the length of the message, and then issue a specific MQGET call specifying the MsgId of that message. However, while this is happening, another transaction might have issued a successful MQGET call for that message, so the first application will receive a completion code of MQRC_NO_MSG_AVAILABLE. Applications that are expected to run in a multi-server environment must be designed to cope with this situation.

Have any of your systems suffered an outage? For example, if the message you were expecting should have been put on to the queue by a CICS application, and the CICS system went down, the message might be in doubt. This means that the queue manager does not know whether the message should be committed or backed out, and so has locked it until this is resolved when resynchronization takes place.
Note: The message is deleted after resynchronization if CICS decides to back it out.

Also consider that the message could have been received, but that your application failed to process it in some way. For example, did an error in the expected format of the message cause your program to reject it? If this is the case, refer to Messages contain unexpected or corrupted information.

Problems with missing messages when using distributed queuing
Problems with getting messages when using message grouping
Finding messages sent to a cluster queue
Finding messages sent to the WebSphere MQ-IMS bridge

Problems with missing messages when using distributed queuing - Middleware News

2011-12-09T09:08:00.000-08:00

Problems with missing messages when using distributed queuing - Middleware News

If your application uses distributed queuing, consider the following points:

Has distributed queuing been correctly installed on both the sending and receiving systems?
Ensure that the instructions about installing the distributed queue management facility in the WebSphere MQ for z/OS® System Setup Guide have been followed correctly.
Are the links available between the two systems?
Check that both systems are available, and connected to WebSphere® MQ for z/OS. Check that the LU 6.2 or TCP/IP connection between the two systems is active or check the connection definitions on any other systems that you are communicating with.

Start of changeSee Monitoring WebSphere MQ for more information about trace-route messaging in a network.End of change
Is the channel running?

Issue the following command for the transmission queue:

DISPLAY QUEUE (qname) IPPROCS

If the value for IPPROCS is 0, this means that the channel serving this transmission queue is not running.
Issue the following command for the channel:

DISPLAY CHSTATUS (channel-name) STATUS MSGS

Use the output produced by this command to check that the channel is serving the correct transmission queue and that it is connected to the correct target machine and port. You can determine whether the channel is running from the STATUS field. You can also see if any messages have been sent on the channel by examining the MSGS field.

If the channel is in RETRYING state, this is probably caused by a problem at the other end. Check that the channel initiator and listener have been started, and that the channel has not been stopped. If somebody has stopped the channel, you need to start it manually.

Is triggering set on in the sending system?
Check that the channel initiator is running.
Does the transmission queue have triggering set on?
If a channel is stopped under specific circumstances, triggering can be set off for the transmission queue.
Is the message you are waiting for a reply message from a remote system?
Check the definitions of the remote system, as described above, and check that triggering is activated in the remote system. Also check that the LU 6.2 connection between the two systems is not single session (if it is, you cannot receive reply messages).

Check that the queue on the remote queue manager exists, is not full, and accepts the message length. If any of these criteria are not fulfilled, the remote queue manager tries to put the message on the dead-letter queue. If the message length is longer than the maximum length that the channel will allow, the sending queue manager tries to put the message on its dead-letter queue.
Is the queue already full?

This could mean that an application could not put the required message on to the queue. If this is so, check if the message has been put on to the dead-letter queue.

The dead-letter queue message header (dead-letter header structure) contains a reason or feedback code explaining why the message could not be put on to the target queue. See the WebSphere MQ Application Programming Reference manual for information about the dead-letter header structure.
Is there a mismatch between the sending and receiving queue managers?
For example, the message length could be longer than the receiving queue manager can handle. Check the console log for error messages.
Are the channel definitions of the sending and receiving channels compatible?
For example, a mismatch in the wrap value of the sequence number will stop the channel. See the WebSphere MQ Intercommunication manual for more information about distributed queuing.
Has data conversion been performed correctly?
If a message has come from a different queue manager, are the CCSIDs and encoding the same, or does data conversion need to be performed.
Has your channel been defined for fast delivery of nonpersistent messages?
If your channel has been defined with the NPMSPEED attribute set to FAST (the default), and the channel has stopped for some reason and then been restarted, nonpersistent messages might have been lost. See the WebSphere MQ Intercommunication manual for more information about fast messages.
Is a channel exit causing the messages to be processed in an unexpected way?
For example, a security exit might prevent a channel from starting, or an ExitResponse of MQXCC_CLOSE_CHANNEL might terminate a channel.

Moving a non-shared queue - Middleware News

2011-12-09T09:06:00.000-08:00

Moving a non-shared queue - Middleware News

To move queues and their messages from one page set to another, use the MQSC MOVE QLOCAL command (described in WebSphere® MQ Script (MQSC) Command Reference). When you have identified the queue or queues that you want to move to a new page set, follow this procedure for each of these queues:

Ensure that the queue you want to move is not in use by any applications (that is, IPPROCS and OPPROCS values from the DISPLAY QSTATUS command are zero) and that it has no uncommitted messages (the UNCOM value from the DISPLAY QSTATUS command is NO).
Note: The only way to ensure that this state continues is to change your security settings temporarily. If you cannot do this, later stages in this procedure might fail if applications start to use the queue despite precautionary steps such as setting PUT(DISABLED). However, messages can never be lost by this procedure.
Prevent applications from putting messages on the queue being moved by altering the queue definition to disable MQPUTs. Change the queue definition to PUT(DISABLED).
Define a temporary queue with the same attributes as the queue that is being moved, using the command:

DEFINE QL(TEMP_QUEUE) LIKE(QUEUE_TO_MOVE) PUT(ENABLED) GET(ENABLED)

Note: If this temporary queue already exists from a previous run, delete it before doing the define.
Move the messages to the temporary queue using the following command:

MOVE QLOCAL(QUEUE_TO_MOVE) TOQLOCAL(TEMP_QUEUE)

Delete the queue you are moving, using the command:

DELETE QLOCAL(QUEUE_TO_MOVE)

Define a new storage class that maps to the required page set, for example:

DEFINE STGCLASS(NEW) PSID(nn)

Add the new storage class definition to the CSQINP2 data sets ready for the next queue manager restart.
Redefine the queue that you are moving, by changing the storage class attribute:

DEFINE QL(QUEUE_TO_MOVE) LIKE(TEMP_QUEUE) STGCLASS(NEW)

When the queue is redefined, it is based on the temporary queue created in step 3.
Move the messages back to the new queue, using the command:

MOVE QLOCAL(TEMP) TOQLOCAL(QUEUE_TO_MOVE)

The queue created in step 3 is no longer required. Use the following command to delete it:

DELETE QL(TEMP_QUEUE)

If the queue being moved was defined in the CSQINP2 data sets, change the STGCLASS attribute of the appropriate DEFINE QLOCAL command in the CSQINP2 data sets. Add the REPLACE keyword so that the existing queue definition is replaced.

Figure 1 shows an extract from a load balancing job.
Figure 1. Extract from a load balancing job for a page set

//UTILITY EXEC PGM=CSQUTIL,PARM=('CSQ1')
//STEPLIB DD DSN=thlqual.SCSQANLE,DISP=SHR
// DD DSN=thlqual.SCSQAUTH,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
COMMAND DDNAME(MOVEQ)
/*
//MOVEQ DD *
ALTER QL(QUEUE_TO_MOVE) PUT(DISABLED)
DELETE QL(TEMP_QUEUE) PURGE
DEFINE QL(TEMP_QUEUE) LIKE(QUEUE_TO_MOVE) PUT(ENABLED) GET(ENABLED)
MOVE QLOCAL(QUEUE_TO_MOVE) TOQLOCAL(TEMP_QUEUE)
DELETE QL(QUEUE_TO_MOVE)
DEFINE STGCLASS(NEW) PSID(2)
DEFINE QL(QUEUE_TO_MOVE) LIKE(TEMP_QUEUE) STGCLASS(NEW)
MOVE QLOCAL(TEMP_QUEUE) TOQLOCAL(QUEUE_TO_MOVE)
DELETE QL(TEMP_QUEUE)

Are some of your queues failing? - middleware News

2011-12-09T09:04:00.000-08:00

Are some of your queues failing? - middleware News

If you suspect that the problem occurs with only a subset of queues, check the local queues that you think are having problems:

Display the information about each queue. You can use the MQSC command DISPLAY QUEUE to display the information.
Use the data displayed to do the following checks:
If CURDEPTH is at MAXDEPTH, the queue is not being processed. Check that all applications are running normally.
If CURDEPTH is not at MAXDEPTH, check the following queue attributes to ensure that they are correct:
If triggering is being used:
Is the trigger monitor running?
Is the trigger depth too great? That is, does it generate a trigger event often enough?
Is the process name correct?
Is the process available and operational?
Can the queue be shared? If not, another application could already have it open for input.
Is the queue enabled appropriately for GET and PUT?
If there are no application processes getting messages from the queue, determine why this is so. It could be because the applications need to be started, a connection has been disrupted, or the MQOPEN call has failed for some reason.

Check the queue attributes IPPROCS and OPPROCS. These attributes indicate whether the queue has been opened for input and output. If a value is zero, it indicates that no operations of that type can occur. The values might have changed; the queue might have been open but is now closed.

You need to check the status at the time you expect to put or get a message.

If you are unable to solve the problem, contact your IBM® Support Center for help.

Determining whether your application has the queue open - Middleware News

2011-12-09T09:02:00.000-08:00

Determining whether your application has the queue open - Middleware News

If you have a problem with a queue, check whether your application has the queue open
About this task
Perform the following steps to determine whether your application has the queue open:
Procedure

Ensure that the application that is running against the queue is the application that you expect. Issue the following command for the queue in question:

DISPLAY QSTATUS(Q1) TYPE(HANDLE) ALL

In the output, look at the APPLTAG field, and check that the name of your application is shown. If the name of your application is not shown, or if there is no output at all, start your application.
If the queue is a transmission queue, look in the output at the CHANNEL field. If the channel name is not shown in the CHANNEL field, determine whether the channel is running.
Ensure that the application that is running against the queue has the queue open for input. Issue the following command:

DISPLAY QSTATUS(Q1) TYPE(QUEUE) ALL

In the output, look at the IPPROCS field to see if any application has the queue open for input. If the value is 0 and this is a user application queue, make sure that the application opens the queue for input to get the messages off the queue.

IPPROCS or OPPROCS greater than 0 in a queue prevents normal termination of queue manager by "endmqm QmgrName" - Middleware News

2011-12-09T08:59:00.000-08:00

IPPROCS or OPPROCS greater than 0 in a queue prevents normal termination of queue manager by "endmqm QmgrName" - Middleware News

Question

You notice that when the queue attributes of IPPROCS or OPPROCS are greater than 0, and try to end the queue manager by issuing "endmqm QmgrName", then the queue manager goes into "quiescing" but it does not fully terminate.

Is there a way to speed up the shutdown of the queue manager?

Answer

If "endmqm QMgrName" does not effectively end the queue manager, you can try to speed up the shutdown process by adding the flag -i such as:

endmqm -i QMgrName

Background:

The following page from the WebSphere MQ V7 Information Center has more information about the IPPROCS and OPPROCS attributes for a queue:

http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=/com.ibm.mq.explorer.doc/e_status_queue.htm

Queue status attributes:

Attribute: Open input count
Meaning: This is the number of applications that are currently connected to the queue to get messages from the queue.
MQSC parameter: IPPROCS

Attribute: Open output count
Meaning: This is the number of applications that are currently connected to the queue to put messages on the queue.
MQSC parameter: OPPROCS

If "endmqm QMgrName" does not effectively end the queue manager, you can try to speed up the shutdown process by adding the flag -i such as:
endmqm -i QMgrName

For more details, see the MQ V7 Information Center:
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=/com.ibm.mq.amqzag.doc/fa15800_.htm
endmqm

The default (endmqm QMgrName) is to use "-c" as in: endmqm -c QMgrName

-c Controlled (or quiesced) shutdown :
This is the default. The queue manager stops, but only after all applications have disconnected. Any MQI calls currently being processed are completed. Control is returned to you immediately and you are not notified of when the queue manager has stopped. The effect on any client applications connected through a server-connection channel is equivalent to a STOP CHANNEL command issued in QUIESCE mode.
>> Note: If an application has opened a queue for put or for get, but still is connected, then this will prevent the queue manager from ending. It will remain in "quiescing".

-i Immediate shutdown:
The queue manager stops after it has completed all the MQI calls currently being processed. Any MQI requests issued after the command has been issued fail. Any incomplete units of work are rolled back when the queue manager is next started.
Control is returned after the queue manager has ended.
The effect on any client applications connected through a server-connection channel is equivalent to a STOP CHANNEL command issued in FORCE mode.
>> Note: If a client application has opened a queue and still is connected, such as the MQ Explorer, then this option will terminate the server-client connection, allowing the queue manager to terminate.

-p Preemptive shutdown:
WARNING: !!!! Use this type of shutdown only in exceptional circumstances. For example, when a queue manager does not stop as a result of a normal endmqm command. !!!

The queue manager might stop without waiting for applications to disconnect or for MQI calls to complete. This can give unpredictable results for WebSphere MQ applications.
The shutdown mode is set to immediate shutdown. If the queue manager has not stopped after a few seconds, the shutdown mode is escalated, and all remaining queue manager processes are stopped.
The effect on any client applications connected through a server-connection channel is equivalent to a STOP CHANNEL command issued in TERMINATE mode.

+++ Scenario

The impact that these attributes have whenever they have a value greater than Zero, when trying to terminate the queue manager is best described by a simple scenario, which is described in the rest of this technote.

A queue Q1 in the queue manager QM_VER has not been opened by any application. Thus, IPPROCS and OPPROCS are 0:
In one window enter:

$ runmqsc QM_VER
display qstatus(Q1)
2 : display qstatus(Q1)
AMQ8450: Display queue status details.
QUEUE(Q1) TYPE(QUEUE)
CURDEPTH(0) IPPROCS(0)
MSGAGE( ) OPPROCS(0)

In another window, the MQ sample command "amqsput" is issued to put a message:

$ amqsput Q1 QM_VER
Sample AMQSPUT0 start
target queue is Q1

Notice that the text of the message has not being entered yet. The application is just waiting for the user to enter the text. The application has already opened the queue and thus, the counter for OPPROCS has been incremented from 0 to 1:

$ runmqsc QM_VER
display qstatus(Q1)
3 : display qstatus(Q1)
AMQ8450: Display queue status details.
QUEUE(Q1) TYPE(QUEUE)
CURDEPTH(0) IPPROCS(0)
MSGAGE( ) OPPROCS(1)

In yet another window, the MQ sample command "amqsget" is issued to get a message:

$ amqsget Q1 QM_VER
Sample AMQSGET0 start

Notice that now the counter for IPPROCS has been incremented from 0 to 1, and that OPPROCS is still at 1 because amqsput is still connected:

$ runmqsc QM_VER
display qstatus(Q1)
4 : display qstatus(Q1)
AMQ8450: Display queue status details.
QUEUE(Q1) TYPE(QUEUE)
CURDEPTH(0) IPPROCS(1)
MSGAGE( ) OPPROCS(1)

But 30 seconds later, amqsget terminates because no messages arrived within 30 seconds, and now the IPPROCS counter decreased from 1 to 0. But amqsput is still connected, waiting for the user to enter a message and thus OPPROCS is still 1.

$ runmqsc QM_VER
display qstatus(Q1)
3 : display qstatus(Q1)
AMQ8450: Display queue status details.
QUEUE(Q1) TYPE(QUEUE)
CURDEPTH(0) IPPROCS(0)
MSGAGE( ) OPPROCS(1)

Let's assume that we wanted to terminate the queue manager, keeping in mind that amqsput is still running and connected to the queue (OPPROCS is still 1):

$ endmqm QM_VER
Quiesce request accepted. The queue manager will stop when all outstanding work
is complete.

Notice that we cannot make new connections, not even running runmqsc:

$ runmqsc QM_VER
AMQ8156: WebSphere MQ queue manager quiescing.

$ amqsget Q1 QM_VER
Sample AMQSGET0 start
MQCONN ended with reason code 2161

$ mqrc 2161
2161 0x00000871 MQRC_Q_MGR_QUIESCING

The monitoring of the MQ processes for this queue manager do not show any changes and the processes are still running.

$ ps -ef | grep -i QM_VER
mqm 1869 1 0 13:28 ? 00:00:00 amqzxma0 -m QM_VER
mqm 1874 1869 0 13:28 ? 00:00:00 /opt/mqm/bin/amqzfuma -m QM_VER
mqm 1878 1869 0 13:28 ? 00:00:00 amqzmuc0 -m QM_VER
mqm 1884 1869 0 13:28 ? 00:00:00 amqzmur0 -m QM_VER
mqm 1885 1869 0 13:28 ? 00:00:00 amqzmuf0 -m QM_VER
mqm 1888 1869 0 13:28 ? 00:00:00 /opt/mqm/bin/amqrrmfa -m QM_VER -t2332800 -s2592000 -p2592000 -g5184000 -c3600
mqm 1889 1869 0 13:28 ? 00:00:00 /opt/mqm/bin/amqzdmaa -m QM_VER
mqm 1914 1869 0 13:28 ? 00:00:00 /opt/mqm/bin/amqzmgr0 -m QM_VER
mqm 1928 1869 0 13:28 ? 00:00:00 amqzlaa0 -mQM_VER -fip0
rivera 2484 19416 0 13:28 pts/3 00:00:00 amqsput Q1 QM_VER
rivera 3605 19796 0 13:30 pts/4 00:00:00 grep -i QM_VER

Because an amqsput connection is preventing the queue manager from terminating, only until amqsput terminates, the queue manager will end.

One easy solution is to manually terminate amqsput, which will disconnect from the queue (OPPROCS will be 0) and the queue manager will terminate.

However, sometimes, it is not easy to identify which is the particular application that is preventing the shutdown, then it is OK to escalate the shutdown of the queue manager by issuing "-i" (for immediate).
Thus, in the same window or in another window, issue the following command, even though an "endmqm QMgrName" was issued already (but it is quiescing).

$ endmqm -i QM_VER
WebSphere MQ queue manager 'QM_VER' ending.
WebSphere MQ queue manager 'QM_VER' ended.

The "-i" flag will wait for in transit activities to terminate, but because there are none at this time, then it will terminate the connection of amqsput and then continue successfully to terminate the queue manager.

Notice that the pending amqsput is terminated with rc 2009:
.
$ amqsput Q1 QM_VER
Sample AMQSPUT0 start
target queue is Q1
MQCLOSE ended with reason code 2009
Sample AMQSPUT0 end
.
Notice that the rc 2009 means:
$ mqrc 2009
2009 0x000007d9 MQRC_CONNECTION_BROKEN

IBM WebSphere DataPower SOA Appliances - Middleware News

2011-11-23T06:40:00.000-08:00

IBM WebSphere DataPower SOA Appliances - Middleware News

IBM WebSphere Enterprise Service Bus 6.2

WebSphere MQ for Windows v6.0 Explorer Trace - Middleware News

2011-10-27T06:37:00.000-07:00

WebSphere MQ for Windows v6.0 Explorer Trace - Middleware News

Follow the instructions listed below to run trace for the WebSphere MQ for Windows v6.0 Explorer using the MQ Java API.

Modify the files runmqcfg.cmd and runmqcfg_rcp.cmd in the directory C:\Program Files\IBM\WebSphere MQ\bin

Add the following line, which specifies the properties file in C:\TEMP\internal.properties

set AMQ_EXPLORER=%AMQ_EXPLORER% "-Dcom.ibm.mq.commonservices=C:\TEMP\internal.properties"

Note: The command must be typed on ONE LINE in the runmqcfg.cmd and runmqcfg_rcp.cmd files and BEFORE the statement:
start "WebSphere MQ Explorer" %AMQ_EXPLORER%

Create a file internal.properties in the C:\TEMP directory as with the following text:

Diagnostics.MQ=enabled Diagnostics.Java=explorer,wmqjavaclasses,all #Diagnostics.Java=explorer Diagnostics.Java.Trace.Detail=high Diagnostics.Java.Trace.Destination.File=enabled Diagnostics.Java.Trace.Destination.Console=disabled Diagnostics.Java.Trace.Destination.Pathname=C:\\temp\\trace Diagnostics.Java.FFDC.Destination.Pathname=C:\\temp\\FFDC Diagnostics.Java.Errors.Destination.Filename=C:\\temp\\errors\\AMQJERR.LOG

You may also need to create the following directories:

C:\temp\FFDC C:\temp\trace C:\temp\errors

In the C:\temp\trace directory you will find files with the format AMQyyyymmddhhmmsssss.*.TRC which contain the MQ Java trace output.

WebSphere MQ for Windows trace - Middleware News

2011-10-27T06:36:00.000-07:00

WebSphere MQ for Windows trace - Middleware News

Follow the instructions listed below to start, stop and format WebSphere MQ for Windows trace.

Start trace:

normal :

strmqtrc

Or start a high detail trace:

strmqtrc -t all -t detail

Or start a high detail wrapping trace and limit the file size to 5MB :

strmqtrc -l 5 -t all -t detail

End trace:

endmqtrc

Format trace: No formatting is required

The trace records are written to the following directory where is the directory where WebSphere MQ was installed.
MQ 5.3: \errors
MQ 6: \trace

On Windows, the trace files are readable without formatting. However, they are still called AMQppppp.TRC (where ppppp is the process identifier or pid which created the file) rather than AMQppppp.FMT.

WebSphere MQ for HP-UX - Middleware News

2011-10-27T06:34:00.001-07:00

WebSphere MQ for HP-UX - Middleware News

Follow the instructions listed below to start, stop and format WebSphere MQ for HP-UX trace. Trace files are written to the directory /var/mqm/trace/, so delete or relocate old trace files before beginning a new trace.

Start trace

for every WebSphere MQ process:

strmqtrc -e

Or start trace only for one queue manager:

strmqtrc -m MY.QMGR

Or start a high detail trace for one queue manager:

strmqtrc -t all -t detail -m MY.QMGR

Or start a high detail wrapping trace and limit the file size to 5 MB :

strmqtrc -l 5 -t all -t detail -m MY.QMGR

End all tracing:

endmqtrc -a

Format the trace files:

dspmqtrc *.TRC

Or format wrapping trace files:

dspmqtrc *.TRC *.TRS

The trace formatter program converts binary files named AMQppppp.TRC (where ppppp is the process identifier or pid which created the file) into readable files named AMQppppp.FMT.

If you used a wrapping trace, then each time a .TRC reaches the size limit MQ renames it to a .TRS extension and starts a new .TRC file. The trace formatter can convert both files to a single formatted file, but only if you format the .TRC and .TRS files at the same time, as shown above.

WebSphere MQ for AIX Trace V6.0 - Middleware News

2011-10-27T06:31:00.001-07:00

WebSphere MQ for AIX Trace V6.0 - Middleware News

Follow the instructions listed below to start, stop and format WebSphere MQ for AIX trace. Trace files are written to the directory /var/mqm/trace, so delete or relocate old trace files before beginning a new trace.

Start trace

for every WebSphere MQ process:

strmqtrc -e

Or start trace only for one queue manager:

strmqtrc -m MY.QMGR

Or start a high detail trace for one queue manager:

strmqtrc -t all -t detail -m MY.QMGR

Or start a high detail wrapping trace and limit the file size to 5MB :

strmqtrc -l 5 -t all -t detail -m MY.QMGR

End all tracing:

endmqtrc -a

Format the trace files:

dspmqtrc *.TRC

Or format wrapping trace files:

dspmqtrc *.TRC *.TRS

The trace formatter program converts binary files named AMQppppp.TRC (where ppppp is the process identifier or pid which created the file) into readable files named AMQppppp.FMT.

If you used a wrapping trace, then each time a .TRC reaches the size limit MQ renames it to a .TRS extension and starts a new .TRC file. The trace formatter can convert both files to a single formatted file, but only if you format the .TRC and .TRS files at the same time, as shown above.

Dead Letter Queue - Dead Letter Messages - Middleware News

2011-09-30T20:47:00.000-07:00

Dead Letter Queue - Dead Letter Messages - Middleware News

Dead Letter Queue

- When messages can not be delivered to the intended queue, the messages may be delivered to a Dead Letter Queue (DLQ) if the queue manager has one defined.
- By default a queue manager does not have a DLQ but you should define one for every queue manager.

Dead Letter Messages

Messages can be placed on the DLQ by the queue manager, the channels (MCA) or by applications
When the messages are put onto DLQ, they should have a Dead Letter Header (DLH). DLH will be generated by Queue manager and MCA.
If application are putting the messages onto DLQ, applications must create the DLH.

MQRC and MQFB

Reason code in the MQDLH will be a value from either the MQRC reason codes or MQFB feedback codes

Example MQDLH
MQOPEN - 'SYSTEM.DEAD.LETTER.QUEUE'
MQGET of message number 1
****Message descriptor****
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 273 CodedCharSetId : 819
Format : 'MQDEAD ‘
Priority : 0 Persistence : 1
MsgId : X'414D5120626F776D616E676120202020524E244220001501'
CorrelId : X'000000000000000000000000000000000000000000000000'
BackoutCount : 0
ReplyToQ : ' '
ReplyToQMgr : 'QM1_TEST ‘
** Identity Context
UserIdentifier : 'mqm '
AccountingToken : X'16010515000000030D6D3BAB5CDD6E5F7E9E53EB03000000000000000000000B'
ApplIdentityData : ' '
** Origin Context
PutApplType : '11'
PutApplName : ‘WebSphere MQ\bin\amqsputc.exe'
PutDate : '20091018'
PutTime : '12044424'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'
**** Message ****
length - 194 bytes
00000000: 444C 4820 0000 0001 0000 0805 5445 5354 'DLH ........TEST‘
00000010: 2020 2020 2020 2020 2020 2020 2020 2020 ' ‘
00000020: 2020 2020 2020 2020 2020 2020 2020 2020 ' ‘
00000030: 2020 2020 2020 2020 2020 2020 4741 4220 ' GAB ‘
00000040: 2020 2020 2020 2020 2020 2020 2020 2020 ' ‘
00000050: 2020 2020 2020 2020 2020 2020 2020 2020 ' ‘
00000060: 2020 2020 2020 2020 2020 2020 0000 0222 ' ..."‘
00000070: 0000 01B5 4D51 5354 5220 2020 0000 0006 '...µMQSTR ....‘
00000080: 616D 7172 6D70 7061 2020 2020 2020 2020 'amqrmppa ‘
00000090: 2020 2020 2020 2020 2020 2020 3230 3035 ' 2009‘
000000A0: 3033 3031 3132 3439 3531 3735 7465 7374 '030112495175test‘
000000B0: 206F 6620 4D65 7373 6167 6520 746F 2044 ' of Message to D‘
000000C0: 4C51 'LQ

DLQ Handler
Once a message arrives on the DLQ you can automate the handling of that message using the DLQ handler program. You can have the handler running and waiting for messages to arrive on the DLQ or you can set up the DLQ to trigger the start of the handler program

Starting the DLQ Handler
You can start the DLQ handler using the runmqdlq command.
Example: runmqdlq DLQ QMGR < rules.tbwhere DLQ = name of your dead letter qQMGR = queue manager name andrules.tb is a file with your rules tableRules TableIt Defines how the DLQ handler will process the messages on the DLQTwo types of entries in the rules table-Control Data-Rulesrunmqdlq can take rules table from command line or redirect from file.Sample ProgramWebsphere MQ supplies a sample program called amqsdlq which provides similar function as runmqdlq. This allows users to customize the way messages are handled from the DLQ, especially useful if you have applications placing messages directly onto DLQ.How to write Rules in rule table explainedRule table is looks something like: Pattern/Keyword Action. ( simillat to find a particular keyword and the do the action specified)Pattern Keywords – allow you to match only certain messages on the DLQEx: REASON – match only messages with a specified reason codeDESTQ – match only messages which were destined for a specified queueAction Keywords describe how a matching message is processedACTION(DISCARD|IGNORE|RETRY|FWD)FWDQ – name of queue where message is forwardedFWDQM – name of qmgr where message is forwardedHEADER(YES|NO) – do messages have DLH headerPUTAUT(DEF|CTX) – userid of runmqdlq program or userid from the MD of the message on the DLQRETRY – number of times to retry each matching ruleMore about Rule TableA rules table must contain at least one rule.Keywords can occur in any order.A keyword can be included only once in any rule.Keywords are not case-sensitive.A keyword and its parameter value must be separated from other keywords by at least one blank space or comma.There can be any number of blanks at the beginning or end of a rule, and between keywords, punctuation, and values.Each rule must begin on a new line.For reasons of portability, the significant length of a line must not be greater than 72 characters.Sample Rule Table**************************************************** An example rules table for the runmqdlq command ***************************************************** Control data entry* ------------------* If parameters are not supplied on the runmqdlq command use* SYSTEM.DEAD.LETTER.QUEUE as the input queue, use QM1_TEST as the* queue manager and set retry interval to 20 secondsinputq('SYSTEM.DEAD.LETTER.QUEUE') inputqm('QM1_TEST') retryint(20)** Rules entries* -----* Include a rule with ACTION (RETRY) first to try to deliver the* message to the intended destination. If a message is placed on the* DLQ because its destination queue is full, attempt to forward the* message to its destination queue. Make 5 attempts at approximately* 20 second intervals (the default value for RETRYINT). Also include* the "+" just to show how to wrap a command over to the next line.REASON(MQRC_Q_FULL) ACTION(RETRY) RETRY(5)* If a message is placed on the DLQ due to put inhibited, attempt to* forward the message to its destination queue. Make 5 attempts at* approximately 20 second intervals (the default value for RETRYINT).REASON(MQRC_PUT_INHIBITED) ACTION(RETRY) RETRY(5)* Include a rule to handle messages which do not match any of the* patterns specified above. Send the messages to another queue named* DEADQ where they can be handled later.ACTION(FWD) FWDQ('DEADQ')Runmqdlq examplesIf you use the DLQ handler without redirecting stdin from a file (the rules table), the DLQ handler reads its input from the keyboard.In WebSphere MQ for AIX, Solaris, HP-UX, and Linux, the DLQ handler does not start to process the named queue until it receives an end_of_file (Ctrl+D) character.In WebSphere MQ for Windows it does not start to process the named queue until you press the following sequence of keys: Ctrl+Z, Enter, Ctrl+Z, EnterC:\>runmqdlq SYSTEM.DEAD.LETTER.QUEUE QM1_TEST
WAIT(YES) RETRYINT(20)
REASON(MQRC_Q_FULL) ACTION(RETRY) +
RETRY(5)
REASON(MQRC_PUT_INHIBITED) ACTION(RETRY) RETRY(5)
REASON(*) ACTION(FWD) FWDQ('DEADQ')
^Z
^Z
2005-04-08 02.20.09 AMQ8708: Dead-letter queue handler started to process
INPUTQ(SYSTEM.DEAD.LETTER.QUEUE)

Migration to WebSphere MQ V7.0.1 and WebSphere Message Broker V7.0 - Middleware News

2011-09-30T20:39:00.000-07:00

Migration to WebSphere MQ V7.0.1 and WebSphere Message Broker V7.0 - Middleware News

Wmq wmb dist migration v1 030310

View more documents from karthickmsit.

Multi instance Queue Managers - Middleware News

2011-09-30T20:23:00.000-07:00

Multi instance Queue Managers - Middleware News

The concept of these multi-instance queue managers is to share the queue manager data in a high available storage place (line SAN), which should be accessible by more than 1 queue manager. For example, we have QM1 and QM2 on different machine. For both these queue managers we keep the logs and QM data in a shared location /shared/QMdata. Now if you start the QM1 first, then QM2 becomes passive. When QM1 is not operational or crashed then QM2 will take over the proceedings.

When you intend to use a queue manager as a multi-instance queue manager, create a single queue manager on one of the servers using the crtmqm command, placing its queue manager data and logs in shared network storage. On the other server, rather than create the queue manager again, use the addmqinf command to create a reference to the queue manager data and logs on the network storage.

To create and use this multi-instance queue managers, we need:

# Client and channel reconnection to transfer WebSphere MQ connections to the computer that takes over running the active queue manager instance.
# A high performance shared network file system that manages locks correctly and provides protection against media and file server failure.
# Resilient networks and power supplies to eliminate single points of failure in the basic infrastructure.
# Applications that tolerate failover. In particular you need to pay close attention to the behavior of transactional applications, and to applications that browse WebSphere MQ queues.
# Monitoring and management of the active and standby instances to ensure that they are running, and to restart active instances that have failed.

How to create the multi-instance Queue Manager?

Note: mqm user and mqm group should have required access permissions to the shared data file system.
the mqm user and group should be available across all the machines which has the QMs and they UID/GID should be same in Linux.

Steps:

I’m assuming that you already have MQ installed on server1 and server2.
Aslo assuming that, you have a NFS/SAN share with name /MQHA with full access to mqm user on both machines. [otherwise, contact your Linux admin to set this]

On Server1, Which will host QM1:
1. Create the shared directory which holds the logs and QM data on the shared network/NFS (like MQHA)
2. Now verify that locking to ensure that multi-instance queue mangers are supported on both machines.
# Run amqmfsck, without any options, on each system to check basic locking
# Run amqmfsck on both WebSphere MQ systems simultaneously, using the -c option, to test writing to the directory concurrently.
# Run amqmfsck on both WebSphere MQ systems at the same time, using the -w option, to test waiting for and releasing a lock on the directory concurrently.
3. check the UID/GID of mqm user
4. Create the logs and data directories in the shared file system
1. mkdir /MQHA
2. mkdir /MQHA/logs
3. mkdir /MQHA/qmgrs
5. Create the queue manager
crtmqm -ld /MQHA/logs -md /MQHA/qmgrs -q QM1
6. Copy the queue manager configuration details from Server 1
dspmqinf -o command QM1
and copy the result to the clip board,
addmqinf -s QueueManager
-v Name=QM1
-v Directory=QM1
-v Prefix=/var/mqm
-v DataPath=/MQHA/qmgrs/QM1

On server2. which will host QM2:

1. Verify the access to shared directory (MQHA)
2. Verify the locking to ensure that multi-instance queue managers are supported [see step2, in Machine1/QM1]
3. Check the GID and UID of mqm and ensure that they are same as Machine1
4. Now, paste the QM configuration information which you got in Step6 of QM1
addmqinf -s QueueManager
-v Name=QM1
-v Directory=QM1
-v Prefix=/var/mqm
-v DataPath=/MQHA/qmgrs/QM1

Start the queue manager instances, in either order, with the -x parameter:

strmqm -x QM1
If you start QM1 first, QM1 will be active and QM2 is passive and vise versa if you start QM2 first.

Testing

Stop the active Queue Manager using, endmqm command with -s option. The client programs reconnect to the new queue manager instance and continue to work with the new instance after a slight delay.

Communicating with a Queue Manager outside Cluster - Middleware News

2011-09-30T20:17:00.000-07:00

Communicating with a Queue Manager outside Cluster - Middleware News

Assumptions:

1. You already have a Queue Manager cluster (named QMGRCLUS) setup with 2 Queue Managers with names QM1 and QM2 and all the requires channels are setup for communication between QM1 and QM2

2. You have QM3, which is outside the cluster

3. QM2 has a Queue [Q2] defined at cluster level.

In this tutorial, let us send message from QM3’s Q3 to QM2’s Q2 and in the reverse path.

In this case one of your Queue Managers should act as a gateway. Say for example, lets make QM1 as the gateway for cluster and QM3 is outside cluster.

Steps:

1. The queue manager outside the cluster must have a QREMOTE definition for each queue in the cluster that it wants to put messages to.

DEFINE QREMOTE(Q2) RNAME(Q2) RQMNAME(QM2) XMITQ(TQ1) [in this case Q2 is a cluster queue and i want to put message from QM3 -> QM2]
2. QM3 must have a SDR channel and TX queue to QM1 and QM1 should have corresponding RCVR channel

For replies:

3. The gateway (QM1) advertises a queue-manager alias for the queue manager outside the cluster. It advertises this alias to the whole cluster by adding the cluster attribute to its queue-manager alias definition.
DEFINE QREMOTE(QM3) RNAME(‘ ‘) RQMNAME(QM4) CLUSTER(QMGRCLUS)
4. QM1 must have a SDR channel and TX queue to QM4 and QM4 should have corresponding RCVR channel.

Observe the below diagram, to understand the setup

image

Now, you need to define the following, for communicating from QM3 to Cluster and Cluster to QM3.

on QM1:

DEFINE QL(TQ3) USAGE(XMITQ)
DEFINE LISTENER(QM1_LIST) TRPTYPE(TCP) PORT(1111)
DEFINE CHANNEL(TO.QM3) CHLTYPE(SDR) TRPTYPE(TCP) CONNAME(‘localhost(3333)’) XMITQ(TQ3)
DEFINE CHANNEL(TO.QM1) CHLTYPE(RCVR) TRPTYPE(TCP)CONNAME(‘localhost(1111)’)
DEFINE QREMOTE(QM3) RNAME(‘ ‘) RQMNAME(QM3) XMITQ(TQ3) CLUSTER(QMGRCLUS)

on QM2:

DEFINE QL(Q2) CLUSTER(QMGRCLUS)
DEFINE LISTENER(QM2_LIST) TRPTYPE(TCP) PORT(2222)

on QM3:

DEFINE QL(Q3)
DEFINE QL(TQ1) USAGE(XMITQ)
DEFINE LISTENER(QM3_LIST) TRPTYPE(TCP) PORT(3333)
DEFINE CHANNEL(TO.QM1) CHLTYPE(SDR) TRPTYPE(TCP) CONNAME(‘localhost(1111)’) XMITQ(TQ1)
DEFINE CHANNEL(TO.QM3) CHLTYPE(RCVR) TRPTYPE(TCP)CONNAME(‘localhost(3333)’)
DEFINE QREMOTE(Q2) RNAME(Q2) RQMNAME(QM2) XMITQ(TQ1)

Start all the listeners on QM1/2/3 and Ensure all channels are running. First test that you are able to communicate between QM1 and QM2.

Then, you should be able to put messages
QM3[Q3] –> QM2[Q2]
QM2[Q2] –> QM3[Q3]
Similarly, if you have any queue on QM1, create corresponding QREMOTE on QM3(which is outside).

MQ commands fail after install of V6.0 - Middleware News

2011-09-26T03:23:00.000-07:00

MQ commands fail after install of V6.0 - Middleware News

Problem(Abstract)

You install WebSphere MQ V6.0 and find that you are unable to run MQ commands such as: dspmqver, dspmq and so on. You receive an error like the following:

dspmq
exec(): 0509-036 Cannot load program dspmq because of the following errors:
0509-150 Dependent module /usr/lib/libmqmcs_r.a(shr.o) could not be loaded.
0509-103 The module has an invalid magic number.

Cause

The system picks 32 bit MQ libraries when It should select the 64 bit lib's.

The most likely cause is that the $LIBPATH or $LD_LIBRARY_PATH is pointing to the 32 bit MQ libraries when It should select the 64 bit lib's.
See Implications of a 64-bit queue manager in the Quick Beginnings Guide for your operating system.

Resolving the problem

Edit the LIBPATH or $LD_LIBRARY_PATH to remove the /usr/lib or /opt/lib.
or
Add /[usr|opt]/mqm/lib64 to the front of the $LIBPATH or $LD_LIBRARY_PATH

export LIBPATH=/usr/mqm/lib64:$LIBPATH to add on AIX system.

WebSphere MQ Bridge for http - Middleware News

2011-09-12T08:23:00.000-07:00

WebSphere MQ Bridge for http - Middleware News

IBM Sterling WebsphereMQ FTE 2-Minute Explainer - Middleware News

2011-09-12T08:21:00.000-07:00

IBM Sterling WebsphereMQ FTE 2-Minute Explainer - Middleware News

MQ FTE V7.0.2: The Enterprise File Bridge - Middleware News

WebSphere MQ File Transfer Edition - Middleware News

IBM WebSphere Commerce Demo - Middleware News

2011-09-12T08:09:00.001-07:00

IBM WebSphere Commerce Demo - Middleware News

Install WebSphere Portal 7 Trial [Part 1 of 4] - Middleware News

2011-09-12T08:03:00.000-07:00

Install WebSphere Portal 7 Trial [Part 1 of 4] - Middleware News

Cloud Computing - Overview - Middleware News

2011-08-19T21:58:00.001-07:00

Cloud Computing - Overview - Middleware News

Introduction to Web Services - Middleware News

2011-08-19T21:57:00.000-07:00

Introduction to Web Services - Middleware News

IBM WebSphere Message Broker V7.0 System Administration Workshop - Middleware News

2011-08-06T21:51:00.000-07:00

IBM WebSphere Message Broker V7.0 System Administration Workshop - Middleware News

Real time Monitoring of WebSphere Message Broker flows - Middleware News

2011-08-06T21:45:00.000-07:00

Real time Monitoring of WebSphere Message Broker flows - Middleware News

WebSphere(R) MQ File Transfer Edition V7.0 - File Transfer Demo - Middleware News

2011-07-19T08:40:00.000-07:00

WebSphere(R) MQ File Transfer Edition V7.0 - File Transfer Demo - Middleware News

Debugging XC130003 FDCs with MQS_ACTION_ON_EXCEPTION - Middleware News

2011-07-12T10:02:00.000-07:00

Debugging XC130003 FDCs with MQS_ACTION_ON_EXCEPTION - Middleware News

Problem(Abstract)

You have an application that fails with an FDC from the xehExceptionHandler component, this happens because it received a signal like SIGBUS or SIGSEGV. You want to know how to find the cause of the failure with the MQS_ACTION_ON_EXCEPTION environment variable.
Cause

The MQ xehExceptionHandler function catches synchronous terminating signals such as SIGBUS (bus error), SIGSEGV (segmentation fault), SIGILL (illegal instruction) and SIGFPE (floating point error). These signals indicate a serious fault, such as dereferencing a NULL pointer, which needs to be investigated by the program developer.
Resolving the problem

The WebSphere MQ Application Programming Guide describes how WebSphere MQ handles signals on UNIX systems. The MQS_ACTION_ON_EXCEPTION environment variable controls what the MQ signal handler will do when it is called. MQS_ACTION_ON_EXCEPTION must be assigned one of the following four values:

HANG
Hang the process if MQ caused the fault

HANG_ALL
Hang the process no matter who is at fault

ABORT
Terminate and dump core if MQ caused the fault

ABORT_ALL
Terminate and dump core no matter who is at fault

Each of these four values can be followed by a plus sign, for example HANG_ALL+. The plus sign forces the handler to act even when MQ expects a signal, so you should not use it unless requested by IBM support. In most cases you should use the following value:

export MQS_ACTION_ON_EXCEPTION=HANG_ALL

You should set this variable in the environment where you start your queue manager and any failing applications. Monitor the /var/mqm/errors directory for a new FDC file from the xehExceptionHandler component, often with Probe Id XC130003 and a Comment1 value showing SIGBUS or SIGSEGV. When you see a matching FDC, the offending program will be waiting in an idle state for you to analyze it. You can do so with a debugger such as dbx or gdb, or on some systems using the IBM stackit script.

The HANG_ALL option tells MQ to stop the process no matter whether it was MQ or application code that failed. This is perhaps the most useful option since it allows you to capture debugging information for IBM support if MQ is at fault or for your own developers if your application code failed.

If you prefer to get a core dump for analysis later choose the value ABORT_ALL instead. The core dump will only be created if the directory permissions support write and "ulimit -c" size is > 0.

Exception Handler Diagnostic Walkthrough
Here is an FDC file that was created when a client application tried to connect to a queue manager running on AIX:

+---------------------------------------------------------+
| |
| WebSphere MQ First Failure Symptom Report |
| ========================================= |
| |
| Date/Time :- Tuesday June 12 15:32:04 EDT 2007 |
| Host Name :- aemaix4 (AIX 5.2) |
| PIDS :- 5724H7201 |
| LVLS :- 6.0.1.1 |
| Product Long Name :- WebSphere MQ for AIX |
| Vendor :- IBM |
| Probe Id :- XC130003 |
| Application Name :- MQM |
| Component :- xehExceptionHandler |
| SCCS Info :- lib/cs/unix/amqxerrx.c, 1.214.1.4 |
| Line Number :- 1341 |
| Build Date :- May 5 2006 |
| CMVC level :- p600-101-060504 |
| Build Type :- IKAP - (Production) |
| UserID :- 00007100 (jtf) |
| Program Name :- amqrmppa |
| Addressing mode :- 64-bit |
| Process :- 311466 |
| Thread :- 4 |
| QueueManager :- JTF |
| ConnId(1) IPCC :- 40 |
| Major Errorcode :- STOP |
| Minor Errorcode :- OK |
| Probe Type :- HALT6109 |
| Probe Severity :- 1 |
| Probe Description :- AMQ6109: An internal WebSphere MQ |
| error has occurred. |
| FDCSequenceNumber :- 0 |
| Arith1 :- 11 b |
| Comment1 :- SIGSEGV: address not mapped(539) |
| |
+---------------------------------------------------------+

MQM Function Stack
ccxResponder
rrxResponder
rriAcceptSess
rriInitExits
rriCALL_EXIT
xcsFFST

This FDC shows both the XC130003 Probe Id and the xehExceptionHandler component name. and the comment at the bottom of the header shows this process received a SIGSEGV signal. The amqrmppa program is responsible for handling channel activity, and the functions listed in the MQM Function Stack show the failing thread was responding to an incoming channel request.

Since amqrmppa is one of the MQ queue manager processes, most problems within it need to be investigated by IBM support. In this case, the functions rriInitExits and rriCALL_EXIT suggest this channel failed while calling a channel exit, which is typically not provided by IBM. At the bottom of the FDC some of the channel details are printed, including its name (IPVAUTH.SVRCONN) and a security exit name.

The MQS_ACTION_ON_EXCEPTION=HANG_ALL variable was set before this queue manager was started, so after writing the FDC file the MQ signal handler suspended this amqrmppa process. The FDC shows it is running under process identifier 311466, so it would be possible to attach a debugger to this process. Alternatively, running 'stackit -p 311466' provides the following information:

Running stackit against process 311466 Tue Jun 12 15:32:43 2007
=================================================================

UID PID PPID C STIME TTY TIME CMD
jtf 311466 4202 0 15:32:03 - 0:00 /usr/mqm/bin/amqrmppa -m JTF

Stack Trace

311466: /usr/mqm/bin/amqrmppa -m JTF
---------- tid# 2982001 ----------
0x0900000001603a60 cccJobMonitor() + ??
0x090000000160184c rppPoolMain() + 0x44c
0x0000000100000490 UnknownData() + 0xffffffff00000298
0x0000000100000288 __start() + 0x90
---------- tid# 3428471 ----------
0x090000000002b688 _ptrgl() + ??
0x090000000003b334 nsleep(??, ??) + 0xac
0x0900000000046be4 sleep(??) + 0x58
0x090000000117ca00 xcsSleep() + 0x90
0x0900000001128f0c xehInterpretSavedSigaction() + 0x9c
0x090000000112e1dc xehExceptionHandler() + 0xb1c

0x0900000004bd3504 ipvQueryLdapServer() + 0x10
0x07000000500007dc ????????(??, ??) + ??
0x0900000004bd3588 ipvAnalyzeAddress() + 0xc
0x0900000004bd3328 ipvAuth(0x110099f10, 0x1100c79b8...
0x0900000001641f50 rriInitExit() + 0x250
0x090000000164d87c rriInitExits() + 0xf3c
0x090000000172b7e4 rriAcceptSess() + 0x1b34
0x0900000001729334 rrxResponder() + 0x164
0x09000000015f1aa0 ccxResponder() + 0x190
0x09000000015ee070 cciResponderThread() + 0xc0
0x090000000112f1d4 ThreadMain() + 0xd44
0x090000000036e508 _pthread_body(??) + 0xbc
...

Address Space Map

311466 : /usr/mqm/bin/amqrmppa -m JTF
100000000 2K read/exec amqrmppa
110000540 0K read/write amqrmppa
9fffffff0000000 33K read/exec /usr/ccs/bin/usla64
9fffffff00084a7 0K read/write /usr/ccs/bin/usla64
900000004bd3000 4K read/exec /scratch/ipverify/ipverify
8001000a001ac08 0K read/write /scratch/ipverify/ipverify
900000001899000 86K read/exec /usr/mqm/lib64/amqcltca_r
...

The stack information printed here is more detailed since it includes operating system functions, not just those functions belonging to WebSphere MQ. Unlike the stack in the FDC file, this one reads from the bottom up. It shows that the MQ rriInitExit function passed control to the ipvAuth function, which is the security exit function configured on the channel:

display channel(IPVAUTH.SVRCONN)
1 : dis chl(IPVAUTH.SVRCONN)
AMQ8414: Display Channel details.
CHANNEL(IPVAUTH.SVRCONN) CHLTYPE(SVRCONN)
ALTDATE(2007-06-12) ALTTIME(15.28.52)
COMPHDR(NONE) COMPMSG(NONE)
DESCR( ) HBINT(300)
KAINT(AUTO) MAXMSGL(4194304)
MCAUSER( ) MONCHL(OFF)
RCVDATA( ) RCVEXIT( )
SCYDATA( )
SCYEXIT(/scratch/ipverify/ipverify(ipvAuth))
SENDDATA( ) SENDEXIT( )
SSLCAUTH(REQUIRED) SSLCIPH( )
SSLPEER( ) TRPTYPE(TCP)

Because this error happened inside the security exit function, the developer of the exit needs to investigate. Fortunately, the stack provides more information to debug the security exit. It shows that the ipvAuth function called ipvAnalyzeAddress, which indirectly called ipvQueryLdapServer. This is the last function before the signal was raised, so it appears the ipvQueryLdapServer function is at fault. The stackit output also confirms that the ipvQueryLdapSever function address is inside the /scratch/ipverify/ipverify module.

A developer could use a debugger to investigate more closely, or perhaps add debugging or logging code to help identify the fault. Sometimes the problem is easy to see when investigating the code. In this case the failure was due to some intentionally bad code added to the exit. The following statement tries to store the integer value 42 at address 0x0000000000000539 (the hex value for decimal 1337):

int *badaddr = (int *)1337;
*badaddr = 42;

Looking back at the FDC header, the comment not only identifies the fault as a SIGSEGV, but it also gives the address that caused the failure: "SIGSEGV: address not mapped(539)". If the exit had instead dereferenced a NULL pointer, the comment would have read "SIGSEGV: address not mapped(0)", at least on AIX. Due to differences between operating systems the comment can vary a bit.

In order to clean up the problem it is first necessary to stop the queue manager. Because this amqrmppa process is in a perpetual hang, endmqm won't complete successfully until it is killed, for example by running 'kill -9 311466'. Once the queue manager and its listener have stopped, the rebuilt exit program should be installed. On AIX root must run the command 'slibclean' to flush the old exit code out of the kernel library cache. Finally, after restarting the queue manager, the new exit is able to handle incoming client connections without any problem:

aemaix4> amqsputc TEST JTF
Sample AMQSPUT0 start
target queue is TEST
Hello, world.

While this sample client application is active, runmqsc shows the SVRCONN channel is running:

display chstatus(IPVAUTH.SVRCONN)
1 : dis chs(IPVAUTH.SVRCONN)
AMQ8417: Display Channel Status details.
CHANNEL(IPVAUTH.SVRCONN) CHLTYPE(SVRCONN)
CONNAME(127.0.0.1) CURRENT
RQMNAME( ) STATUS(RUNNING)
SUBSTATE(RECEIVE) XMITQ( )

These tests and the absence of any new FDC files confirms that the correction to the channel exit solved the SIGSEGV exception in the WebSphere MQ channel process.

Connecting WebSphere MQ and Message Broker using SSL - Middleware News

2011-07-07T07:56:00.000-07:00

Connecting WebSphere MQ and Message Broker using SSL - Middleware News

Ssl2

View more documents from karthickmsit.

Connecting two Windows Queue Managers using SSL - Middleware News

2011-07-07T07:24:00.000-07:00

Connecting two Windows Queue Managers using SSL - Middleware News

Mq ssl channels_on_windows

View more documents from karthickmsit.

Adding SSL certificates to a mixed z/OS and Unix queue manager environment - Middleware News

2011-07-07T07:04:00.000-07:00

Adding SSL certificates to a mixed z/OS and Unix queue manager environment - Middleware News

1. Security Considerations

IBM advises customers who are using SSL, that the most secure way to do this is to use recognized Certification Authorities to sign their certificates. Ensuring secure transfer of information is the main purpose of SSL. This integrity must be properly observed when setting up SSL. You should always be certain who has signed each of your SSL certificates, who has had and who continues to have access to them.

The first secure way to generate certificates is to generate a certificate request, on each system or machine that uses SSL. This request has to be signed by an external Certification Authority before it can be used. Getting certificate requests signed by a CA is secure, because during the signing process at no point do any files contain the certificate's Private Keys. This principle is vital to SSL security. Signing certificates in this way is covered by section 10. The secure way to add SSL certificates to your Production MQ system.

The second secure way that external Certificate Authorities commonly use is to supply a signed CA certificate for customers to sign their certificate requests. The Certificate Authorities usually supply other software for SSL certificate administration. This way is very similar to using a built in z/OS facility to sign your own requests that follows.

Within z/OS there is facility to sign SSL certificate requests using CA Certificates created by yourself. It is cheaper and the process is shown below. However there are downsides.

It will require the setting up of a certificate revocation system which will require administration. (This is to cover the eventuality that a certificate you issued should no longer be accepted as valid, perhaps because it has been compromised.)
All companies which use certificates generated in this way, must trust the company who administers the certificates. This should include audit controls.
Time spent signing certificate requests.

Using the z/OS built in function to sign your own certificate requests protects the Private Key in the same way as the first secure way. This alternative should only be used for large scale testing of SSL on internal systems. This is covered in section 11. Securely signing a certificate request from Unix using a z/OS CA certificate.

Sections 3 to 9 describe a slightly different strategy to set up Queue Managers to use SSL. The strategy is effective, but is not recommended in a production environment due to the potential to expose the Private Key. In the strategy described in Sections 3 to 9 the Private Key for Unix certificates is generated on the z/OS machine and is exported with the certificate in a file, which is encrypted and protected with a password. As the private key is created on one machine, and then moved to another, this method is considered less secure. The skills learned by following Sections 3 to 9 are applicable to using the more secure methods described in Sections 10 and 11 (which reference the other relevant sections).

2. Summary of SSL Certificate set up for Queue Managers

Each Queue Manager requires a Key Repository. On z/OS this is a RACF Key Ring and on Unix this is a set of files secured by operating system permissions.
The following sections describe how this Key Repository is created. A summary of the items this Key Repository must contain is provided as follows:

The personal certificate for that Queue Manager with the Private Key associated with that certificate.
The personal certificate should have a label that follows the following convention: On z/OS 'ibmWebSphereMQQMGR' where QMGR is the 4 byte Queue Manager name. For distributed Queue Managers the label should be 'ibmwebspheremqqmgrname' where qmgrname is the full Queue Manager name converting all upper case characters to lower case.
A copy of the Certification Authority (CA) Certificate, used to sign its personal certificate.
A copy of all CA certificates, used to sign all personal certificates (for all Queue Managers) that it will communicate with, using SSL. *
On z/OS the repository is RACF, on distributed systems, it is IKEYMAN

*In some cases a personal certificate has been signed by a CA certificate that has in turn been signed by another CA certificate (known as a certificate chain). Each of these CA certificates, up to the self signed CA certificate, must be included in each Key Repository.

3. Creating the certificates and Key Repository on z/OS

In the example below the z/OS queue manager is called MQ0A. MQ0A has a CHINIT with an associated user of TESTUSER. On Unix the queue manager is called QM_unix.

To understand how to submit RACF commands, see section 14. Submitting RACF commands

Create a Certification Authority on z/OS. See http://www.ibm.com/support/docview.wss?uid=swg27006987 for an explanation of a Certification Authority.

RACDCERT CERTAUTH GENCERT -
SUBJECTSDN(CN('CST CA SQ00') -
T('WMQ') -
OU('TEST') -
O('IBM') -
L('HURSLEY') -
SP('HAMPSHIRE') -
C('UK')) -
WITHLABEL('SQ00 CA')

Create a personal certificate for QMGR MQ0A on z/OS and sign it with the CA SQ00 CA defined above. See http://www.ibm.com/support/docview.wss?uid=swg27006987 for an explanation of a personal certificate.
Note: the case and value of the label is important in SSL certificates. On z/OS the label is mixed case, see below.

RACDCERT ID(TESTUSER) GENCERT -
SUBJECTSDN(CN('Personal Certificate for MQ0A') -
T('QMGR') -
OU('TEST') -
O('IBM') -
L('HURSLEY') -
SP('HAMPSHIRE') -
C('UK')) -
WITHLABEL('ibmWebSphereMQMQ0A') -
SIGNWITH(CERTAUTH LABEL('SQ00 CA'))

Create a personal certificate for the Unix Queue Manager called QM_unix and sign with the CA certificate above.
Note: for distributed Queue Managers the label must be only lower case regardless of the case of the queue manager names - see below.

RACDCERT ID(TESTUSER) GENCERT -
SUBJECTSDN(CN('Personal Cert for QM_unix') -
T('QMGR') -
OU('TEST') -
O('IBM') -
L('HURSLEY') -
SP('HAMPSHIRE') -
C('UK')) -
WITHLABEL('ibmwebspheremqqm_unix') -
SIGNWITH(CERTAUTH LABEL('SQ00 CA'))

Define a Key Ring (or Key Repository) for the z/OS Queue Manager. Where TESTUSER is the User ID associated with the CHINIT started task for Queue Manager MQ0A.

RACDCERT ID(TESTUSER) ADDRING(MQ0ARING)

Connect the CA certificate and MQ0A's personal certificate into the Key Ring.

RACDCERT ID(TESTUSER) CONNECT(CERTAUTH LABEL('SQ00 CA') RING(MQ0ARING))
RACDCERT ID(TESTUSER) -
CONNECT(ID(TESTUSER) LABEL('ibmWebSphereMQMQ0A') RING(MQ0ARING))

Export the personal certificate for QM_unix. This creates a file on z/OS and adds the certificate to the file.
This file will be transferred to the Unix machine.
PKCS12 is a standard format used by z/OS, Windows and Unix, which contains personal certificates and CA certificate information, as well as the Private Key associated with the personal certificate. Other formats do not include the Private Key.

When adding a Personal Certificate to RACF, the CA certificate is not automatically added. If the CA certificate is not already there, then you need to add the CA certificate in a separate step, from a separate file. The CA certificate is typically held in a file in DER format.

The PKCS12 file contains the Private Key of the certificate, which is what makes SSL secure. As a consequence, you need to set a password for the file, to prevent its misuse. This password will be required when the certificate is imported. The password must be kept secret on a need to know basis, otherwise the integrity of your security is compromised! This is why this method is less secure than that used in sections 10 and 11.

RACDCERT ID(TESTUSER) -
EXPORT (LABEL('ibmwebspheremqqm_unix')) -
DSN('MQ.RACD.DIGCERT.UNIX.PKCS12') -
FORMAT(PKCS12DER) -
PASSWORD('ZOSPASS')

The file will have characteristics like the following.

Data Set Name . . . : MQ.RACD.DIGCERT.UNIX.PKCS12

General Data Current Allocation
Volume serial . . . : SP6218 Allocated tracks . : 1
Device type . . . . : 3390 Allocated extents . : 1
Organization . . . : PS
Record format . . . : VB
Record length . . . : 84
Block size . . . . : 27998 Current Utilization
1st extent tracks . : 1 Used tracks . . . . : 1
Secondary tracks . : 5 Used extents . . . : 1

Creation date . . . : 2006/03/06
Referenced date . . : 2006/03/06
Expiration date . . : ***None***

The Signing Certificate must be added before adding the PKCS12 certificate.
So we export it from RACF in DER format.

RACDCERT CERTAUTH EXPORT (-
LABEL('SQ00 CA')) -
DSN('MQS.RACD.DIGCERT.SQ00CA.DER') -
FORMAT(CERTDER)

4. Configuring the z/OS queue manager to use the certificate

The Queue Manager must be altered to use SSL, using MQSC Commands. This adds a pointer to the Key Ring and specifies a number of SSL tasks to process SSL

ALTER QMGR SSLKEYR(MQ0ARING) SSLTASKS(10)

The CHINIT must be stopped and restarted for these changes to take effect.

STOP CHINIT
START CHINIT PARM(MQ0AXPRM)

To make use of SSL, the existing channel (SSLCHANNEL) needs to have an SSL Cipherspec added.
Hint: Before setting up a channel pair to use SSL, it is best to prove that your channel pairing is set up correctly before adding SSL.

ALTER CHANNEL(SSLCHANNEL) CHLTYPE(RCVR) SSLCIPH(RC4_MD5_EXPORT)

Where RC4_MD5_EXPORT is one of the cipher specifications available on all platforms. It defines the Hash Algorithm, the Encryption Algorithm and the number of bits used in encryption. The same value must be used at each end. See Table 1 in Specifying CipherSpecs in the IBM WebSphere MQ Help Center to see which cipherspecs are available and their characteristics. This completes the changes on the z/OS machine.

5. Transfer the certificates from z/OS to the Unix machine

FTP the file (in Binary mode) to the Unix box.
IBM recommends that you use directory /var/mqm/qmgrs/qmgrname/ssl to store your certificates, where qmgrname is your Queue Manager name. They will be left in this directory by subsequent uninstalls, installations and migrations of WMQ. For security reasons, PKCS12 files should only be copied to the directories of the Queue Managers that will use it. This will help you to secure it. DER files should also be kept in the same directory, though the security implications are much reduced.

From the Unix console, go to the directory where you want to place your certificates and FTP the file from z/OS.

cd /var/mqm/qmgrs/QM_unix/ssl
FTP ...
User Name: ....
Password: ********
bin
get 'MQ.RACD.DIGCERT.UNIX.PKCS12 ' unix.p12
get 'MQ.RACD.DIGCERT.SQ00CA.DER ' SQ00CA.der
bye

6. Setting up IKEYMAN to administer SSL certificates on Unix

IKEYMAN is the IBM key management utility for managing certificates on distributed platforms. It is installed (optionally) during WebSphere MQ installation. Although IKEYMAN has a GUI and a command line interface, this document only covers the command line format, as this enables administration from Telnet.

Terms used:

A key database (key.kdb) is a file that IKEYMAN uses to store one or more key pairs and certificates.
A stash file is used by IKEYMAN to store encrypted database passwords.
GSKIT is a set of programmable interfaces that allow an application to be SSL enabled.
GSK7 is GSKIT version 7.
Key Ring and Key Repository are interchangeable terms. Key Ring is used in association with RACF and Key Repository is used in association with Distributed Platforms.

See section 15. Background References below for further details on IKEYMAN & GSKIT.

It is important to use the right User ID to administer the certificates. Ensure that you use a User ID that is either the mqm user or in the mqm group. This will restrict the number of users able to access the certificates and increase your security.

Set the JAVA_HOME for GSK7. This is machine dependant. Note: this step is necessary to add the PKCS12 certificates into the key.kdb.Without this being set correctly, you will get a message indicating that the key.kdb is corrupted.
Two variations are shown below.

export JAVA_HOME=/var/mqm/ssl/jre
for AIX only
export JAVA_HOME=/opt/mqm/ssl/jre
for all other Unix platforms

Change to your chosen directory for Queue Manager QM_unix.

cd /var/mqm/qmgrs/QM_unix/ssl

Create a key.kdb and a stash file, if you do not already have one for the queue manager. The command puts an encrypted version of the password (set here to KEYPASS) in the stash file.
It is used to verify the authority of the GSKIT commands. The password is set to expire after 90 days.

gsk7cmd -keydb -create -db key -pw KEYPASS -type cms -expire 90 -stash

Enable all mqm users to read the key.kdb and the stash file.

If you perform WMQ administration as the 'mqm' user (preferred) then change ownership and permissions of the file as follows:

chown mqm:mqm key.*
chmod 600 key.*

Alternatively, you can grant update permissions to all users in the 'mqm' group as follows:

chown mqm:mqm key.*
chmod 660 key.*

7. Using the certificates on the Unix machine.

Import the DER file (FTP'd above) into key.kdb.
This action adds the Signing CA certificate "SQ00 CA" to the key.kdb. This step must precede the addition of the personal certificate.

gsk7cmd -cert -add -db key.kdb -pw KEYPASS -label "SQ00 CA" -format binary -trust enable -file SQ00CA.der

Import the PKCS12 file (FTP'd above) into key.kdb.
This action adds the personal certificate to the key.kdb.

gsk7cmd -cert -import -file unix.p12 -pw ZOSPASS -type pkcs12 -target key.kdb -target_pw KEYPASS -target_type cms

List all certificates in the key.kdb.
gsk7cmd -cert -list all -db key.kdb -pw KEYPASS -type cms

For this installation I have the following. The last two lines are the CA certificate for "SQ00 CA" (0cn=cst ca ...) and the personal certificate for the Queue Manager (ibmwebspheremq...).

Certificates in database: ./key.kdb
... Other supplied CA certificates
0cn=cst ca sq00, t=wmq, ou=cst, o=ibm, l=hursley, st=hampshire, c=uk
ibmwebspheremqqm_unix

8. Configuring the Unix queue manager to use the certificate.

Use runmqsc to alter the Queue Manager to use the KEY Repository for QM_unix (this is the key.kdb file created above).

runmqsc QM_unix
alter qmgr sslkeyr('/var/mqm/qmgrs/QM_unix/ssl/key')
Note: If you use the default location for key repositories (as above) this command is not necessary. If you store the IKEYMAN key database files in a different location, or use a different filename to 'key.kdb', the format of the SSLKEYR string is the full path of the .kdb file without the .kdb extension.

You do not have to shut down and restart the Queue Manager on WMQ V6 or later releases.
This is because of the MQSC command:

refresh security type(SSL)

Display the Key Repository information for the queue manager.

dis qmgr sslkeyr

dis QMGR sslkeyr
1 : dis QMGR sslkeyr
AMQ8408: Display Queue Manager details.
QMNAME(QM_unix)
SSLKEYR(/var/mqm/qmgrs/QM_unix/ssl/key)

The channel (SSLCHANNEL) needs to have the same SSL Cipherspec at both ends to make use of SSL. The z/OS channel was altered above.

ALTER CHANNEL(SSLCHANNEL) CHLTYPE(SDR) SSLCIPH(RC4_MD5_EXPORT)
Where RC4_MD5_EXPORT is the value used on the z/OS channel.

Start the channel, and show it is active.

START CHANNEL(SSLCHANNEL)
DISPLAY CHSTATUS(SSLCHANNEL)

It should have status RUNNING.

CHANNEL(SSLCHANNEL) CHLTYPE(SDR)
CONNAME(**********) CURRENT
RQMNAME(MQ0A) STATUS(RUNNING)
SUBSTATE(MQGET) XMITQ(***********)

9. Extending the scenario to include another z/OS Queue Manager.

The following actions are required to enable MQ0A and QM_unix to communicate, using SSL, with another z/OS Queue Manager MQ0M on system MV0M.
MQ0M has a CHINIT userid of TESTUSE2. It currently uses SSL and its personal certificate was signed by a CA with a label "SQ01 CA".

MQ0M needs the CA certificate used to sign the personal certificate for MQ0A (and QM_unix). MQ0A and QM_unix need the CA certificate used to sign the personal certificate for MQ0M. This will enable the three Queue Managers to communicate using SSL.

So "SQ00 CA" CA certificate is added into MQ0M's Key Ring and "SQ01 CA" CA certificate into MQ0A's Key Ring and "SQ01 CA" CA certificate is added into the key.kdb associated with QM_unix.

The CA certificates are transported in DER format, which contains the Public key, but not the Private Key associated with it.
The action of adding each CA certificate to the Key Ring, authorizes all personal certificates that it has signed.
This is why RACF gives a warning, during the addition of a CA certificate.

QM_unix uses the same CA certificate as MQ0A. This means there is only a need to include the MQ0A CA certificate and the CA certificate from MQ0M in each Key Repository. If QM_unix used a third CA certificate then that certificate would also be required in each Key Repository.

On MV0A, export the CA certificate created above to a dataset. MQ0M can then add this copy of the MQ0A CA into its Key Ring. This exported certificate contains enough information to verify the two personal certificates that it has signed above.

RACDCERT CERTAUTH EXPORT (-
LABEL('SQ00 CA')) -
DSN('MQ.RACD.DIGCERT.SQ00CA.DER') -
FORMAT(CERTDER)

FTP the file to MV0M as file MQ.RACD.DIGCERT.SQ00CA.DER.

The following actions take place on the MV0M z/OS system.

Add the CA certificate to the MV0M RACF database.

RACDCERT CERTAUTH -
ADD('MQ.RACD.DIGCERT.SQ00CA.DER') -
TRUST -
WITHLABEL('SQ00 CA')

Connect the CA certificate into MQ0M's Key Ring.

RACDCERT ID(TESTUSE2) CONNECT(CERTAUTH LABEL('SQ00 CA') RING(MQ0MRING))

Export the CA certificate used to sign MQ0M's personal certificate.

RACDCERT CERTAUTH EXPORT (-
LABEL('SQ01 CA')) -
DSN('MQ.RACD.DIGCERT.SQ01CA.DER') -
FORMAT(CERTDER)

FTP this file to MV0A z/OS system.

The next set of actions are on the MV0A z/OS system.

Add the CA certificate from MQ0M (label "SQ01 CA") in file MQ.RACD.DIGCERT.SQ01CA.DER to the RACF database for MQ0A.

RACDCERT CERTAUTH -
ADD('MQ.RACD.DIGCERT.SQ01CA.DER') -
TRUST -
WITHLABEL('SQ01 CA')

Connect the MV0M CA certificate into the Key Ring for MQ0A.

RACDCERT ID(TESTUSER) CONNECT(CERTAUTH LABEL('SQ01 CA') RING(MQ0ARING))

The next set of actions are on the Unix system.

Transfer the CA certificate to the Unix box, using the procedure above and continue on the Unix box. This culminates in the following get.

get 'MQ.RACD.DIGCERT.SQ01CA.DER ' SQ01CA.der

Add the MV0M CA certificate to the key.kdb.
gsk7cmd -cert -add -db key.kdb -pw KEYPASS -label "SQ01 CA" -format binary -trust enable -file SQ01CA.der

List all certificates in the key.kdb.
gsk7cmd -cert -list all -db key.kdb -pw KEYPASS -type cms

This now shows "SQ01 CA" added.

Certificates in database: ./key.kdb
SQ01 CA
... Other supplied CA certificates
0cn=cst ca sq00, t=wmq, ou=cst, o=ibm, l=hursley, st=hampshire, c=uk
ibmwebspheremqqm_unix

10. The secure way to gain an SSL certificate for a Production WMQ system.

This section describes how a Key Repository is created for z/OS and Unix queue managers, and a secure way in which a certificate can be requested for that queue manager, from a CA.

In the example below the z/OS queue manager is called MQ0P. MQ0P has a CHINIT with an associated user of PRODUSER. The Unix queue manager is called QM_unixP, and the logged in user is the WMQ administrator ID 'mqm' (or a member of the 'mqm' group).

On z/OS

To generate a request on z/OS use RACF. For details see section 14. Submitting RACF commands

Create a request for a personal certificate. See http://www.ibm.com/support/docview.wss?uid=swg27006987 for an explanation of a personal certificate.
Note: the case and value of the label is important in SSL certificates. On z/OS the label is mixed case, see below.

RACDCERT ID(PRODUSER) GENCERT -
SUBJECTSDN(CN('Personal Certificate for MQ0P') -
T('QMGR') -
OU('PRODN') -
O('IBM') -
L('HURSLEY') -
SP('HAMPSHIRE') -
C('UK')) -
WITHLABEL('ibmWebSphereMQMQ0P'))

This certificate request must be written to a file in order to be sent to a Certificate Authority to be signed. This is achieved by the following.

RACDCERT ID(PRODUSER) -
GENREQ(LABEL('ibmWebSphereMQMQ0P')) -
DSN('MQ.RACD.DIGCERT.CERTREQ.MQ0P.ARM')

This file will be in EBCDIC format and will look something like

-----BEGIN CERTIFICATE-----
MIIC3zCCAkigAwIBAgIBDTANBgkqhkiG9w0BAQUFADBzMQswCQYDVQQGEwJVSzES
MBAGA1UECBMJSEFNUFNISVJFMRAwDgYDVQQHEwdIVVJTTEVZMQwwCgYDVQQKEwNJ
Qk0xDDAKBgNVBAsTA0NTVDEMMAoGA1UEDBMDV01RMRQwEgYDVQQDEwtDU1QgQ0Eg
U1EwMjAeFw0wNjA1MTEwNDAwMDBaFw0wNzA1MTIwMzU5NTlaMHExCzAJBgNVBAYT
AlVLMRIwEAYDVQQIEwlIQU1QU0hJUkUxEDAOBgNVBAcTB0hVUlNMRVkxDDAKBgNV
BAoTA0lCTTENMAsGA1UECxMEVEVTVDENMAsGA1UEDBMEUU1HUjEQMA4GA1UEAwwH
UU1fTUpGNzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAn8oXMIsLZWZiO63x
XldHOILZe6XofqPCwP+aVpbWrjoEJGpDdyBbWQ73iwNrA7+wM4Yd1Q7Fc9ij5fwJ
qm4iCUCV/mqluXVLB2OAkt9rxJojzCB1SKvn9QnOuRF6BbaX0GyRBzKZS+ZaEmXO
44eYwXEUn1+ygi1tAeF/NAwDSNkCAwEAAaOBhDCBgTA/BglghkgBhvhCAQ0EMhMw
R2VuZXJhdGVkIGJ5IHRoZSBTZWN1cml0eSBTZXJ2ZXIgZm9yIHovT1MgKFJBQ0Yp
MB0GA1UdDgQWBBR/Xvs9fGGbpSzfVPLrT0rmjtMaZjAfBgNVHSMEGDAWgBRRwXFF
BnYdlTu/DZP3SAxymrvYrzANBgkqhkiG9w0BAQUFAAOBgQBrc1z1gf217aUCNBPE
dX6OHeEfmlSkiY88AXvrpalhPyCNWuZtZLQpeQiTRdvFbhTbTU/YVPUu3QH+4Vat
DyqOzUic/ra34BRR4xxKhIGi2kMwUNqNPjPsj22tzK1Djle0tsdHYcAUDFAead90
kiplHt2OFRwUfM+zEVfrMVqJlE==
-----END CERTIFICATE-----

This file is ready to be sent to a Certification Authority, by way of whichever email system you choose to use.
Note: If your email system uses ASCII you can use the default ftp setting of ASCII to transfer the file.

When you get your signed certificate returned, put it to a dataset on z/OS. It can then be added to RACF. You should check that the signed certificate looks similar to the above. There is a short part of section 11 that covers possible problems when using ftp to put files to z/OS.

The following RACF command will add the signed personal certificate to RACF.

RACDCERT ID(PRODUSER) -
ADD('MQ.RACD.DIGCERT.CERTREQ.MQ0P.CERTBR64') TRUST -
WITHLABEL('ibmWebSphereMQMQ0P')

Your CA should provide you with a CA certificate, or multiple CA certificates. Unless RACF already contains them, every certificate must be copied to datasets in z/OS and added to RACF.
The RACDCERT ADD command will look something like the following. Where "CA Label" is a label describing the CA certificate. The label you use is not important to WMQ.

RACDCERT CERTAUTH -
ADD('MQ.RACD.DIGCERT.CERTAUTH.DER') -
TRUST WITHLABEL('CA Label')

The private certificate, and all CA certificates, need to be added to a Key Ring (this is also defined in RACF). This Key Ring will become the Key Repository for MQ0P.
The following RACF command defines a Key Ring, where PRODUSER is the User ID associated with the CHINIT started task for Queue Manager MQ0P.

RACDCERT ID(PRODUSER) ADDRING(MQ0PRING)

Connect all CA certificates, and MQ0P's personal certificate into the Key Ring using RACF commands as follows.

RACDCERT ID(PRODUSER) -
CONNECT(CERTAUTH LABEL('CA label') RING(MQ0PRING))
RACDCERT ID(PRODUSER) -
CONNECT(ID(PRODUSER) LABEL('ibmWebSphereMQMQ0P') RING(MQ0PRING))

The remaining actions to enable MQ0P to use SSL are detailed in section 4.Configuring the z/OS queue manager to use the certificate.
Note: This Queue Manager is MQ0P whereas that section refers to MQ0A

On Unix
You must read and apply 6. Setting up IKEYMAN to administer SSL certificates on Unix for this machine and Queue Manager, before you can run the following commands.
Be careful when using the commands in that section to use the name of this Queue Manager (QM_unixP) rather than QM_unix.

Change your working directory to the directory which will contain the files for the queue manager's Key Repository. The following command changes to the default Key Repository directory for a queue manager called QM_unixP.
cd /var/mqm/qmgrs/QM_unixP/ssl

Create a Key Repository for the queue manager. The following command creates a Key Repository with the default name 'key.kdb'.
gsk7cmd -keydb -create -db key.kdb -pw KEYPASS -stash

It is important that the file permissions of the key.* files created allow the WMQ queue manager to read the files, while not giving read access to other users. For example the files can be given u+rw permissions only, if administered by the 'mqm' user, or u+rw,g+rw permissions if administered by other members of the 'mqm' group.

Generate a certificate request from IKEYMAN and put a copy of the (not yet signed) certificate into the certreq.arm file. The label must be of the correct format, as described in Section 2.
gsk7cmd -certreq -create -db key.kdb -pw KEYPASS -label ibmwebspheremqqm_unixp -dn "CN=Personal Certificate for QM_unixP,OU=PROD-N,O=IBM,C=UK" -size 1024 -file certreq.arm

The certreq.arm file is ready to be sent to a Certification Authority, by way of whichever email system you choose to use. The certificate authority will sign the certificate and return it, along with the CA certificates required for that certificate.
This request will not have any Private Keys contained in the file, which makes this method very secure.

Note: The files returned may be in binary or ASCII format. I have assumed it is in ASCII format and that you detached them to CAcert.der and unixp.certb64 in the above directory.

Your CA should provide you with a CA certificate, or multiple CA certificates. These must all be added to the Key Repository of the queue manager (starting with the root CA certificate and working down the chain). The command below will add a CA certificate to the key repository, where "CAcert.der" is the file sent by the CA and placed in the same directory as the Key Repository, and "CA label" is a label describing the certificate. The label you use is not important to WMQ.

gsk7cmd -cert -add -db key.kdb -pw KEYPASS -label "CA label" -format ascii -trust enable -file CAcert.der

Once all CA certificates have been added, you can receive the signed personal certificate for the Queue Manager back into the Key Repository (where the private key has been kept safe). The following command receives a signed certificate back into the Key Repository.

gsk7cmd -cert -receive -file unixp.certbr64 -db key.kdb -pw KEYPASS -format ascii -label ibmwebspheremqqm_unixp -default_cert yes

The remaining actions to enable QM_unixP to use SSL are detailed in section 8. Configuring the Unix queue manager to use the certificate.
Be careful when using the commands in that section to use the name of this Queue Manager (QM_unixP) rather than QM_unix.
From reading section 2. Summary of SSL Certificate set-up for Queue Managers, you will see that all CA certificates used to sign personal certificates must be added to all key repositories.

11. Securely signing a certificate request from Unix using a z/OS CA certificate

If you are looking to set up an internal system using SSL certificates, you may not want to involve the expense of using an external Certification Authority. This section shows how you can use RACF (on z/OS) to sign certificate requests that you generated for Unix Queue Managers using the steps in Section 10. The secure way to gain an SSL certificate for a Production WMQ system.

For instructions on how to host a CA on a Windows or Unix machine see:
http://www.ibm.com/support/docview.wss?uid=swg21233897 for

As all certificates in your environment are signed by the same CA, your queue managers will trust that CA to validate the identity of other queue managers in your environment.

In this example, we will enable QM_unixP to communicate with any Queue Manager that is set up with a certificate signed by the same CA certificate (in this example label 'SQ00 CA'). This includes any other Unix, Windows and z/OS Queue Managers.

On unixP
The following commands take place on a Unix machine that we will call unixP. This machine hosts Queue Manager QM_unixP.
You must read and action 6. Setting up IKEYMAN to administer SSL certificates on Unix for this machine and Queue Manager, before you can run the following commands.
Be careful when using the commands in that section to use the name of this Queue Manager (QM_unixP) rather than QM_unix.

In Section 10 we described how to create a Key Repository for a Unix queue manager, create a certificate request and send it to a CA to be signed. For this Section we will generate a certificate request from IKEYMAN as follows.

Change directory to the location of the Key Repository.
cd /var/mqm/qmgrs/QM_unixP/ssl

Generate a certificate request and put a copy of the certificate into the certreq.arm file.
gsk7cmd -certreq -create -db key.kdb -pw KEYPASS -label ibmwebspheremqqm_unixp -dn "CN=Personal Certificate for QM_unixP,OU=PROD-N,O=IBM,C=UK" -size 1024 -file certreq.arm

You can now ftp the certificate request (in ASCII mode) to z/OS.

FTP ...
User Name: ....
Password: ********
quote site recfm=vb
cd 'MQ.RACD.DIGCERT'
put certreq.arm UNIXP.ARM
bye

Note: RACF may have difficulty reading your request if you did not specify the SITE FTP command. This causes hex '0D' to be inserted at the end of each line. To correct this edit the file on z/OS with the command Hex on and overtype. It should look like the example in section 10. The secure way to gain an SSL certificate for a Production WMQ system.

The following actions take place on the z/OS system.

To understand how to submit RACF commands, see section 14. Submitting RACF commands

The Certification Authority certificate on z/OS is defined as follows. See http://www.ibm.com/support/docview.wss?uid=swg27006987 for an explanation of a Certification Authority.

RACDCERT CERTAUTH GENCERT -
SUBJECTSDN(CN('CST CA SQ00') -
T('WMQ') -
OU('TEST') -
O('IBM') -
L('HURSLEY') -
SP('HAMPSHIRE') -
C('UK')) -
WITHLABEL('SQ00 CA')

Sign the Certificate request from unixP using the CA certificate in RACF. The user ID used here, TESTUSER provides an intermediate place to store the signed public certificate before it is transferred back to the Unix system where it will be used.
RACDCERT ID(TESTUSER) GENCERT( 'MQ.RACD.DIGCERT.UNIXP.ARM ' ) -
WITHLABEL('ibmwebspheremqqm_unixp')) -
SIGNWITH( CERTAUTH LABEL('SQ00 CA'))

The certificate is now in RACF so Export the certificate you have just signed from the TESTUSER profile, to a file for transfer back to the Unix system.
RACDCERT ID(TESTUSER) EXPORT (-
LABEL('ibmwebspheremqqm_unixp')) -
DSN('MQ.RACD.DIGCERT.UNIXP.CERTB64') -
FORMAT(CERTB64)

Also Export the signing CA certificate. This creates a DER file
RACDCERT CERTAUTH EXPORT (-
LABEL('SQ00 CA')) -
DSN('MQ.RACD.DIGCERT.SQ00CA.DER') -
FORMAT(CERTDER)

The following takes place on the unixP system.

You can now ftp the signed certificate (in ASCII mode) and the CA certificate (in Binary mode) to Unix from the appropriate directory.
cd /var/mqm/qmgrs/QM_unixP/ssl

FTP ...
User Name: ....
Password: ********
cd 'MQ.RACD.DIGCERT'
get UNIXP.CERTB64 unixp.certb64
bin
get SQ00CA.DER SQ00CA.der
bye

Firstly add the CA certificate to the key repository.
gsk7cmd -cert -add -db key.kdb -pw KEYPASS -label "SQ00 CA" -format binary -trust enable -file SQ00CA.der

You can now add the signed personal certificate to the key.kdb database using a command like the following.
gsk7cmd -cert -receive -file unixp.certb64 -db key.kdb -pw KEYPASS -format ascii -default_cert yes

The remaining actions to get QM_unixP using SSL are detailed in section 8. Configuring the Unix queue manager to use the certificate.
Be careful when using the commands in that section, to use the name of this Queue Manager (QM_unixP) rather than QM_unix.

On z/OS
There is no need to generate certificate requests from z/OS Queue Managers in cases where they are signed by a CA certificate on the same system. Certificates used on z/OS as the equivalent of the above certificate can be generated and signed by the CA certificate in RACF on that same image in a single command.

Create a personal certificate for QMGR MQ0A on z/OS and sign it with the same CA certificate label SQ00 CA. See http://www.ibm.com/support/docview.wss?uid=swg27006987 for an explanation of a personal certificate.
Note: The case and value of the label is important in SSL certificates. On z/OS the label is mixed case, see below.

RACDCERT ID(TESTUSER) GENCERT -
SUBJECTSDN(CN('Personal Certificate for MQ0A') -
T('QMGR') -
OU('TEST') -
O('IBM') -
L('HURSLEY') -
SP('HAMPSHIRE') -
C('UK')) -
WITHLABEL('ibmWebSphereMQMQ0A') -
SIGNWITH(CERTAUTH LABEL('SQ00 CA'))

Define a Key Ring (or Key Repository) for the z/OS Queue Manager. Where TESTUSER is the User ID associated with the CHINIT started task for Queue Manager MQ0A.

RACDCERT ID(TESTUSER) ADDRING(MQ0ARING)

Connect the CA certificate and MQ0A's personal certificate into the Key Ring.

RACDCERT ID(TESTUSER) CONNECT(CERTAUTH LABEL('SQ00 CA') RING(MQ0ARING))
RACDCERT ID(TESTUSER) -
CONNECT(ID(TESTUSER) LABEL('ibmWebSphereMQMQ0A') RING(MQ0ARING))

You will need to read and apply section 4. Configuring the z/OS Queue Manager to use the certificate.

This example has shown how to enable two Queue Managers to communicate using SSL. To enable other Unix Queue Managers to communicate, simply repeat the process outlined above for Unix Queue Managers for a new Queue Manager. Section 9. Extending the scenario to include another z/OS Queue Manager shows how to extend to include another Queue Managers on another z/OS system.

12. Other useful GSK7 Commands.

The following command changes the password on the key.kdb and causes it to expire in 90 days. If the -expire option is omitted, the password will not expire.
gsk7cmd -keydb -changepw -db key.kdb -pw KEYPASS -new_pw new_password -expire 90 -stash

To delete a certificate from the key.kdb.
For example, if you wish to exclude all messages from Queue Managers using a given CA..
gsk7cmd -cert -delete -db key.kdb -pw KEYPASS -label "SQ00 CA"

To delete the key.kdb file to start again.
gsk7cmd -keydb -delete -db key.kdb -pw KEYPASS -type cms

In a production environment, deleting a personal certificate or a Key Repository is a significant action. In a secure environment, the Key Repository is the only place where the private key for a personal certificate exists. If this private key is deleted, then the personal certificate is rendered useless. The private key cannot be recreated. Due to this, care should be taken when deleting certificates or certificate repositories.

13. Some useful RACF commands.

To list the CA certificates have been defined.
RACDCERT CERTAUTH LIST

List the personal certificates have been defined to user TESTUSER.
RACDCERT ID(TESTUSER) LIST

List the personal certificates have been defined to user TESTUSER in Key Ring MQ0ARING.
RACDCERT ID(TESTUSER) LISTRING(MQ0ARING)

Delete a specified CA certificate. Here is one you want to be VERY careful about its use. When you submit this you render useless all personal certificates that it has signed!
RACDCERT CERTAUTH DELETE(LABEL('SQ00 CA'))

Delete a specified personal certificate. This renders the personal certificate useless, but allows you to start again.
RACDCERT ID(TESTUSER) DELETE(LABEL('ibmWebSphereMQMQ0A'))

Delete the Key Ring MQ0ARING associated with user ID TESTUSER.
RACDCERT ID(TESTUSER) DELRING(MQ0ARING)

Refresh the certificates in the RACF Database. You will be prompted for this on z/OS 1.9 if you require your changes to be effective immediately.
SETROPTS RACLIST(DIGTCERT) REFRESH

14. Submitting RACF commands.

Note: To create digital certificates you will need the appropriate authority to issue the RACDCERT command, from your RACF System Administrator.

The RACF command RACDCERT is used to generate and manipulate digital certificates on z/OS. You can issue these commands in batch, for example using the following JCL.

//RACDSUB EXEC PGM=IKJEFT01,DYNAMNBR=20
//SYSPRINT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
RACDCERT ...

From TSO you can also submit the commands from the ISPF Command Shell (usually =6)

You can submit commands by prefixing them with TSO from ISPF.

Tip: Keep a record of what you have done! The best way to do this is by keeping a copy of what you did in a JCL library.

15. Background References.

For a more detailed explanation of what SSL is, click here http://www-306.ibm.com/software/webservers/httpservers/doc/v1319/9atssl.htm

For further details on how to use IKEYMAN, its' commands and platform specifics for platforms other than HP UX & AIX see the following site: http://www-306.ibm.com/software/webservers/httpservers/doc/v1319/9atikeyu.htm#HDRKMUEXPG.

GSKIT is a set of programmable interfaces that allow an application to be SSL enabled. Seehttp://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm?info/rzab6/rzab6cgskit.htm for further details on using this API.

How does the MQ parameter of expiry work ? - Middleware News

2011-06-17T11:37:00.000-07:00

How does the MQ parameter of expiry work ? - Middleware News

Symptom Your messages are expiring from the MQ queue before your MQ applications have accessed them.

Fix

Following is a section from the IBM WMQ API reference on message expiry. To summarize, messages that expire continue to contribute to a queue's depth (message count) until they are browsed, an attempt is made to transport them to another queue is made, or an MQGET command is executed against them. When some action is taken against the expired message sitting on the queue, it is discarded at that point.

The only version of WMQ 5.3 that has the option of automatically removing expired messages from a queue (without having to browse, get, etc.) is the z/OS version.

Expiry (MQLONG)

Message lifetime.

This is a period of time expressed in tenths of a second, set by the application that

puts the message. The message becomes eligible to be discarded if it has not been

removed from the destination queue before this period of time elapses.

The value is decremented to reflect the time the message spends on the destination

queue, and also on any intermediate transmission queues if the put is to a remote

queue. It may also be decremented by message channel agents to reflect

transmission times, if these are significant. Likewise, an application forwarding this

message to another queue might decrement the value if necessary, if it has retained

the message for a significant time. However, the expiration time is treated as

approximate, and the value need not be decremented to reflect small time

intervals.

When the message is retrieved by an application using the MQGET call, the Expiry

field represents the amount of the original expiry time that still remains.

After a message?s expiry time has elapsed, it becomes eligible to be discarded by

the queue manager. In the current implementations, the message is discarded when

a browse or nonbrowse MQGET call occurs that would have returned the message

had it not already expired. For example, a nonbrowse MQGET call with the

MatchOptions field in MQGMO set to MQMO_NONE reading from a FIFO ordered

queue will cause all the expired messages to be discarded up to the first unexpired

message. With a priority ordered queue, the same call will discard expired

messages of higher priority and messages of an equal priority that arrived on the

queue before the first unexpired message.

A message that has expired is never returned to an application (either by a browse

or a non-browse MQGET call), so the value in the Expiry field of the message

descriptor after a successful MQGET call is either greater than zero, or the special

value MQEI_UNLIMITED.

If a message is put on a remote queue, the message may expire (and be discarded)

whilst it is on an intermediate transmission queue, before the message reaches the

destination queue.

A report is generated when an expired message is discarded, if the message

specified one of the MQRO_EXPIRATION_* report options. If none of these

options is specified, no such report is generated; the message is assumed to be no

longer relevant after this time period (perhaps because a later message has

superseded it).

Any other program that discards messages based on expiry time must also send an

appropriate report message if one was requested.

Notes:

1. If a message is put with an Expiry time of zero, the MQPUT or MQPUT1 call

fails with reason code MQRC_EXPIRY_ERROR; no report message is generated

in this case.

2. Since a message whose expiry time has elapsed may not actually be discarded

until later, there may be messages on a queue that have passed their expiry

Chapter 10. MQMD ? Message descriptor 151

time, and which are not therefore eligible for retrieval. These messages

nevertheless count towards the number of messages on the queue for all

purposes, including depth triggering.

3. An expiration report is generated, if requested, when the message is actually

discarded, not when it becomes eligible for discarding.

4. Discarding of an expired message, and the generation of an expiration report if

requested, are never part of the application?s unit of work, even if the message

was scheduled for discarding as a result of an MQGET call operating within a

unit of work.

5. If a nearly-expired message is retrieved by an MQGET call within a unit of

work, and the unit of work is subsequently backed out, the message may

become eligible to be discarded before it can be retrieved again.

6. If a nearly-expired message is locked by an MQGET call with MQGMO_LOCK,

the message may become eligible to be discarded before it can be retrieved by

an MQGET call with MQGMO_MSG_UNDER_CURSOR; reason code

MQRC_NO_MSG_UNDER_CURSOR is returned on this subsequent MQGET

call if that happens.

7. When a request message with an expiry time greater than zero is retrieved, the

application can take one of the following actions when it sends the reply

message:

v Copy the remaining expiry time from the request message to the reply

message.

v Set the expiry time in the reply message to an explicit value greater than

zero.

v Set the expiry time in the reply message to MQEI_UNLIMITED.

The action to take depends on the design of the application suite. However, the

default action for putting messages to a dead-letter (undelivered-message)

queue should be to preserve the remaining expiry time of the message, and to

continue to decrement it.

8. Trigger messages are always generated with MQEI_UNLIMITED.

9. A message (normally on a transmission queue) which has a Format name of

MQFMT_XMIT_Q_HEADER has a second message descriptor within the

MQXQH. It therefore has two Expiry fields associated with it. The following

additional points should be noted in this case:

v When an application puts a message on a remote queue, the queue manager

places the message initially on a local transmission queue, and prefixes the

application message data with an MQXQH structure. The queue manager

sets the values of the two Expiry fields to be the same as that specified by

the application.

If an application puts a message directly on a local transmission queue, the

message data must already begin with an MQXQH structure, and the format

name must be MQFMT_XMIT_Q_HEADER (but the queue manager does not

enforce this). In this case the application need not set the values of these two

Expiry fields to be the same. (The queue manager does not check that the

Expiry field within the MQXQH contains a valid value, or even that the

message data is long enough to include it.)

v When a message with a Format name of MQFMT_XMIT_Q_HEADER is

retrieved from a queue (whether this is a normal or a transmission queue),

the queue manager decrements both these Expiry fields with the time spent

waiting on the queue. No error is raised if the message data is not long

enough to include the Expiry field in the MQXQH.

MQMD ? Expiry field

152 Application Programming Reference

v The queue manager uses the Expiry field in the separate message descriptor

(that is, not the one in the message descriptor embedded within the MQXQH

structure) to test whether the message is eligible for discarding.

v If the initial values of the two Expiry fields were different, it is therefore

possible for the Expiry time in the separate message descriptor when the

message is retrieved to be greater than zero (so the message is not eligible for

discarding), while the time according to the Expiry field in the MQXQH has

elapsed. In this case the Expiry field in the MQXQH is set to zero.

The following special value is recognized:

MQEI_UNLIMITED

Unlimited lifetime.

The message has an unlimited expiration time.

On VSE/ESA, the value of Expiry must be MQEI_UNLIMITED.

This is an output field for the MQGET call, and an input field for the MQPUT and

MQPUT1 calls. The initial value of this field is MQEI_UNLIMITED.

Expired messages on z/OS

On WebSphere MQ for z/OS, messages that have expired are discarded by the

next appropriate MQGET call. However, if no such call occurs, the expired

message is not discarded, and, for some queues, a large number of expired

messages can accumulate. To remedy this, you can set the queue manager to scan

queues periodically and discard expired messages on one or more queues.

There are two ways of doing this:

Periodic scan

You can specify a period using the EXPRYINT (expiry interval) queue

manager attribute. Each time the expiry interval is reached, the queue

manager looks for candidate queues that are worth scanning to discard

expired messages.

The queue manager maintains information about the expired messages on

each queue, and knows whether a scan for expired messages is

worthwhile. So, only a selection of queues is scanned at any time.

Shared queues are scanned only by one queue manager in a queue-sharing

group. Generally, it is the first queue manager to restart, or the first to

have EXPRYINT set. If this queue manager terminates, another queue

manager in the queue-sharing group takes over the queue scanning. Set the

expiry interval value for all queue managers within a queue-sharing group

to the same value.

Explicit request

Issue the REFRESH QMGR TYPE(EXPIRY) command, specifying the queue

or queues that you want scanned.
MQMD ? Expiry field

Note

The xCoupler (RA56-ESA Release 1.2 and greater) can set the EXPIRY for the MQ messages in 2 locations.

1. On an individual TRIGGER level (on the trigger edit screen under Extended Attributes)

2. On an individual TRANSPORT level (on the transport edit screen under Extended Attributes)

Resolving problems with MQSC commands - Middleware News

2011-06-14T15:49:00.000-07:00

Resolving problems with MQSC commands - Middleware News

If you cannot get MQSC commands to run, use the following information to see if any of these common problems apply to you. It is not always obvious what the problem is when you read the error generated.

When you use the runmqsc command, remember the following:

Use the < operator to redirect input from a file. If you omit this operator, the queue manager interprets the file name as a queue manager name, and issues the following error message:

AMQ8118: WebSphere MQ queue manager does not exist.

If you redirect output to a file, use the > redirection operator. By default, the file is put in the current working directory at the time runmqsc is invoked. Specify a fully-qualified file name to send your output to a specific file and directory.
Check that you have created the queue manager that is going to run the commands.

To do this on Windows systems, use the WebSphere MQ Explorer to display a list of queue managers. On UNIX systems, look in the WebSphere MQ configuration file, mqs.ini. This file contains the names of the queue managers and the name of the default queue manager, if you have one.
The queue manager must be running. If it is not, start it; (see Starting a queue manager). You get an error message if you try to start a queue manager that is already running.
Specify a queue manager name on the runmqsc command if you have not defined a default queue manager, or you get this error:

AMQ8146: WebSphere MQ queue manager not available.

You cannot specify an MQSC command as a parameter of the runmqsc command. For example, this is not valid:

runmqsc DEFINE QLOCAL(FRED)

You cannot enter MQSC commands before you issue the runmqsc command.
You cannot run control commands from runmqsc. For example, you cannot issue the strmqm command to start a queue manager while you are running MQSC commands interactively. If you do this, you receive error messages similar to the following:

runmqsc
.
.
Starting WebSphere MQ Commands.

1 : strmqm saturn.queue.manager
AMQ8405: Syntax error detected at or near end of cmd segment below:-s

AMQ8426: Valid MQSC commands are:
ALTER
CLEAR
DEFINE
DELETE
DISPLAY
END
PING
REFRESH
RESET
RESOLVE
RESUME
START
STOP
SUSPEND
2 : end

Running MQSC commands from text files - Middleware News

2011-06-14T15:44:00.000-07:00

Running MQSC commands from text files - Middleware News

Running MQSC commands interactively is suitable for quick tests, but if you have very long commands, or are using a particular sequence of commands repeatedly, consider redirecting stdin from a text file. (See Standard input and output for information about stdin and stdout.) To do this, first create a text file containing the MQSC commands using your usual text editor. When you use the runmqsc command, use the redirection operators. For example, the following command runs a sequence of commands contained in the text file myprog.in:

runmqsc < myprog.in

Similarly, you can also redirect the output to a file. A file containing the MQSC commands for input is called an MQSC command file. The output file containing replies from the queue manager is called the output file.

To redirect both stdin and stdout on the runmqsc command, use this form of the command:

runmqsc < myprog.in > myprog.out

This command invokes the MQSC commands contained in the MQSC command file myprog.in. Because we have not specified a queue manager name, the MQSC commands run against the default queue manager. The output is sent to the text file myprog.out. Figure 2 shows an extract from the MQSC command file myprog.in and Figure 3 shows the corresponding extract of the output in myprog.out.

To redirect stdin and stdout on the runmqsc command, for a queue manager (saturn.queue.manager) that is not the default, use this form of the command:

runmqsc saturn.queue.manager < myprog.in > myprog.out

Running MQSC commands from batch files - Middleware News

2011-06-14T15:39:00.000-07:00

Running MQSC commands from batch files - Middleware News

If you have very long commands, or are using a particular sequence of commands repeatedly, consider redirecting stdin from a batch file. To do this, first create a batch file containing the MQSC commands using your usual text editor. When you use the runmqsc command, use the redirection operators. The following example:

Creates a test queue manager, TESTQM
Creates a matching CLNTCONN and listener set to use TCP/IP port 1600
Creates a test queue, TESTQ
Puts a message on the queue, using the amqsputc sample program

Example script for running MQSC commands from a batch file

export MYTEMPQM=TESTQM
export MYPORT=1600
export MQCHLLIB=/var/mqm/qmgrs/$MQTEMPQM/@ipcc

crtmqm $MYTEMPQM
strmqm $MYTEMPQM
runmqlsr -m $MYTEMPQM -t TCP -p $MYPORT &

runmqsc $MYTEMPQM << EOF
DEFINE CHANNEL(NTLM) CHLTYPE(SVRCONN) TRPTYPE(TCP) SCYEXIT('amqrspin(SCY_NTLM)')
DEFINE CHANNEL(NTLM) CHLTYPE(CLNTCONN) QMNAME('$MYTEMPQM') CONNAME('127.0.0.1($MYPORT)')
ALTER CHANNEL(NTLM) CHLTYPE(CLNTCONN) SCYEXIT('amqrspin(SCY_NTLM)')
DEFINE QLOCAL(TESTQ)
EOF

amqsputc TESTQ $MYTEMPQM << EOF
hello world
EOF

endmqm -i $MYTEMPQM

IBM WebSphere MQ Q PROGRAM - Middleware News

2011-05-06T10:01:00.000-07:00

IBM WebSphere MQ Q PROGRAM - Middleware News

Q is simple pipe line program which takes messages from one source and
outputs to a target. The operation of the 'pipe' is controlled by
switches to the program. The source and target can either be the
console or a WebSphere MQ Queue. Since input/output can be taken from
stdin/stdout these can also be files. Two instances of Q can therefore
be used to implement a primitive file transfer program.

On most platforms a single program, Q, is supplied, which can connect
either as a local application or as a client. The mode of operation
is controlled via the '-l' parameter given below.

On other platforms, such as z/OS, only a single program, Q, is supplied
which runs only as a local application.

USAGE
_____

If the Q program is executed without any parameters or with an invalid
parameter it displays a brief description of each valid parameter. The
parameters, alphabetically, are as follows:

-a Sets message attributes when put to the output queue

p - forces persistence
n - forces non-persistence
q - uses queue default persistence
s - allow segmentation
c - get complete messages
d - put a datagram message type
R - put a request message type
r - put a reply message type
t - put a report message type
a - use read ahead on open and subscribe
A - force no use of read ahead on open and subscribe
C - close temporary queues with quiesce option
D - close temporary queues with delete option
2 - force message properties to be returned as an MQRFH2 header

-A[i|o|a]
Sets the value of an attribute. Should be used in combination
with -C and an appropriate option.

i - Application Identity Data (put and subscribe)
o - Application Origin Data (put only)
a - Accounting Token (put and subscribe)

-c Causes the MQGET call from the input queue to specify GMO_CONVERT
with the CCSID and Encoding values specified. The encoding value
should be specified in hex.

-C Controls whether the message context should be transferred from
input queue to output queue

a - pass all context
i - pass identity context
A - set all context
I - set identity context
n - no context

-d Controls what detail level is output to stdout.

f - Message content is printed formatted if it's an MQ* format
h - Message is printed in hex
l - Print message length
t - Print message offsets
x - Use XML Shortform
X - No XML Auto detect
n - Don't print the message
d/D - Print the MQMD after/before the MQI calls
o/O - Print the MQOD after/before the MQI calls
p/P - Print the MQPMO after/before the MQI calls
g/G - Print the MQGMO after/before the MQI calls
s/S - Print the MQSD after/before the MQI calls
r/R - Print the MQSRO after/before the MQI calls
1 - Low level of detail
2 - Medium level of detail
3 - High level of detail

-e Echo.
Causes the program to MQPUT any messages got from the input
queue to the reply queue.

-E Echo.
Causes the program to MQPUT any messages got from the input
queue to the reply queue, and fill in the Reply QMgr.

-f
Input file.
Each line of the file will be put to output queue as a different
message.
See "Z/OS FILE NAME FORMAT EXAMPLES" for specific z/OS details.

-F[+]
Input/output file.
Entire file will be put to the output queue as a single message.
If '+' is specified the dataset attributes will be retained if
the output dataset exists - z/OS only.
See "Z/OS FILE NAME FORMAT EXAMPLES" for specific z/OS details.

-g Use specific message id or correl id

mMsgId - Get by specified message id of 24 characters
cCorrelId - Get by correlation id of 24 characters
cGroupId - Get by group id of 24 characters
xmMsgId - Get by specified message id in hex
xcCorrelId - Get by correlation id in hex
xcGroupId - Get by group id in hex
pmMsgId - Put with specified message id of 24 characters
pcCorrelId - Put with correlation id of 24 characters
pcGroupId - Put with group id of 24 characters
pxmMsgId - Put with specified message id in hex
pxcCorrelId - Put with correlation id in hex
pxcGroupId - Put with group id in hex
pC - Use MQCI New session

-h
Only pass messages through the pipe that contain the specified
filter string. Must be single word.

-H
Use message selection on open and subscribe

-i The name of the Input Queue name (if any) to browse
See "QUEUE NAME FORMAT" for specific details.

-I The name of the Input Queue name (if any) to do destructive get
See "QUEUE NAME FORMAT" for specific details.

-jThe format name to be used on the MQPUT

-k Use browse lock

-l [ Not all platforms ]
The MQI library to link to, valid values are:

mqm - Queue Manager program

mqic32 or mqic - Client program

If not specified the program will try to use the Queue Manager
interface. If that is not present it will try to use the
MQ Client interface.

-L The maximum number of messages to process.

-m The name of the Queue Manager to connect to if not the default.

-M Allows a single text message to be put

-n"[ca|cad][cd|cdd][e|ed][x|xd]"
Sets the report option when messages are put to the output queue

ca - Confirm on arrival
cad - Confirm on arrival with data
cafd - Confirm on arrival with full data
cd - Confirm on delivery
cdd - confirm on delivery with data
cdfd - confirm on delivery with full data
e - Exceptions
ed - Exceptions with data
efd - Exceptions with full data
x - Expirations
xd - Expirations with data
xfd - Expirations with full data
pan - PAN
nan - NAN
newm - New Message Id
passm - Pass Message Id
copym - Copy Message Id
disc - Discard Message
passd - Pass discard and expiry
act - Activity Reports

-o The name of the Output Queue name (if any)
See "QUEUE NAME FORMAT" for specific details.

-O The name of the Output Queue name (if any)
See "QUEUE NAME FORMAT" for specific details.
As above but using Bind on Open

Multiple -o and -O flags can be provided which will cause a
distribution list to be used.

-p
Number of messages after which an MQCMIT is taken. If not
specified message operations are not under syncpoint.

-P
Sets the priority of put messages or on a subscribe

-q Quiet mode - doesn't write messages to screen

-r[+] The name of the Reply Queue to be placed in the message descriptor
when MQPUTing to the output queue.

If '+' is specified then the program will read the reply from the
reply queue before attempting the next put.

-s Force output to stdout. This can be used to monitor messages if
transferring messages from one queue to another.

-$
Sets separator character in queue names
Without this option you can use a queue value of QM1/Q1,QM1#Q1 or
QM1,Q1
However, '/' can be used in a queue name so it may be useful to
restrict the processing of this character.

-t Print timings for API calls

-U Sets the user ID in the message.

If '+' is specified then this instead sets the alternate user ID
for an open and subscribe call.

-v
Controls what information about what the program is doing is
printed.

p - Causes a pause before each API
>=1 - Information about each message is printed
>=2 - Each API call is printed
P - Print out command line parameters

-V[z][c] Sets the return value from the Q program. Default behaviour
is to return MQRC value.

z - Forces a zero return code
c - Return MQCC mapped to 0,4,8

-w Number of seconds to wait for a message if reading from an input
queue.

-W Number of milliseconds to before each MQGET call.
Can be used to represent 'think' time

-x[f][s][c]
Use MQCONNX

f - Use FASTPATH bindings
s - Use STANDARD bindings
i - Use ISOLATED bindings
q - No quiesce option
N - No MQDISC on end
b - Handle share block
n - Handle share noblock
c - Specify channel (for use with client connection)
t - Specify Connection Tag
u - Specify User ID and Password

-X
Loads a message from a file. File must contain hex strings such as the
message output lines from AMQSBCG (not entire output) or the output from
Q itself. Use -F if the file just contains the message characters
directly.
See "Z/OS FILE NAME FORMAT EXAMPLES" for specific z/OS details.

-y Set expiry for messages in 1/10th's of a second

-z Zero out MsgIds before MQPUT

-Z TimeZone (hours) Put Date/Time

-1 Use MQPUT1 rather than MQPUT

=# Set MQ structure versions
eg.-#m1p2g3o4x2 would ask for Version 1 MQMD
Version 2 MQPMO
Version 3 MQGMO
Version 4 MQOD
Version 2 MQCNO
eg.-#c uses current versions

Any group can be specified independantly

-* Repeat execution without program terminating

-= Set Max message size - allows truncation

-! Do not use exit handler

-S Subscribe options

o: Subscribe to Topic Object
s: Subscribe to Topic String
n: Subscription Name
u: l Subscription Level
c - Create the subscription - this is the default for Q
r - Resume an existing subscription
a - Alter an existing subscription
d - the subscription is durable
v - Any user can use this subcription
f - Only the owning user can use this subscription
g - the subscription is a group subscription
N - new publications only - no retained ones
R - get publications on request only
C - Use character based wildcards
T - Use topic based wildcards
D - Remove a durable subscription

-T Publish options

o: Subscribe to Topic Object
s: Subscribe to Topic String
r - publish a retained message
p - suppress the reply-to information on the publication
n - do not publish to any of my own subscriptions

QUEUE NAME FORMAT
_________________

A number of the parameters above allow the specification of a queue
name. For example the output queue. The name is passed to the MQOPEN
verb and can either consist of one or two parts. A one part name is
assumes to be the name of the queue and the queue manager name blank.
With a two part name the name of the queue manager is assumed to be
specified first. A two part name must use one of the following
characters as a separator

/ \ # or ,

For example the following examples tells Q to take input from the
keyboard and put the messages to different queues.

Q -oQ1
Q -oQM2/Q1
Q -oQM3#Q1

PUBLISH/SUBSCRIBE EXAMPLES
--------------------------
Make a managed, durable subscription using both topic object and topic string
and wait for messages to be delivered.
Q -Scdo:STOCK.MARKET -Ss:Prices -Sn:StockPrices -w60

Make a durable subscription using Q1 as the destination queue for publications
and remove it when we're done.
Q -ScdDs:Scores -Sn:ScoresSub -IQ1 -w60

Only receive publications every 20 seconds by requesting subscription only
on demand.
Q -ScRs:Fruit/Apples -W20000 -w120

Publish retained messages on a topic
Q -Trs:PriceList

Z/OS FILE NAME FORMAT EXAMPLES
______________________________

Example usage on z/OS for -f, -F and -X parameters.
-f"//MY.FILE" - sequential file (not fully qualified)
-f"//'USERID.MY.FILE'" - sequential file (fully qualified)
-f"//'USERID.MY.PDS(MEMBER)'" - PDS Member (fully qualified)
This doesn't work from within JCL due to
the single quotes round entire parm
string. To use this from within a parm
string in JCL do the following:-
-f"//''USERID.MY.PDS(MEMBER)''" - PDS Member (from within JCL only)
-f"//MY.PDS(MEMBER)" - PDS Member (not fully qualified)
-f"DD:INFILE" - DD Card name
-f"DD:INFILE(MEMBER)" - DD Card definition must not also have
a member defined for this to work.
-F"+DD:INFILE" - Output only example showing + to keep
data set attributes as existing file

For more details see "Chapter 11. Performing OS I/O Operations" in
z/OS C/C++ Programming Guide (SC09-4765-03).

Examples of usage
_________________
Write to a queue : q -oQ1
Write to two queues (Dist list) : q -oQ1 -oQ2
Read from a queue : q -IQ1
Browse from a queue : q -iQ1
Show Message Descriptor : q -iQ1 -dd3
Wait for messages : q -IQ1 -w60
Move messages between Queues : q -IQ1 -oQ2
Copy messages between Queues : q -iQ1 -oQ2
Subscribe to a topic : q -Ss:TopicStr -w60
Make a durable subscription : q -Sds:TopicStr -Sn:MySubName -w60
Publish on a topic : q -Ts:TopicStr

The program also allows multiple Queue Managers to be in use.
____________________________________________________________

Copy messages from QM1 to QM2 : q -xb -m QM1 -i Q1 -m QM2 -oQ2
The -xb parameter is required on some platforms to allow connection
to two difference Queue Managers from the same thread.

Move messages from QM1 to QM2 : q -xb -m QM1 -I Q1 -m QM2 -oQ2 -p20
Note that this doesn't use two phase commit. The transaction is committed
on the target and then on the source.

MESSAGE FORMATS
_______________

When typing messages in from the keyboard and message is generated each
time the return key is pressed. However, a message starting with a '#'
character is interpreted to allow multiple messages to be generated.
The syntax is displayed by entering '?' in message input. It is as
follows :-

#[!][c][Reps/[Size/[Delay/[Commits]]]]

! Don't include the # instruction string as part of the message.

C Asks for the message to be checksumed. The program will
randomly set the characters of the message. Add up the
numerical values of the whole message and print out the result.
This is useful to ensure that messages are being received
complete and without corruption.

REPS Number of message to produce

SIZE Size of each message

DELAY Delay in seconds between each MQPUT

COMMITS Commit interval.

The Size and Delay parameters can be specified negative in which case
the program will randomly choose values for each MQPUT up to the value
specified.

EXAMPLES
________

#!10 HELLO

Sends ten messages each with the content 'Hello'

#!5/1024 HELLO

Sends five messages each of 1024 bytes with the initial data of each
message being 'Hello'

#!10/-10000/-5 HELLO

Sends ten messages of random size up to 10000 bytes with a random delay
of up to 5 seconds between each MQPUT.

Note that on Windows the time interval is specified in milliseconds not
seconds as on Unix and z/OS.

INSTALLATION
____________

The following platforms are supported :
Windows (various flavours)
AIX
HP/UX
Solaris
Linux
z/OS

They are supplied in the InfoZip format file MA01 ZIPBIN.

Download this file (in BINARY) to a temporary directory and uncompress
using InfoZip's Unzip (use the default options to ensure the
subdirectories stored in the ZIP file are re-created).

This will create subdirectories containing the items shown below. Once
unpacked, transfer the appropriate executable to the destination system
and follow any system specific instruction where detailed below.

Windows DIRECTORY
q.exe - will run as a client or a Queue Manager program (see -l parameter).

UNIX DIRECTORY
q - runs as a Queue Manager or a client program (see -l parameter)

zOS DIRECTORY
Q.SEQ - sequential file containing Queue Manager program
Q.JCL - example JCL for running in batch

Transfer the Q.SEQ file to a z/OS system using the following commands
ftp> binary
ftp> quote site fixrecfm 80
ftp> put zOS\Q.SEQ Q.SEQ
In tso use the following command
receive inds(Q.SEQ)
when prompted for a filename, reply
DSN(Q.LOAD)

Q can be run on z/OS in BATCH - an example piece of JCL is provided in
zOS directory.
Q can also be run interactively, e.g. from the TSO/E READY prompt or
the ISPF Command Shell (=6).

z/OS USS
________
To run the program in the USS version you should first convert the
executable. To do this issue the following command.

TSO OPUT 'somewhere.Q.LOAD(Q)' '/u/userid/bin/q' BIN

Websphere MQ / MQSERIES PROCESSES BY PLATFORM - Middleware News

2011-04-19T07:02:00.000-07:00

Websphere MQ / MQSERIES PROCESSES BY PLATFORM - Middleware News

PLATFORM =AIX

ProcName Process Function
amqhasmx logger
amqharmx log formatter,used only if the queue manager has linear logging selected
amqzllp0 checkpoint processor
amqzlaa0 queue manager agent(s)
amqzxma0 processing controller
runmqsc MQ Command interface
amqpcsea PCF command processor
amqcrsta Any remotely started channel over TCP/IP - Could be RECEIVER,REQUESTER,CLUSRCVR,SVRCONN,SENDER,SERVER
amqcrs6a Any remotely started channel over LU62/SNA - Could be RECEIVER,REQUESTER,CLUSRCVR,SVRCONN,SENDER,SERVER
runmqchl Any locally started channel over any protocol - Could be SENDER,SERVER,CLUSSDR,REQUESTER
runmqlsr listener process
runmqchi channel initiator

PLATFORM = AS/400

ProcName Process Function
AMQHIXK4 Storage Manager (Housekeeper)
AMQMCPRA Data Store (Object Cache)
AMQCLMAA Listener
AMQALMP4 Check Point Process
AMQRMCLA Sender channel
AMQPCSVA PCF command processor
AMQRIMNA Channel initiator (trigger monitor to start channel)
AMQIQES4 Quiesce (forces user logoffs - for upgrades)
AMQIQEJ4 Quiesce (without user logoffs - for daily use if desired)
AMQCRSTA Any remotely started channel over TCP/IP - Could be RECEIVER,REQUESTER,CLUSRCVR,SVRCONN,SENDER,SERVER
AMQCRS6A Any remotely started channel over LU62/SNA - Could be RECEIVER,REQUESTER,CLUSRCVR,SVRCONN,SENDER,SERVER

PLATFORM = HP/UX

ProcName Process Function
amqhasmx logger
amqharmx log formatter, used only if the queue manager has linear logging selected
amqzllp0 checkpoint processor
amqzlaa0 queue manager agents
amqzxma0 processing controller
runmqsc MQ Command interface
amqpcsea PCF command processor
amqcrsta Any remotely started channel over TCP/IP - Could be RECEIVER,REQUESTER,CLUSRCVR,SVRCONN,SENDER,SERVER
amqcrs6a Any remotely started channel over LU62/SNA - Could be RECEIVER,REQUESTER,CLUSRCVR,SVRCONN,SENDER,SERVER
runmqchl Any locally started channel over any protocol - Could be SENDER,SERVER,CLUSSDR,REQUESTER
runmqlsr listener process
runmqchi channel initiator

PLATFORM = OS2

ProcName Process Function
AMQHASM2.EXE The logger
AMQHARM2.EXE Log formatter (LINEAR logs only)
AMQZLLP0.EXE Checkpoint process
AMQZLAA0.EXE LQM agents
AMQZXMA0.EXE Execution controller
AMQXSSV2.EXE Shared memory servers
RUNMQSC.EXE MQSeries Command processor
AMQPCSEA.EXE PCF command processor
AMQCRSTA.EXE Any remotely started channel over TCP/IP - Could be RECEIVER,REQUESTER,CLUSRCVR,SVRCONN,SENDER,SERVER
AMQCRS6A.EXE Any remotely started channel over LU62/SNA - Could be RECEIVER,REQUESTER,CLUSRCVR,SVRCONN,SENDER,SERVER
RUNMQCHL.EXE Any locally started channel over any protocol - Could be SENDER,SERVER,CLUSSDR,REQUESTER
RUNMQLSR LISTENER PROCESS
RUNMQCHI CHANNEL INITIATOR

PLATFORM = SOLARIS

ProcName Process Function
amqhasmx logger
amqharmx log formatter, used only if the queue manager has linear logging selected
amqzllp0 checkpoint processor
amqzlaa0 queue manager agents
amqzxma0 processing controller
amqcrsta Any remotely started channel over TCP/IP - Could be RECEIVER,REQUESTER,CLUSRCVR,SVRCONN,SENDER,SERVER
amqcrs6a Any remotely started channel over LU62/SNA - Could be RECEIVER,REQUESTER,CLUSRCVR,SVRCONN,SENDER,SERVER
runmqchl Any locally started channel over any protocol - Could be SENDER,SERVER,CLUSSDR,REQUESTER
runmqlsr listener process
runmqchi channel initiator
runmqsc MQ Command interface
amqpcsea PCF command processor

Windows

ProcName Process Function
AMQHASMN.EXE The logger
AMQHARMN.EXE Log formatter (LINEAR logs only)
AMQZLLP0.EXE Checkpoint process
AMQZLAA0.EXE LQM agents
AMQZTRCN.EXE Trace
AMQZXMA0.EXE Execution controller
AMQXSSVN.EXE Shared memory servers
AMQCRSTA.EXE Any remotely started channel over TCP/IP - Could be RECEIVER,REQUESTER,CLUSRCVR,SVRCONN,SENDER,SERVER
AMQCRS6A.EXE Any remotely started channel over LU62/SNA - Could be RECEIVER,REQUESTER,CLUSRCVR,SVRCONN,SENDER,SERVER
RUNMQCHL.EXE Any locally started channel over any protocol - Could be SENDER,SERVER,CLUSSDR,REQUESTER
RUNMQLSR LISTENER PROCESS
RUNMQCHI CHANNEL INITIATOR
RUNMQSC.EXE MQSeries Command processor
AMQPCSEA.EXE PCF command processor
AMQSCM.EXE Service Control Manager

Process Names Process Function

amqpcsea Command server
amqhasmx Logger
amqharmx Log formatter (linear logs only)
amqzllp0 Checkpoint processor
amqzlaa0 Queue manager agents
amqzfuma OAM process
amqzxma0 Processing controller
amqrrmfa Repository process (for clusters)
amqzdmaa Deferred message processor

Veritas Cluster - Commands - Middleware News

2011-03-10T06:48:00.000-08:00

Veritas Cluster - Commands - Middleware News

VRTSvcs VERITAS Cluster Server
VRTSvcswz VERITAS Cluster Server Wizard
VRTScsga VERITAS Cluster Server Graphical Administrator
VRTSgab VERITAS Group Membership and Atomic Broadcast
VRTSllt VERITAS Low Latency Transport
VRTSvcsor VERITAS Cluster Server Oracle Enterprise Extension
VRTSvcssy VERITAS Cluster Server Sybase Enterprise Extension
VRTSperl VERITAS Perl for VRTSvcs

Cluster Name of your HA environment
Nodes Physical systems that make up the cluster
Service group Abstract container of related resources
Resource Cluster components (i.e. NICs, IPs, disk groups,
volumes, mounts, processes, etc...)
Attributes Parameter values that define the resources
Dependencies Links between resources or service groups

Cluster Mgr Cluster Monitor : Log in, add clusters, change preferences
Cluster Mgr Cluster Explorer: Monitor systems, service grps,
resources, attributes & dependencies
Cluster Mgr Log Desk : Monitor log messages received
from engine, view GUI commands
Cluster Mgr Command Center : Build VCS commands and send to engine
LLT Low Latency transport provides fast kernel-kernel
comm. & monitors network connx.
GAB Grp membership & Atomic Broadcast maintains a synch.
state & monitors disk comm.

Config files VCS etc directory
$VCSETC=/etc/VRTSvcs
Config files VCS configuration directories
$VCSCONF=/etc/VRTSvcs/conf/config
Binary files VCS opt directory
$VCSOPT=/opt/VRTSvcs
Binary files VCS binary path
$VCSBIN=/opt/VRTSvcs/bin
Log files VCS log path
$VCSLOG=/var/VRTSvcs/log
Config files VCS configuration file
/etc/VRTSvcs/conf/config/main.cf
LLT tab file LLT configuration file
/etc/llttab
LLT hosts file LLT host name database
/etc/llthosts
GAB file Grp membership & Atomic Broadcast file
/etc/gabtab

quick-start VCS Quick-start wizard
# $VCS_HOME/wizards/config/quick_start
quick-NFS VCS Quick-NFS wizard
# $VCS_HOME/wizards/services/quick_nfs
llt Verify LLT
# /sbin/llstat -n
llt Get interface MAC Address
# /opt/VRTSllt/getmac device_name
llt Check network connectivity
# /opt/VRTSllt/dlpiping -s|-c -v device_name
gab Verify GAB
# /sbin/gabconfig -a ; /sbin/gabconfig -l
hasys List systems in cluster
# /opt/VRTSvcs/bin/hasys -list
hasys Detailed info on each cluster node
# /opt/VRTSvcs/bin/hasys -display (sysname)
hasys Increase system count in gabtab startup
# /opt/VRTSvcs/bin/hasys -add (sysname)
hasys Delete a system
# /opt/VRTSvcs/bin/hasys -delete (sysname)
hastart Start VCS cluster
# /opt/VRTSvcs/bin/hastart
hastart Force start a stale VCS cluster
# /opt/VRTSvcs/bin/hastart -force -stale
hastop Stop VCS on all systems
# /opt/VRTSvcs/bin/hastop -all
hastop Stop VCS had, keep srvc-groups running
# /opt/VRTSvcs/bin/hastop -local -force
hastop Stop VCS, migrate srvc-groups to sysname
# /opt/VRTSvcs/bin/hastop -sys (sysname) -evacuate
hastatus Provide continual status of service grps
# /opt/VRTSvcs/bin/hastatus
hastatus Verify status of service groups
# /opt/VRTSvcs/bin/hastatus -summary
hacf Check for syntax errors in main.cf
# /opt/VRTSvcs/bin/hacf -verify /etc/VRTSvcs/conf/config/main.cf
hacf Generate dependency tree in main.cf
# /opt/VRTSvcs/bin/hacf -generate /etc/VRTSvcs/conf/config/main.cf

hares List all resources
# /opt/VRTSvcs/bin/hares -list
hares List a resource's dependencies
# /opt/VRTSvcs/bin/hares -dep (resource_name)
hares Get detailed info on a resource
# /opt/VRTSvcs/bin/hares -display (resource)
hares Add a resource
# /opt/VRTSvcs/bin/hares -add (resource_name (resource_type (service_group)
hares Modify attributes of the new resource
# /opt/VRTSvcs/bin/hares -modify (resource_name (attribute_name (value)
hares Delete a resource
# /opt/VRTSvcs/bin/hares -delete (resource_name)
hares Online a resource
# /opt/VRTSvcs/bin/hares -online (resource_name) -sys (system_name)
hares Offline a resource
# /opt/VRTSvcs/bin/hares -offline (resource_name) -sys (system_name)
hares Monitor resource on a system
# /opt/VRTSvcs/bin/hares -probe (resource_name) -sys (system_name)
hares Clear a faulted resource
# /opt/VRTSvcs/bin/hares -clear (resource_name) [-sys system_name]
hares Make a resource's attribute value local
# /opt/VRTSvcs/bin/hares -local (resource_name) (attribute_name) value)
hares Make a resource's attribute value global
# /opt/VRTSvcs/bin/hares -global (resource_name) (attribute_name) value)
hares Specify a dependency between 2 resources
# /opt/VRTSvcs/bin/hares -link (parent_res) (child_res)
hares Remove dependency between 2 resources
# /opt/VRTSvcs/bin/hares -unlink (parent_res) (child_res)
hares Modify a Share res. by adding options
# /opt/VRTSvcs/bin/hares Share_cicgt-as4-p_apps Options "%-o rw,root=dcsa-cln1"

hagrp List all service groups
# /opt/VRTSvcs/bin/hagrp -list
hagrp List a service group's resources
# /opt/VRTSvcs/bin/hagrp -resources [service_group]
hagrp List a service group's dependencies
# /opt/VRTSvcs/bin/hagrp -dep [service_group]
hagrp Detailed info about a service group
# /opt/VRTSvcs/bin/hagrp -display [service_group]
hagrp Start service group, bring res. online
# /opt/VRTSvcs/bin/hagrp -online (service_group) -sys (system_name)
hagrp Stop service group, bring res. offline
# /opt/VRTSvcs/bin/hagrp -offline (service_group) -sys (system_name)

hagrp Switch service group between nodes
# /opt/VRTSvcs/bin/hagrp -switch (service_group) -to (system_name)
hagrp Freeze svcgroup, (disable onl. & offl.)
# /opt/VRTSvcs/bin/hagrp -freeze (service_group) [-persistent]
hagrp Thaw a svcgroup, (enable onl. & offl.)
# /opt/VRTSvcs/bin/hagrp -unfreeze (service_group) [-persistent]
hagrp Enable a service group
# /opt/VRTSvcs/bin/hagrp -enable (service_group) [-sys system_name]
hagrp Disable a service group
# /opt/VRTSvcs/bin/hagrp -disable (service_group) [-sys system_name]
hagrp Enable all resources in a service group
# /opt/VRTSvcs/bin/hagrp -enableresources (service_group)
hagrp Disable all resources in a service group
# /opt/VRTSvcs/bin/hagrp -disableresources (service_group)
hagrp Specify dependenciy between 2 svc groups
# /opt/VRTSvcs/bin/hagrp -link (parent_group) (child_group) (relationship)
hagrp Remove dependenciy between 2 svc groups
# /opt/VRTSvcs/bin/hagrp -unlink (parent_group) (child_group)
hagrp Auto-Enable a servicegroup marked
# /opt/VRTSvcs/bin/hagrp -autoenable (service_group) [-sys system_name]
disabled due to prob with system_name.

hatype List resource types
# /opt/VRTSvcs/bin/hatype -list
hatype Detailed info on a resource type
# /opt/VRTSvcs/bin/hatype -display (resource_type)
hatype List all resources of a part. type
# /opt/VRTSvcs/bin/hatype -resources (resource_type)
hatype Add a resource type
# /opt/VRTSvcs/bin/hatype -add (resource_type)
hatype Set static attribute values
# /opt/VRTSvcs/bin/hatype -modify ...
hatype Delete a resource type
# /opt/VRTSvcs/bin/hatype -delete (resource_type)
haattr Add Attribute to a Type definition
# /opt/VRTSvcs/bin/haattr -add (resource_type) (attribute_name) /
(attribute_type -integer, -string, -vector)
haattr Delete a Entry in a Type definition
# /opt/VRTSvcs/bin/haattr -delete (resource_type) (attribute_name)
haconf Set VCS configuration file to r/w mode
# /opt/VRTSvcs/bin/haconf -makerw
haconf Set VCS configuration file to read mode
# /opt/VRTSvcs/bin/haconf -dump -makero
hauser Add a user with r/w access to VCS
# /opt/VRTSvcs/bin/hauser -add (user_name)
hauser Add a user with read access only to VCS
# /opt/VRTSvcs/bin/hauser -add VCSGuest
hauser Update a user
# /opt/VRTSvcs/bin/hauser -update (user_name)
hauser Delete a user
# /opt/VRTSvcs/bin/hauser -delete (user_name)
hauser Display all users
# /opt/VRTSvcs/bin/hauser -display
haagent Start agents manually
# haagent -start (agent_name) -sys (system_name)
haagent Stop agents manually
# haagent -stop (agent_name) -sys (system_name)
hagui Start Cluster Manager
# /opt/VRTSvcs/bin/hagui
hagui Start Cluster Manager in debug mode
# /opt/VRTSvcs/bin/hagui -D

Product Terminology comparisons
Sun SC 2.2 Veritas VCS 1.1
------------------------------------------------------
cluster name cluster name
admin workstation -
physical node A local system
physical node B remote system
physical node IP address maintenance IP address
logical host service group
logical host IP address service group IP address
- resources
disk group disk group
private heartbeats communication channels
- GAB disk (disk heartbeat)
Quorum disk -
Admin filesystem -
scinstall Quick-Start wizard
split-brain network partition

configuration files:
/etc/llthosts
/etc/llttab
/etc/gabtab
/etc/VRTSvcs/conf/config/main.cf
/etc/VRTSvcs/conf/config/sysname

Identifying vulnerable applications

The following commands can help you quickly and accurately identify whether you are running a vulnerable version that requires updating.

Solaris systems, run the following command:

# pkginfo -l VRTSvcs | grep VERSION
VERSION: 3.5

The base version will appear to the right of the VERSION tag. If it is 3.5, or 4.0, you are vulnerable. If nothing is returned, you do not have VERITAS Cluster Server for UNIX installed.

Linux systems, run the following command:

# rpm -q -i VRTSvcs | grep Version
Version: 2.2.rhel30 Vendor: VERITAS Software Corp.

The version (along with the platform, in this case, RHEL 3.0), will appear to the right of the Version tag. If it reads 2.2, you are vulnerable. If nothing is returned, you do not have VERITAS Cluster Server for UNIX installed.

AIX systems, type the following command:

# lslpp -l | grep VRTSvcs.rte
VRTSvcs.rte 4.0.0.0 COMMITTED VERITAS Cluster Server 4.0

The version will appear at the end of the line (in this case, 4.0). If it includes 3.5 or 4.0, you are vulnerable. If nothing is returned, you do not have VERITAS Cluster Server for UNIX installed.

HP-UX systems, type the following command:

# swlist | grep VRTSvcs
...
VRTSvcs 3.5 Veritas Cluster Server
...

The results may include several lines of output. Identify the line that starts with VRTSvcs and note the version number in the second column. If it reads 3.5, you are vulnerable. If this line does not appear in the output, you do not have VERITAS Cluster Server for UNIX installed.

Mitigation/Workarounds

For customers unable to apply the recommended fixes immediately, removing root suid permission on VCS 'ha' binaries and restricting access to Authorized VCS users can protect a VCS cluster from possible elevation of privileges until such time as proper updates can be applied.

NOTE: This workaround will require non-root users who require access to be assigned a valid VCS Username and password for use every time they communicate with the VCS Cluster.

Remove root suid permissions on any VCS 'ha' binaries

Find affected binaries as follows: -

On Linux, use the command "find /opt/VRTSvcs -perm 4000"

On Solaris, AIX, HP-UX use the command "find /opt/VRTSvcs -perm 4755"

chmod u-s

Restrict access to Cluster Nodes to only Authorized VCS users

Check the value of Cluster attribute AllowNativeCliUsers as: -

haclus -value AllowNativeCliUsers

If the value of the above attribute is 1, perform the following steps: -

haconf -makerw

haclus -modify AllowNativeCliUsers 0

haconf -dump -makero

Force non-root users to specify a valid VCS Username and password and use TCP for communication by setting the following environment variable:

VCS_TEST_HOST= where value is the hostname of the cluster node.

e.g., export VCS_TEST_HOST=sysa where sysa is the hostname of the cluster node.

NOTE: By removing the root suid permissions, a non-root user cannot communicate with VCS using root Unix Domain Sockets (UDS). By setting the VCS_TEST_HOST environment variable, the 'ha' command (e.g. hagrp) can be used by a non-root user after specifying a valid VCS username and password.

WARNING: Any 'cron' jobs running as a non-root user and using a VCS 'ha' command may fail because of not specifying a valid VCS username and password. For such cases, the appropriate VCS patch listed above should be applied.

cluster_server_datasheet

Veritas Cluster Cheat Sheet

Control commands - Middleware News

2011-02-26T07:13:00.000-08:00

Control commands - Middleware News

* amqccert (check certificate chains)
* amqmdain (WebSphere MQ services control)
* Topic closedamqtcert (transfer certificates)
* crtmqcvx (data conversion)
* crtmqm (create queue manager)
* dltmqm (delete queue manager)
* dmpmqaut (dump authority)
* dmpmqlog (dump log)
* dspmq (display queue managers)
* dspmqaut (display authority)
* dspmqcsv (display command server)
* dspmqfls (display files)
* dspmqrte (WebSphere MQ display route application)
* dspmqtrc (display formatted trace output)
* dspmqtrn (display transactions)
* dspmqver (display version information)
* endmqcsv (end command server)
* endmqlsr (end listener)
* endmqdnm (stop .NET monitor)
* endmqm (end queue manager)
* endmqtrc (end trace)
* mqftapp (run File Transfer Application GUI)
* mqftrcv (receive file on server)
* mqftrcvc (receive file on client)
* mqftsnd (send file from server)
* mqftsndc (send file from client)
* rcdmqimg (record media image)
* rcrmqobj (recreate object)
* rsvmqtrn (resolve transactions)
* runmqchi (run channel initiator)
* runmqchl (run channel)
* runmqdlq (run dead-letter queue handler)
* runmqdnm (run .NET monitor)
* runmqlsr (run listener)
* runmqsc (run MQSC commands)
* runmqtmc (start client trigger monitor)
* runmqtrm (start trigger monitor)
* Topic closedsetmqaut (grant or revoke authority)
* setmqcrl (set certificate revocation list (CRL) LDAP server definitions)
* setmqprd (enroll production license)
* setmqscp (set service connection points)
* strmqcfg (start WebSphere MQ Explorer)
* strmqcsv (start command server)
* strmqm (start queue manager)
* strmqtrc (Start trace)

COMPHDR AND COMPMSG CHANNEL ATTRIBUTES CAN'T HAVE SPACES AROUND THEIR VALUES WHEN BEING ACCESSED BY RUNMQSC - Middleware News

2011-02-26T06:22:00.000-08:00

COMPHDR AND COMPMSG CHANNEL ATTRIBUTES CAN'T HAVE SPACES AROUND THEIR VALUES WHEN BEING ACCESSED BY RUNMQSC - Middleware News

Data compression (COMPMSG)

This is a list of message data compression techniques supported by the channel. For sender, server, cluster-sender, cluster-receiver, and client-connection channels the values specified are in order of preference. The first compression technique supported by the remote end of the channel is used. The channels' mutually supported compression techniques are passed to the sending channel's message exit where the compression technique used can be altered on a per message basis. Compression will alter the data passed to send and receive exits. See Header compression (COMPHDR) for compression of the message header.
The possible values are:

NONE
No message data compression is performed. This is the default value.

RLE
Message data compression is performed using run-length encoding.

ZLIBFAST
Message data compression is performed using the zlib compression technique. A fast compression time is preferred.

ZLIBHIGH
Message data compression is performed using the zlib compression technique. A high level of compression is preferred.

ANY
Allows the channel to support any compression technique that the queue manager supports. Only supported for Receiver, Requester and Server-Connection channels.

This attribute is valid for all channel types.

Error description

COMPHDR and COMPMSG channel attributes are the only ones
that cannot be set with blanks surrounding their values when
defining a new channel, or altering an existing channel, using
runmqsc. COMPHDR( NONE ) or COMPHDR( NONE) COMPHDR(NONE )
fails, where COMPHDR(NONE) succeeds. Typically error AMQ8427
will be geneated by runmqsc for the failing ALTER channel or
DEFINE channel commands.

Local fix

Problem summary

****************************************************************
USERS AFFECTED:
Users using runmqsc to define/alter a channel

Platforms affected:
All Distributed (iSeries, all Unix and Windows)
****************************************************************

PROBLEM SUMMARY:
There is a problem in the parsing rule for COMPHDR and COMPMSG
values causing syntax error when spaces are used around their
values.

Problem conclusion

The parsing rule for COMPHDR and COMPMSG has been modified to
accept values with spaces around them

2033 MQRC NO MSG AVAILABLE - Middleware News

2011-02-14T07:09:00.000-08:00

2033 MQRC NO MSG AVAILABLE - Middleware News

Problem(Abstract)

You attempt to get a message from your queue. The getting application fails with the following: 2033 0x000007f1 MQRC_NO_MSG_AVAILABLE
Cause

The following are the most likely causes for MQRC 2033:

* There are no messages on the queue.
* The unit of work (UOW) for the MQPUT was not committed.
* The messages have expired.

Resolving the problem

* Consider this reason code as a normal condition and handle this condition in your getting application. Use the MQGET MQGMO_WAIT option and retry the MQGET.
o The amqsget sample programs demonstrate the use of MQGET MQGMO_WAIT.

* Verify that the putting application is committing the UOW. The current depth of the queue increments at MQPUT. However, messages are not available to the getting application until they are committed.

* Messages that have expired will be counted in the current depth of the queue and they are discarded at the point of MQGET. Expired messages are never returned to the getting application. You may want to increase your message expiry time or use unlimited expiry for your messages.

Note: There are more reasons for MQRC 2033. This documents the most common causes.

MQGET fails with MQRC 2033

Problem(Abstract)

Your WebSphere MQ for z/OS batch job puts messages to a queue. Your trigger-started program attempts to get the messages from the queue and fails with reason code

2033 0x000007f1 MQRC_NO_MSG_AVAILABLE

Cause

The batch job has not committed the unit of work.

Resolving the problem
Your batch job will determine when the unit of work is complete. Use the MQCMIT call to make messages available to getting applications, or use MQPMO_NO_SYNCPOINT (the default option on z/OS is MQPMO_SYNCPOINT).
Do not always consider MQRC_NO_MSG_AVAILABLE to be a failure. Your getting application should be designed to handle MQRC 2033, because it is a very common reason code.

A GET WAIT CAN RESULT IN MQRC=2033, ALTHOUGH MESSAGES ARE ON QUEUE.

Error description

* Application has few GET-Wait instances on a queue and messages
will be GETed by GroupID. Depending on number of messages and
the number of parallel instances, application will get 2033 RC,
although messages still existing on queue. The second/reGET is
always successful. If only one instance of the application is
used, the problem does not exist.

The following describes the scenario:
Application 1 puts 3 messages in group
C3E2D840D8C1F0F1161D6BD8551672C8C309DC2393D329CE to the request
queue, the last message having the last_msg_in_group flag
turned on (i.e the group is complete).

Application 1 then does a get on the reply, specifying this
groupid and MQGMO_ALL_MSGS_AVAILABLE. At this point there are
no messages matching the groupid on the reply queue, and so
CSQIMGC1 returns CSQI_GROUP_INCOMPLETE. This is translated to
MQRC_NO_MSG_AVAILABLE, but beause the wait interval has not
expired, this is not returned to the caller, and Application
1 is put on the getwait chain for the reply queue.

Application 2 then follows the same sequence, but for group
C3E2D840D8C1F0F115D1DCF8551672C8C309DC239539F90C. At this
point the getwaiter chain contains
Application 1->Application 2.

Application 3 then gets the 3 messages put by Application 2,
and puts them on the reply queue. Each time one of these
messages is put CSQM1PGW is called to locate a suitable waiter
interval (1s) expires, and MQRC_NO_MSG_AVAILABLE is returned
to the caller, despite the messages existing on the queue. If
the get is redriven it will find the messages and succeed.

Local fix

Problem summary

*****************************************************************
* USERS AFFECTED: All users of WebSphere MQ for z/OS V7 *
****************************************************************
* PROBLEM DESCRIPTION: When using MQGMO_ALL_MSGS_AVAILABLE and *
* message grouping, MQRC 2033 *
* (MQRC_NO_MSG_AVAILABLE) is returned *
* even though the queue contains suitable *
* messages. *
****************************************************************
* RECOMMENDATION: *
****************************************************************
The problem is in the handling of getwaits when
MQGMO_ALL_MSGS_AVAILABLE and MQMO_MATCH_GROUP_ID is used.
Specifically a group of messages (by GROUPID) arrives and causes
the wrong getwaiter to be alerted. The correct getwaiter is
never notified and eventually its getwait time expires and MQRC
2033 is returned. The wrong getwaiter does not remove the
messages from the queue as they are for the wrong group and they
remain on the queue.

Problem conclusion

* CSQMGSGW has been changed to check for correct GROUPID when
alerting a getwaiter who has specified MQGMO_ALL_MSGS_AVAILABLE
and MQMO_MATCH_GROUPID
000Y
CSQMGSGW

IBM Websphere MQ Reason Codes - Middleware News

2011-02-09T08:36:00.000-08:00

IBM Websphere MQ Reason Codes - Middleware News

# 0 (0000) (RC0000): MQRC_NONE
# 900 (0384) (RC900): MQRC_APPL_FIRST
# 999 (03E7) (RC999): MQRC_APPL_LAST
# 2001 (07D1) (RC2001): MQRC_ALIAS_BASE_Q_TYPE_ERROR
# 2002 (07D2) (RC2002): MQRC_ALREADY_CONNECTED
# 2003 (07D3) (RC2003): MQRC_BACKED_OUT
# 2004 (07D4) (RC2004): MQRC_BUFFER_ERROR
# 2005 (07D5) (RC2005): MQRC_BUFFER_LENGTH_ERROR
# 2006 (07D6) (RC2006): MQRC_CHAR_ATTR_LENGTH_ERROR
# 2007 (07D7) (RC2007): MQRC_CHAR_ATTRS_ERROR
# 2008 (07D8) (RC2008): MQRC_CHAR_ATTRS_TOO_SHORT
# 2009 (07D9) (RC2009): MQRC_CONNECTION_BROKEN
# 2010 (07DA) (RC2010): MQRC_DATA_LENGTH_ERROR
# 2011 (07DB) (RC2011): MQRC_DYNAMIC_Q_NAME_ERROR
# 2012 (07DC) (RC2012): MQRC_ENVIRONMENT_ERROR
# 2013 (07DD) (RC2013): MQRC_EXPIRY_ERROR
# 2014 (07DE) (RC2014): MQRC_FEEDBACK_ERROR
# 2016 (07E0) (RC2016): MQRC_GET_INHIBITED
# 2017 (07E1) (RC2017): MQRC_HANDLE_NOT_AVAILABLE
# 2018 (07E2) (RC2018): MQRC_HCONN_ERROR
# 2019 (07E3) (RC2019): MQRC_HOBJ_ERROR
# 2020 (07E4) (RC2020): MQRC_INHIBIT_VALUE_ERROR
# 2021 (07E5) (RC2021): MQRC_INT_ATTR_COUNT_ERROR
# 2022 (07E6) (RC2022): MQRC_INT_ATTR_COUNT_TOO_SMALL
# 2023 (07E7) (RC2023): MQRC_INT_ATTRS_ARRAY_ERROR
# 2024 (07E8) (RC2024): MQRC_SYNCPOINT_LIMIT_REACHED
# 2025 (07E9) (RC2025): MQRC_MAX_CONNS_LIMIT_REACHED
# 2026 (07EA) (RC2026): MQRC_MD_ERROR
# 2027 (07EB) (RC2027): MQRC_MISSING_REPLY_TO_Q
# 2029 (07ED) (RC2029): MQRC_MSG_TYPE_ERROR
# 2030 (07EE) (RC2030): MQRC_MSG_TOO_BIG_FOR_Q
# 2031 (07EF) (RC2031): MQRC_MSG_TOO_BIG_FOR_Q_MGR
# 2033 (07F1) (RC2033): MQRC_NO_MSG_AVAILABLE
# 2034 (07F2) (RC2034): MQRC_NO_MSG_UNDER_CURSOR
# 2035 (07F3) (RC2035): MQRC_NOT_AUTHORIZED
# 2036 (07F4) (RC2036): MQRC_NOT_OPEN_FOR_BROWSE
# 2037 (07F5) (RC2037): MQRC_NOT_OPEN_FOR_INPUT
# 2038 (07F6) (RC2038): MQRC_NOT_OPEN_FOR_INQUIRE
# 2039 (07F7) (RC2039): MQRC_NOT_OPEN_FOR_OUTPUT
# 2040 (07F8) (RC2040): MQRC_NOT_OPEN_FOR_SET
# 2041 (07F9) (RC2041): MQRC_OBJECT_CHANGED
# 2042 (07FA) (RC2042): MQRC_OBJECT_IN_USE
# 2043 (07FB) (RC2043): MQRC_OBJECT_TYPE_ERROR
# 2044 (07FC) (RC2044): MQRC_OD_ERROR
# 2045 (07FD) (RC2045): MQRC_OPTION_NOT_VALID_FOR_TYPE
# 2046 (07FE) (RC2046): MQRC_OPTIONS_ERROR
# 2047 (07FF) (RC2047): MQRC_PERSISTENCE_ERROR
# 2048 (0800) (RC2048): MQRC_PERSISTENT_NOT_ALLOWED
# 2049 (0801) (RC2049): MQRC_PRIORITY_EXCEEDS_MAXIMUM
# 2050 (0802) (RC2050): MQRC_PRIORITY_ERROR
# 2051 (0803) (RC2051): MQRC_PUT_INHIBITED
# 2052 (0804) (RC2052): MQRC_Q_DELETED
# 2053 (0805) (RC2053): MQRC_Q_FULL
# 2055 (0807) (RC2055): MQRC_Q_NOT_EMPTY
# 2056 (0808) (RC2056): MQRC_Q_SPACE_NOT_AVAILABLE
# 2057 (0809) (RC2057): MQRC_Q_TYPE_ERROR
# 2058 (080A) (RC2058): MQRC_Q_MGR_NAME_ERROR
# 2059 (080B) (RC2059): MQRC_Q_MGR_NOT_AVAILABLE
# 2061 (080D) (RC2061): MQRC_REPORT_OPTIONS_ERROR
# 2062 (080E) (RC2062): MQRC_SECOND_MARK_NOT_ALLOWED
# 2063 (080F) (RC2063): MQRC_SECURITY_ERROR
# 2065 (0811) (RC2065): MQRC_SELECTOR_COUNT_ERROR
# 2066 (0812) (RC2066): MQRC_SELECTOR_LIMIT_EXCEEDED
# 2067 (0813) (RC2067): MQRC_SELECTOR_ERROR
# 2068 (0814) (RC2068): MQRC_SELECTOR_NOT_FOR_TYPE
# 2069 (0815) (RC2069): MQRC_SIGNAL_OUTSTANDING
# 2070 (0816) (RC2070): MQRC_SIGNAL_REQUEST_ACCEPTED
# 2071 (0817) (RC2071): MQRC_STORAGE_NOT_AVAILABLE
# 2072 (0818) (RC2072): MQRC_SYNCPOINT_NOT_AVAILABLE
# 2075 (081B) (RC2075): MQRC_TRIGGER_CONTROL_ERROR
# 2076 (081C) (RC2076): MQRC_TRIGGER_DEPTH_ERROR
# 2077 (081D) (RC2077): MQRC_TRIGGER_MSG_PRIORITY_ERR
# 2078 (081E) (RC2078): MQRC_TRIGGER_TYPE_ERROR
# 2079 (081F) (RC2079): MQRC_TRUNCATED_MSG_ACCEPTED
# 2080 (0820) (RC2080): MQRC_TRUNCATED_MSG_FAILED
# 2082 (0822) (RC2082): MQRC_UNKNOWN_ALIAS_BASE_Q
# 2085 (0825) (RC2085): MQRC_UNKNOWN_OBJECT_NAME
# 2086 (0826) (RC2086): MQRC_UNKNOWN_OBJECT_Q_MGR
# 2087 (0827) (RC2087): MQRC_UNKNOWN_REMOTE_Q_MGR
# 2090 (082A) (RC2090): MQRC_WAIT_INTERVAL_ERROR
# 2091 (082B) (RC2091): MQRC_XMIT_Q_TYPE_ERROR
# 2092 (082C) (RC2092): MQRC_XMIT_Q_USAGE_ERROR
# 2093 (082D) (RC2093): MQRC_NOT_OPEN_FOR_PASS_ALL
# 2094 (082E) (RC2094): MQRC_NOT_OPEN_FOR_PASS_IDENT
# 2095 (082F) (RC2095): MQRC_NOT_OPEN_FOR_SET_ALL
# 2096 (0830) (RC2096): MQRC_NOT_OPEN_FOR_SET_IDENT
# 2097 (0831) (RC2097): MQRC_CONTEXT_HANDLE_ERROR
# 2098 (0832) (RC2098): MQRC_CONTEXT_NOT_AVAILABLE
# 2099 (0833) (RC2099): MQRC_SIGNAL1_ERROR
# 2100 (0834) (RC2100): MQRC_OBJECT_ALREADY_EXISTS
# 2101 (0835) (RC2101): MQRC_OBJECT_DAMAGED
# 2102 (0836) (RC2102): MQRC_RESOURCE_PROBLEM
# 2103 (0837) (RC2103): MQRC_ANOTHER_Q_MGR_CONNECTED
# 2104 (0838) (RC2104): MQRC_UNKNOWN_REPORT_OPTION
# 2105 (0839) (RC2105): MQRC_STORAGE_CLASS_ERROR
# 2106 (083A) (RC2106): MQRC_COD_NOT_VALID_FOR_XCF_Q
# 2107 (083B) (RC2107): MQRC_XWAIT_CANCELED
# 2108 (083C) (RC2108): MQRC_XWAIT_ERROR
# 2109 (083D) (RC2109): MQRC_SUPPRESSED_BY_EXIT
# 2110 (083E) (RC2110): MQRC_FORMAT_ERROR
# 2111 (083F) (RC2111): MQRC_SOURCE_CCSID_ERROR
# 2112 (0840) (RC2112): MQRC_SOURCE_INTEGER_ENC_ERROR
# 2113 (0841) (RC2113): MQRC_SOURCE_DECIMAL_ENC_ERROR
# 2114 (0842) (RC2114): MQRC_SOURCE_FLOAT_ENC_ERROR
# 2115 (0843) (RC2115): MQRC_TARGET_CCSID_ERROR
# 2116 (0844) (RC2116): MQRC_TARGET_INTEGER_ENC_ERROR
# 2117 (0845) (RC2117): MQRC_TARGET_DECIMAL_ENC_ERROR
# 2118 (0846) (RC2118): MQRC_TARGET_FLOAT_ENC_ERROR
# 2119 (0847) (RC2119): MQRC_NOT_CONVERTED
# 2120 (0848) (RC2120): MQRC_CONVERTED_MSG_TOO_BIG
# 2121 (0849) (RC2121): MQRC_NO_EXTERNAL_PARTICIPANTS
# 2122 (084A) (RC2122): MQRC_PARTICIPANT_NOT_AVAILABLE
# 2123 (084B) (RC2123): MQRC_OUTCOME_MIXED
# 2124 (084C) (RC2124): MQRC_OUTCOME_PENDING
# 2125 (084D) (RC2125): MQRC_BRIDGE_STARTED
# 2126 (084E) (RC2126): MQRC_BRIDGE_STOPPED
# 2127 (084F) (RC2127): MQRC_ADAPTER_STORAGE_SHORTAGE
# 2128 (0850) (RC2128): MQRC_UOW_IN_PROGRESS
# 2129 (0851) (RC2129): MQRC_ADAPTER_CONN_LOAD_ERROR
# 2130 (0852) (RC2130): MQRC_ADAPTER_SERV_LOAD_ERROR
# 2131 (0853) (RC2131): MQRC_ADAPTER_DEFS_ERROR
# 2132 (0854) (RC2132): MQRC_ADAPTER_DEFS_LOAD_ERROR
# 2133 (0855) (RC2133): MQRC_ADAPTER_CONV_LOAD_ERROR
# 2134 (0856) (RC2134): MQRC_BO_ERROR
# 2135 (0857) (RC2135): MQRC_DH_ERROR
# 2136 (0858) (RC2136): MQRC_MULTIPLE_REASONS
# 2137 (0859) (RC2137): MQRC_OPEN_FAILED
# 2138 (085A) (RC2138): MQRC_ADAPTER_DISC_LOAD_ERROR
# 2139 (085B) (RC2139): MQRC_CNO_ERROR
# 2140 (085C) (RC2140): MQRC_CICS_WAIT_FAILED
# 2141 (085D) (RC2141): MQRC_DLH_ERROR
# 2142 (085E) (RC2142): MQRC_HEADER_ERROR
# 2143 (085F) (RC2143): MQRC_SOURCE_LENGTH_ERROR
# 2144 (0860) (RC2144): MQRC_TARGET_LENGTH_ERROR
# 2145 (0861) (RC2145): MQRC_SOURCE_BUFFER_ERROR
# 2146 (0862) (RC2146): MQRC_TARGET_BUFFER_ERROR
# 2148 (0864) (RC2148): MQRC_IIH_ERROR
# 2149 (0865) (RC2149): MQRC_PCF_ERROR
# 2150 (0866) (RC2150): MQRC_DBCS_ERROR
# 2152 (0868) (RC2152): MQRC_OBJECT_NAME_ERROR
# 2153 (0869) (RC2153): MQRC_OBJECT_Q_MGR_NAME_ERROR
# 2154 (086A) (RC2154): MQRC_RECS_PRESENT_ERROR
# 2155 (086B) (RC2155): MQRC_OBJECT_RECORDS_ERROR
# 2156 (086C) (RC2156): MQRC_RESPONSE_RECORDS_ERROR
# 2157 (086D) (RC2157): MQRC_ASID_MISMATCH
# 2158 (086E) (RC2158): MQRC_PMO_RECORD_FLAGS_ERROR
# 2159 (086F) (RC2159): MQRC_PUT_MSG_RECORDS_ERROR
# 2160 (0870) (RC2160): MQRC_CONN_ID_IN_USE
# 2161 (0871) (RC2161): MQRC_Q_MGR_QUIESCING
# 2162 (0872) (RC2162): MQRC_Q_MGR_STOPPING
# 2163 (0873) (RC2163): MQRC_DUPLICATE_RECOV_COORD
# 2173 (087D) (RC2173): MQRC_PMO_ERROR
# 2182 (0886) (RC2173): MQRC_API_EXIT_NOT_FOUND
# 2183 (0887) (RC2183): MQRC_API_EXIT_LOAD_ERROR
# 2184 (0888) (RC2184): MQRC_REMOTE_Q_NAME_ERROR
# 2185 (0889) (RC2185): MQRC_INCONSISTENT_PERSISTENCE
# 2186 (088A) (RC2186): MQRC_GMO_ERROR
# 2187 (088B) (RC2187): MQRC_CICS_BRIDGE_RESTRICTION
# 2188 (088C) (RC2188): MQRC_STOPPED_BY_CLUSTER_EXIT
# 2189 (088D) (RC2189): MQRC_CLUSTER_RESOLUTION_ERROR
# 2190 (088E) (RC2190): MQRC_CONVERTED_STRING_TOO_BIG
# 2191 (088F) (RC2191): MQRC_TMC_ERROR
# 2192 (0890) (RC2192): MQRC_PAGESET_FULL
# 2192 (0890) (RC2192): MQRC_STORAGE_MEDIUM_FULL
# 2193 (0891) (RC2193): MQRC_PAGESET_ERROR
# 2194 (0892) (RC2194): MQRC_NAME_NOT_VALID_FOR_TYPE
# 2195 (0893) (RC2195): MQRC_UNEXPECTED_ERROR
# 2196 (0894) (RC2196): MQRC_UNKNOWN_XMIT_Q
# 2197 (0895) (RC2197): MQRC_UNKNOWN_DEF_XMIT_Q
# 2198 (0896) (RC2198): MQRC_DEF_XMIT_Q_TYPE_ERROR
# 2199 (0897) (RC2199): MQRC_DEF_XMIT_Q_USAGE_ERROR
# 2201 (0899) (RC2201): MQRC_NAME_IN_USE
# 2202 (089A) (RC2202): MQRC_CONNECTION_QUIESCING
# 2203 (089B) (RC2203): MQRC_CONNECTION_STOPPING
# 2204 (089C) (RC2204): MQRC_ADAPTER_NOT_AVAILABLE
# 2206 (089E) (RC2206): MQRC_MSG_ID_ERROR
# 2207 (089F) (RC2207): MQRC_CORREL_ID_ERROR
# 2208 (08A0) (RC2208): MQRC_FILE_SYSTEM_ERROR
# 2209 (08A1) (RC2209): MQRC_NO_MSG_LOCKED
# 2210 (08A2) (RC2210): MQRC_SOAP_DOTNET_ERROR
# 2211 (08A3) (RC2211): MQRC_SOAP_AXIS_ERROR
# 2212 (08A4) (RC2212): MQRC_SOAP_URL_ERROR
# 2217 (08A9) (RC2217): MQRC_CONNECTION_NOT_AUTHORIZED
# 2218 (08AA) (RC2218): MQRC_MSG_TOO_BIG_FOR_CHANNEL
# 2219 (08AB) (RC2219): MQRC_CALL_IN_PROGRESS
# 2220 (08AC) (RC2220): MQRC_RMH_ERROR
# 2222 (08AE) (RC2222): MQRC_Q_MGR_ACTIVE
# 2223 (08AF) (RC2223): MQRC_Q_MGR_NOT_ACTIVE
# 2224 (08B0) (RC2224): MQRC_Q_DEPTH_HIGH
# 2225 (08B1) (RC2225): MQRC_Q_DEPTH_LOW
# 2226 (08B2) (RC2226): MQRC_Q_SERVICE_INTERVAL_HIGH
# 2227 (08B3) (RC2227): MQRC_Q_SERVICE_INTERVAL_OK
# 2228 (08B4) (RC2228): MQRC_RFH_HEADER_FIELD_ERROR
# 2229 (08B5) (RC2229): MQRC_RAS_PROPERTY_ERROR
# 2232 (08B8) (RC2232): MQRC_UNIT_OF_WORK_NOT_STARTED
# 2233 (08B9) (RC2233): MQRC_CHANNEL_AUTO_DEF_OK
# 2234 (08BA) (RC2234): MQRC_CHANNEL_AUTO_DEF_ERROR
# 2235 (08BB) (RC2235): MQRC_CFH_ERROR
# 2236 (08BC) (RC2236): MQRC_CFIL_ERROR
# 2237 (08BD) (RC2237): MQRC_CFIN_ERROR
# 2238 (08BE) (RC2238): MQRC_CFSL_ERROR
# 2239 (08BF) (RC2239): MQRC_CFST_ERROR
# 2241 (08C1) (RC2241): MQRC_INCOMPLETE_GROUP
# 2242 (08C2) (RC2242): MQRC_INCOMPLETE_MSG
# 2243 (08C3) (RC2243): MQRC_INCONSISTENT_CCSIDS
# 2244 (08C4) (RC2244): MQRC_INCONSISTENT_ENCODINGS
# 2245 (08C5) (RC2245): MQRC_INCONSISTENT_UOW
# 2246 (08C6) (RC2246): MQRC_INVALID_MSG_UNDER_CURSOR
# 2247 (08C7) (RC2247): MQRC_MATCH_OPTIONS_ERROR
# 2248 (08C8) (RC2248): MQRC_MDE_ERROR
# 2249 (08C9) (RC2249): MQRC_MSG_FLAGS_ERROR
# 2250 (08CA) (RC2250): MQRC_MSG_SEQ_NUMBER_ERROR
# 2251 (08CB) (RC2251): MQRC_OFFSET_ERROR
# 2252 (08CC) (RC2252): MQRC_ORIGINAL_LENGTH_ERROR
# 2253 (08CD) (RC2253): MQRC_SEGMENT_LENGTH_ZERO
# 2255 (08CF) (RC2255): MQRC_UOW_NOT_AVAILABLE
# 2256 (08D0) (RC2256): MQRC_WRONG_GMO_VERSION
# 2257 (08D1) (RC2257): MQRC_WRONG_MD_VERSION
# 2258 (08D2) (RC2258): MQRC_GROUP_ID_ERROR
# 2259 (08D3) (RC2259): MQRC_INCONSISTENT_BROWSE
# 2260 (08D4) (RC2260): MQRC_XQH_ERROR
# 2261 (08D5) (RC2261): MQRC_SRC_ENV_ERROR
# 2262 (08D6) (RC2262): MQRC_SRC_NAME_ERROR
# 2263 (08D7) (RC2263): MQRC_DEST_ENV_ERROR
# 2264 (08D8) (RC2264): MQRC_DEST_NAME_ERROR
# 2265 (08D9) (RC2265): MQRC_TM_ERROR
# 2266 (08DA) (RC2266): MQRC_CLUSTER_EXIT_ERROR
# 2267 (08DB) (RC2267): MQRC_CLUSTER_EXIT_LOAD_ERROR
# 2268 (08DC) (RC2268): MQRC_CLUSTER_PUT_INHIBITED
# 2269 (08DD) (RC2269): MQRC_CLUSTER_RESOURCE_ERROR
# 2270 (08DE) (RC2270): MQRC_NO_DESTINATIONS_AVAILABLE
# 2271 (08DF) (RC2271): MQRC_CONN_TAG_IN_USE
# 2272 (08E0) (RC2272): MQRC_PARTIALLY_CONVERTED
# 2273 (08E1) (RC2273): MQRC_CONNECTION_ERROR
# 2274 (08E2) (RC2274): MQRC_OPTION_ENVIRONMENT_ERROR
# 2277 (08E5) (RC2277): MQRC_CD_ERROR
# 2278 (08E6) (RC2278): MQRC_CLIENT_CONN_ERROR
# 2279 (08E7) (RC2279): MQRC_CHANNEL_STOPPED_BY_USER
# 2280 (08E8) (RC2280): MQRC_HCONFIG_ERROR
# 2281 (08E9) (RC2281): MQRC_FUNCTION_ERROR
# 2282 (08EA) (RC2282): MQRC_CHANNEL_STARTED
# 2283 (08EB) (RC2283): MQRC_CHANNEL_STOPPED
# 2284 (08EC) (RC2284): MQRC_CHANNEL_CONV_ERROR
# 2285 (08ED) (RC2285): MQRC_SERVICE_NOT_AVAILABLE
# 2286 (08EE) (RC2286): MQRC_INITIALIZATION_FAILED
# 2287 (08EF) (RC2287): MQRC_TERMINATION_FAILED
# 2288 (08F0) (RC2288): MQRC_UNKNOWN_Q_NAME
# 2289 (08F1) (RC2289): MQRC_SERVICE_ERROR
# 2290 (08F2) (RC2290): MQRC_Q_ALREADY_EXISTS
# 2291 (08F3) (RC2291): MQRC_USER_ID_NOT_AVAILABLE
# 2292 (08F4) (RC2292): MQRC_UNKNOWN_ENTITY
# 2294 (08F6) (RC2294): MQRC_UNKNOWN_REF_OBJECT
# 2295 (08F7) (RC2295): MQRC_CHANNEL_ACTIVATED
# 2296 (08F8) (RC2296): MQRC_CHANNEL_NOT_ACTIVATED
# 2297 (08F9) (RC2297): MQRC_UOW_CANCELED
# 2298 (08FA) (RC2298): MQRC_FUNCTION_NOT_SUPPORTED
# 2299 (08FB) (RC2299): MQRC_SELECTOR_TYPE_ERROR
# 2300 (08FC) (RC2300): MQRC_COMMAND_TYPE_ERROR
# 2301 (08FD) (RC2301): MQRC_MULTIPLE_INSTANCE_ERROR
# 2302 (08FE) (RC2302): MQRC_SYSTEM_ITEM_NOT_ALTERABLE
# 2303 (08FF) (RC2303): MQRC_BAG_CONVERSION_ERROR
# 2304 (0900) (RC2304): MQRC_SELECTOR_OUT_OF_RANGE
# 2305 (0901) (RC2305): MQRC_SELECTOR_NOT_UNIQUE
# 2306 (0902) (RC2306): MQRC_INDEX_NOT_PRESENT
# 2307 (0903) (RC2307): MQRC_STRING_ERROR
# 2308 (0904) (RC2308): MQRC_ENCODING_NOT_SUPPORTED
# 2309 (0905) (RC2309): MQRC_SELECTOR_NOT_PRESENT
# 2310 (0906) (RC2310): MQRC_OUT_SELECTOR_ERROR
# 2311 (0907) (RC2311): MQRC_STRING_TRUNCATED
# 2312 (0908) (RC2312): MQRC_SELECTOR_WRONG_TYPE
# 2313 (0909) (RC2313): MQRC_INCONSISTENT_ITEM_TYPE
# 2314 (090A) (RC2314): MQRC_INDEX_ERROR
# 2315 (090B) (RC2315): MQRC_SYSTEM_BAG_NOT_ALTERABLE
# 2316 (090C) (RC2316): MQRC_ITEM_COUNT_ERROR
# 2317 (090D) (RC2317): MQRC_FORMAT_NOT_SUPPORTED
# 2318 (090E) (RC2318): MQRC_SELECTOR_NOT_SUPPORTED
# 2319 (090F) (RC2319): MQRC_ITEM_VALUE_ERROR
# 2320 (0910) (RC2320): MQRC_HBAG_ERROR
# 2321 (0911) (RC2321): MQRC_PARAMETER_MISSING
# 2322 (0912) (RC2322): MQRC_CMD_SERVER_NOT_AVAILABLE
# 2323 (0913) (RC2323): MQRC_STRING_LENGTH_ERROR
# 2324 (0914) (RC2324): MQRC_INQUIRY_COMMAND_ERROR
# 2325 (0915) (RC2325): MQRC_NESTED_BAG_NOT_SUPPORTED
# 2326 (0916) (RC2326): MQRC_BAG_WRONG_TYPE
# 2327 (0917) (RC2327): MQRC_ITEM_TYPE_ERROR
# 2328 (0918) (RC2328): MQRC_SYSTEM_BAG_NOT_DELETABLE
# 2329 (0919) (RC2329): MQRC_SYSTEM_ITEM_NOT_DELETABLE
# 2330 (091A) (RC2330): MQRC_CODED_CHAR_SET_ID_ERROR
# 2331 (091B) (RC2331): MQRC_MSG_TOKEN_ERROR
# 2332 (091C) (RC2332): MQRC_MISSING_WIH
# 2333 (091D) (RC2333): MQRC_WIH_ERROR
# 2334 (091E) (RC2334): MQRC_RFH_ERROR
# 2335 (091F) (RC2335): MQRC_RFH_STRING_ERROR
# 2336 (0920) (RC2336): MQRC_RFH_COMMAND_ERROR
# 2337 (0921) (RC2337): MQRC_RFH_PARM_ERROR
# 2338 (0922) (RC2338): MQRC_RFH_DUPLICATE_PARM
# 2339 (0923) (RC2339): MQRC_RFH_PARM_MISSING
# 2340 (0924) (RC2340): MQRC_CHAR_CONVERSION_ERROR
# 2341 (0925) (RC2341): MQRC_UCS2_CONVERSION_ERROR
# 2342 (0926) (RC2342): MQRC_DB2_NOT_AVAILABLE
# 2343 (0927) (RC2343): MQRC_OBJECT_NOT_UNIQUE
# 2344 (0928) (RC2344): MQRC_CONN_TAG_NOT_RELEASED
# 2345 (0929) (RC2345): MQRC_CF_NOT_AVAILABLE
# 2346 (092A) (RC2346): MQRC_CF_STRUC_IN_USE
# 2347 (092B) (RC2347): MQRC_CF_STRUC_LIST_HDR_IN_USE
# 2348 (092C) (RC2348): MQRC_CF_STRUC_AUTH_FAILED
# 2349 (092D) (RC2349): MQRC_CF_STRUC_ERROR
# 2350 (092E) (RC2350): MQRC_CONN_TAG_NOT_USABLE
# 2351 (092F) (RC2351): MQRC_GLOBAL_UOW_CONFLICT
# 2352 (0930) (RC2352): MQRC_LOCAL_UOW_CONFLICT
# 2353 (0931) (RC2353): MQRC_HANDLE_IN_USE_FOR_UOW
# 2354 (0932) (RC2354): MQRC_UOW_ENLISTMENT_ERROR
# 2355 (0933) (RC2355): MQRC_UOW_MIX_NOT_SUPPORTED
# 2356 (0934) (RC2356): MQRC_WXP_ERROR
# 2357 (0935) (RC2357): MQRC_CURRENT_RECORD_ERROR
# 2358 (0936) (RC2358): MQRC_NEXT_OFFSET_ERROR
# 2359 (0937) (RC2359): MQRC_NO_RECORD_AVAILABLE
# 2360 (0938) (RC2360): MQRC_OBJECT_LEVEL_INCOMPATIBLE
# 2361 (0939) (RC2361): MQRC_NEXT_RECORD_ERROR
# 2362 (093A) (RC2362): MQRC_BACKOUT_THRESHOLD_REACHED
# 2363 (093B) (RC2363): MQRC_MSG_NOT_MATCHED
# 2364 (093C) (RC2364): MQRC_JMS_FORMAT_ERROR
# 2365 (093D) (RC2365): MQRC_SEGMENTS_NOT_SUPPORTED
# 2366 (093E) (RC2366): MQRC_WRONG_CF_LEVEL
# 2367 (093F) (RC2367): MQRC_CONFIG_CREATE_OBJECT
# 2368 (0940) (RC2368): MQRC_CONFIG_CHANGE_OBJECT
# 2369 (0941) (RC2369): MQRC_CONFIG_DELETE_OBJECT
# 2370 (0942) (RC2370): MQRC_CONFIG_REFRESH_OBJECT
# 2371 (0943) (RC2371): MQRC_CHANNEL_SSL_ERROR
# 2373 (0945) (RC2373): MQRC_CF_STRUC_FAILED
# 2374 (0946) (RC2374): MQRC_API_EXIT_ERROR
# 2375 (0947) (RC2375): MQRC_API_EXIT_INIT_ERROR
# 2376 (0948) (RC2376): MQRC_API_EXIT_TERM_ERROR
# 2377 (0949) (RC2377): MQRC_EXIT_REASON_ERROR
# 2378 (094A) (RC2378): MQRC_RESERVED_VALUE_ERROR
# 2379 (094B) (RC2379): MQRC_NO_DATA_AVAILABLE
# 2380 (094C) (RC2380): MQRC_SCO_ERROR
# 2381 (094D) (RC2381): MQRC_KEY_REPOSITORY_ERROR
# 2382 (094E) (RC2382): MQRC_CRYPTO_HARDWARE_ERROR
# 2383 (094F) (RC2383): MQRC_AUTH_INFO_REC_COUNT_ERROR
# 2384 (0950) (RC2384): MQRC_AUTH_INFO_REC_ERROR
# 2385 (0951) (RC2385): MQRC_AIR_ERROR
# 2386 (0952) (RC2386): MQRC_AUTH_INFO_TYPE_ERROR
# 2387 (0953) (RC2387): MQRC_AUTH_INFO_CONN_NAME_ERROR
# 2388 (0954) (RC2388): MQRC_LDAP_USER_NAME_ERROR
# 2389 (0955) (RC2389): MQRC_LDAP_USER_NAME_LENGTH_ERR
# 2390 (0956) (RC2390): MQRC_LDAP_PASSWORD_ERROR
# 2391 (0957) (RC2391): MQRC_SSL_ALREADY_INITIALIZED
# 2392 (0958) (RC2392): MQRC_SSL_CONFIG_ERROR
# 2393 (0959) (RC2393): MQRC_SSL_INITIALIZATION_ERROR
# 2394 (095A) (RC2394): MQRC_Q_INDEX_TYPE_ERROR
# 2395 (095B) (RC2395): MQRC_CFBS_ERROR
# 2396 (095C) (RC2396): MQRC_SSL_NOT_ALLOWED
# 2397 (095D) (RC2397): MQRC_JSSE_ERROR
# 2398 (095E) (RC2398): MQRC_SSL_PEER_NAME_MISMATCH
# 2399 (095F) (RC2399): MQRC_SSL_PEER_NAME_ERROR
# 2400 (0960) (RC2400): MQRC_UNSUPPORTED_CIPHER_SUITE
# 2401 (0961) (RC2401): MQRC_SSL_CERTIFICATE_REVOKED
# 2402 (0962) (RC2402): MQRC_SSL_CERT_STORE_ERROR
# 2406 (0966) (RC2406): MQRC_CLIENT_EXIT_LOAD_ERROR
# 2407 (0967) (RC2407): MQRC_CLIENT_EXIT_ERROR
# 2409 (0969) (RC2409): MQRC_SSL_KEY_RESET_ERROR
# 2411 (096B) (RC2411): MQRC_LOGGER_STATUS
# 2412 (096C) (RC2412): MQRC_COMMAND_MQSC
# 2413 (096D) (RC2413): MQRC_COMMAND_PCF
# 2414 (096E) (RC2414): MQRC_CFIF_ERROR
# 2415 (096F) (RC2415): MQRC_CFSF_ERROR
# 2416 (0970) (RC2416): MQRC_CFGR_ERROR
# 2417 (0971) (RC2417): MQRC_MSG_NOT_ALLOWED_IN_GROUP
# 2418 (0972) (RC2418): MQRC_FILTER_OPERATOR_ERROR
# 2419 (0973) (RC2419): MQRC_NESTED_SELECTOR_ERROR
# 2420 (0974) (RC2420): MQRC_EPH_ERROR
# 2421 (0975) (RC2421): MQRC_RFH_FORMAT_ERROR
# 2422 (0976) (RC2422): MQRC_CFBF_ERROR
# 2423 (0977) (RC2423): MQRC_CLIENT_CHANNEL_CONFLICT
# 2424 (0978) (RC2424): MQRC_SD_ERROR
# 2425 (0979) (RC2425): MQRC_TOPIC_STRING_ERROR
# 2426 (097A) (RC2426): MQRC_STS_ERROR
# 2428 (097C) (RC2428): MQRC_NO_SUBSCRIPTION
# 2429 (097D) (RC2429): MQRC_SUBSCRIPTION_IN_USE
# 2430 (097E) (RC2430): MQRC_STAT_TYPE_ERROR
# 2431 (097F) (RC2431): MQRC_SUB_USER_DATA_ERROR
# 2432 (0980) (RC2432): MQRC_SUB_ALREADY_EXISTS
# 2434 (0982) (RC2434): MQRC_IDENTITY_MISMATCH
# 2435 (0983) (RC2435): MQRC_ALTER_SUB_ERROR
# 2436 (0984) (RC2436): MQRC_DURABILITY_NOT_ALLOWED
# 2437 (0985) (RC2437): MQRC_NO_RETAINED_MSG
# 2438 (0986) (RC2438): MQRC_SRO_ERROR
# 2440 (0988) (RC2440): MQRC_SUB_NAME_ERROR
# 2441 (0989) (RC2441): MQRC_OBJECT_STRING_ERROR
# 2442 (098A) (RC2442): MQRC_PROPERTY_NAME_ERROR
# 2443 (098B) (RC2443): MQRC_SEGMENTATION_NOT_ALLOWED
# 2444 (098C) (RC2444): MQRC_CBD_ERROR
# 2445 (098D) (RC2445): MQRC_CTLO_ERROR
# 2446 (098E) (RC2446): MQRC_NO_CALLBACKS_ACTIVE
# 2448 (0990) (RC2448): MQRC_CALLBACK_NOT_REGISTERED
# 2449 (0991) (RC2449): MQRC_MQCTL_ALREADY_STARTED
# 2457 (0999) (RC2457): MQRC_OPTIONS_CHANGED
# 2458 (099A) (RC2458): MQRC_READ_AHEAD_MSGS
# 2459 (099B) (RC2459): MQRC_SELECTOR_SYNTAX_ERROR
# 2460 (099C) (RC2460): MQRC_HMSG_ERROR
# 2461 (099D) (RC2461): MQRC_CMHO_ERROR
# 2462 (099E) (RC2462): MQRC_DMHO_ERROR
# 2463 (099F) (RC2463): MQRC_SMPO_ERROR
# 2464 (09A0) (RC2464): MQRC_IMPO_ERROR
# 2465 (09A1) (RC2465): MQRC_PROPERTY_NAME_TOO_BIG
# 2466 (09A2) (RC2466): MQRC_PROP_VALUE_NOT_CONVERTED
# 2467 (09A3) (RC2467): MQRC_PROP_TYPE_NOT_SUPPORTED
# 2469 (09A5) (RC2469): MQRC_PROPERTY_VALUE_TOO_BIG
# 2470 (09A6) (RC2470): MQRC_PROP_CONV_NOT_SUPPORTED
# 2471 (09A7) (RC2471): MQRC_PROPERTY_NOT_AVAILABLE
# 2472 (09A8) (RC2472): MQRC_PROP_NUMBER_FORMAT_ERROR
# 2473 (09A9) (RC2473): MQRC_PROPERTY_TYPE_ERROR
# 2478 (09AE) (RC2478): MQRC_PROPERTIES_TOO_BIG
# 2479 (09AF) (RC2479): MQRC_PUT_NOT_RETAINED
# 2480 (09B0) (RC2480): MQRC_ALIAS_TARGTYPE_CHANGED
# 2481 (09B1) (RC2481): MQRC_DMPO_ERROR
# 2482 (09B2) (RC2482): MQRC_PD_ERROR
# 2483 (09B3) (RC2483): MQRC_CALLBACK_TYPE_ERROR
# 2484 (09B4) (RC2484): MQRC_CBD_OPTIONS_ERROR
# 2485 (09B5) (RC2485): MQRC_MAX_MSG_LENGTH_ERROR
# 2486 (09B6) (RC2486): MQRC_CALLBACK_ROUTINE_ERROR
# 2487 (09B7) (RC2487): MQRC_CALLBACK_LINK_ERROR
# 2488 (09B8) (RC2488): MQRC_OPERATION_ERROR
# 2489 (09B9) (RC2489): MQRC_BMHO_ERROR
# 2490 (09BA) (RC2490): MQRC_UNSUPPORTED_PROPERTY
# 2492 (09BC) (RC2492): MQRC_PROP_NAME_NOT_CONVERTED
# 2494 (09BE) (RC2494): MQRC_GET_ENABLED
# 2495 (09BF) (RC2495): MQRC_MODULE_NOT_FOUND
# 2496 (09C0) (RC2496): MQRC_MODULE_INVALID
# 2497 (09C1) (RC2497): MQRC_MODULE_ENTRY_NOT_FOUND
# 2498 (09C2) (RC2498): MQRC_MIXED_CONTENT_NOT_ALLOWED
# 2499 (09C3) (RC2499): MQRC_MSG_HANDLE_IN_USE
# 2500 (09C4) (RC2500): MQRC_HCONN_ASYNC_ACTIVE
# 2501 (09C5) (RC2501): MQRC_MHBO_ERROR
# 2502 (09C6) (RC2502): MQRC_PUBLICATION_FAILURE
# 2503 (09C7) (RC2503): MQRC_SUB_INHIBITED
# 2504 (09C8) (RC2504): MQRC_SELECTOR_ALWAYS_FALSE
# 2507 (09CB) (RC2507): MQRC_XEPO_ERROR
# 2509 (09CD) (RC2509): MQRC_DURABILITY_NOT_ALTERABLE
# 2510 (09CE) (RC2510): MQRC_TOPIC_NOT_ALTERABLE
# 2512 (09D0) (RC2512): MQRC_SUBLEVEL_NOT_ALTERABLE
# 2513 (09D1) (RC2513): MQRC_PROPERTY_NAME_LENGTH_ERR
# 2514 (09D2) (RC2514): MQRC_DUPLICATE_GROUP_SUB
# 2515 (09D3) (RC2515): MQRC_GROUPING_NOT_ALTERABLE
# 2516 (09D4) (RC2516): MQRC_SELECTOR_INVALID_FOR_TYPE
# 2517 (09D5) (RC2517): MQRC_HOBJ_QUIESCED
# 2518 (09D6) (RC2518): MQRC_HOBJ_QUIESCED_NO_MSGS
# 2519 (09D7) (RC2519): MQRC_SELECTION_STRING_ERROR
# 2520 (09D8) (RC2520): MQRC_RES_OBJECT_STRING_ERROR
# 2521 (09D9) (RC2521): MQRC_CONNECTION_SUSPENDED
# 2522 (09DA) (RC2522): MQRC_INVALID_DESTINATION
# 2523 (09DB) (RC2523): MQRC_INVALID_SUBSCRIPTION
# 2524 (09DC) (RC2524): MQRC_SELECTOR_NOT_ALTERABLE
# 2525 (09DD) (RC2525): MQRC_RETAINED_MSG_Q_ERROR
# 2526 (09DE) (RC2526): MQRC_RETAINED_NOT_DELIVERED
# 2527 (09DF) (RC2527): MQRC_RFH_RESTRICTED_FORMAT_ERR
# 2528 (09E0) (RC2528): MQRC_CONNECTION_STOPPED
# 2529 (09E1) (RC2529): MQRC_ASYNC_UOW_CONFLICT
# 2530 (09E2) (RC2530): MQRC_ASYNC_XA_CONFLICT
# 2531 (09E3) (RC2531): MQRC_PUBSUB_INHIBITED
# 2532 (09E4) (RC2532): MQRC_MSG_HANDLE_COPY_FAILURE
# 2533 (09E5) (RC2533): MQRC_DEST_CLASS_NOT_ALTERABLE
# 2534 (09E6) (RC2534): MQRC_OPERATION_NOT_ALLOWED
# 2535 (09E7) (RC2535): MQRC_ACTION_ERROR
# 2537 (09E9) (RC2537): MQRC_CHANNEL_NOT_AVAILABLE
# 2538 (09EA) (RC2538): MQRC_HOST_NOT_AVAILABLE
# 2539 (09EB) (RC2539): MQRC_CHANNEL_CONFIG_ERROR
# 2540 (09EC) (RC2540): MQRC_UNKNOWN_CHANNEL_NAME
# 2541 (09ED) (RC2541): MQRC_LOOPING_PUBLICATION
# 2543 (09EF) (RC2543): MQRC_STANDBY_Q_MGR
# 2544 (09F0) (RC2544): MQRC_RECONNECTING
# 2545 (09F1) (RC2545): MQRC_RECONNECTED
# 2546 (09F2) (RC2546): MQRC_RECONNECT_QMID_MISMATCH
# 2547 (09F3) (RC2547): MQRC_RECONNECT_INCOMPATIBLE
# 2548 (09F4) (RC2548): MQRC_RECONNECT_FAILED
# 2549 (09F5) (RC2549): MQRC_CALL_INTERRUPTED
# 2550 (09F6) (RC2550): MQRC_NO_SUBS_MATCHED
# 2551 (09F7) (RC2551): MQRC_SELECTION_NOT_AVAILABLE
# 2552 (09F8) (RC2552): MQRC_CHANNEL_SSL_WARNING
# 2553 (09F9) (RC2553): MQRC_OCSP_URL_ERROR
# 2554 (09FA) (RC2554): MQRC_CONTENT_ERROR
# 2555 (09FB) (RC2555): MQRC_RECONNECT_Q_MGR_REQD
# 2556 (09FC) (RC2556): MQRC_RECONNECT_TIMED_OUT
# 2557 (09FD) (RC2557): MQRC_PUBLISH_EXIT_ERROR
# 2570 (0A0A) (RC2570): MQRC_SSL_ALT_PROVIDER_REQUIRED
# 6100 (17D4) (RC6100): MQRC_REOPEN_EXCL_INPUT_ERROR
# 6101 (17D5) (RC6101): MQRC_REOPEN_INQUIRE_ERROR
# 6102 (17D6) (RC6102): MQRC_REOPEN_SAVED_CONTEXT_ERR
# 6103 (17D7) (RC6103): MQRC_REOPEN_TEMPORARY_Q_ERROR
# 6104 (17D8) (RC6104): MQRC_ATTRIBUTE_LOCKED
# 6105 (17D9) (RC6105): MQRC_CURSOR_NOT_VALID
# 6106 (17DA) (RC6106): MQRC_ENCODING_ERROR
# 6107 (17DB) (RC6107): MQRC_STRUC_ID_ERROR
# 6108 (17DC) (RC6108): MQRC_NULL_POINTER
# 6109 (17DD) (RC6109): MQRC_NO_CONNECTION_REFERENCE
# 6110 (17DE) (RC6110): MQRC_NO_BUFFER
# 6111 (17DF) (RC6111): MQRC_BINARY_DATA_LENGTH_ERROR
# 6112 (17E0) (RC6112): MQRC_BUFFER_NOT_AUTOMATIC
# 6113 (17E1) (RC6113): MQRC_INSUFFICIENT_BUFFER
# 6114 (17E2) (RC6114): MQRC_INSUFFICIENT_DATA
# 6115 (17E3) (RC6115): MQRC_DATA_TRUNCATED
# 6116 (17E4) (RC6116): MQRC_ZERO_LENGTH
# 6117 (17E5) (RC6117): MQRC_NEGATIVE_LENGTH
# 6118 (17E6) (RC6118): MQRC_NEGATIVE_OFFSET
# 6119 (17E7) (RC6119): MQRC_INCONSISTENT_FORMAT
# 6120 (17E8) (RC6120): MQRC_INCONSISTENT_OBJECT_STATE
# 6121 (17E9) (RC6121): MQRC_CONTEXT_OBJECT_NOT_VALID
# 6122 (17EA) (RC6122): MQRC_CONTEXT_OPEN_ERROR
# 6123 (17EB) (RC6123): MQRC_STRUC_LENGTH_ERROR
# 6124 (17EC) (RC6124): MQRC_NOT_CONNECTED
# 6125 (17ED) (RC6125): MQRC_NOT_OPEN
# 6126 (17EE) (RC6126): MQRC_DISTRIBUTION_LIST_EMPTY
# 6127 (17EF) (RC6127): MQRC_INCONSISTENT_OPEN_OPTIONS
# 6128 (17FO) (RC6128): MQRC_WRONG_VERSION
# 6129 (17F1) (RC6129): MQRC_REFERENC

2010 MQRC_DATA_LENGTH_ERROR when sending MQ messages larger than 4MB on client connection - Middleware News

2011-02-09T08:26:00.000-08:00

2010 MQRC_DATA_LENGTH_ERROR when sending MQ messages larger than 4MB on client connection - Middleware News

Problem(Abstract)

Your WebSphere MQ client application is trying to send messages larger than 4 MB. It receives a data length error and is unable to send the messages.

Cause

The client channel did not have large enough MAXMSGL specified.

Resolving the problem

Increase the MAXMSGL attribute for the following:

* SVRCONN channel
* CLNTCONN channel
* Queue Manager
* Queue

The MAXMSGL attribute for theses MQ objects must be large enough to handle your largest messages. However, for this value to be picked up in a client channel it must be accepted by both the client and the server.

One way to do this is to define it in both the CLNTCONN channel definition and the SVRCONN channel definition using runmqsc on the server. Then copy the amqclchl.tab file from your server to the client machine, so the client can use that CLNTCONN channel definition with the new MAXMSGL value.

It is possible to put larger messages if your client application passes a channel definition structure to MQCONNX instead of calling the regular MQCONN call. There is a sample program called amqscnxc which shows how to use the MQCONNX call for specifying client connection information on the CLNTCONN channel definition.

THE WMQ JAVA CLIENT THROWS A MQRC 2010 WHEN THE SPECIFIED BUFFERLENGTH IS LARGER THAN MAXMSGL ON THE CHANNEL - Middleware News

2011-02-09T08:14:00.000-08:00

THE WMQ JAVA CLIENT THROWS A MQRC 2010 WHEN THE SPECIFIED BUFFERLENGTH IS LARGER THAN MAXMSGL ON THE CHANNEL - Middleware News

Error description

* If a WebSphere MQ classes for Java client specifies a
BufferLength value on a MQGET call that is larger than the
value that is defined for the MaxMsgLength (MAXMSGL) on the
channel, then it must result in a reason code of 2010
MQRC_DATA_LENGTH_ERROR and the message must remain on the
queue.

The V6 WebSphere MQ classes for Java Client allows the
application to receive the message from the queue. Although the
2010 error is thrown in the V6 client, it is consumed
internally and a second MQGET is performed with the
BufferLength reduced to a value equal to the channel's
MaxMsgLength. This means only a portion of the
message is delivered to the application and the rest of the
data is lost if MQGMO_ACCEPT_TRUNCATED_MSG option has been used
in the MQGMO structure.

Under similar circumstances, a V7.0 WebSphere MQ classes for
Java client also results in a 2010 error to be thrown and
consumed internally. After the 2010 is consumed internally, a
second MQGET is performed, but with the BufferLength reduced to
a zero(0) size. The V7.0 WebSphere MQ classes for Java then
provides the receiving application a 0 bytes length message,
and a 2079 MQRC_TRUNCATED_MSG_ACCEPTED exception:

com.ibm.mq.MQException: MQJE001: Completion Code '1', Reason
'2079'.

Local fix

* Here are 3 ways to avoid this problem:

1. Specify a Buffer Length value that is less than the MAXMSGL
property of the channel.
2. Increase the MAXMSGL property on the channel to a value
greater than the BufferLength specified in the get() call.
3. Do not use the MQGMO_ACCEPT_TRUNCATED_MSG option in the
MQGMO structure.

Problem summary

****************************************************************

USERS AFFECTED:

This issue affects users of the WebSphere MQ classes for Java
(both V6 and V7.0) who do a get() with
MQGMO_ACCEPT_TRUNCATED_MSG and BufferLength specified, and with
the MAXMSGL on the channel set to a value less than this
bufferLength size.

Platforms affected:

All Distributed (iSeries, all Unix and Windows) +Java
****************************************************************

PROBLEM SUMMARY:

When a WebSphere MQ classes for Java application performed a
get() with MQGMO_ACCEPT_TRUNCATED_MSG and BufferLength
specified, when the specified BufferLength was greater than the
MAXMSGL size defined on the channel, then the following
occurred:

(a) The V6 WebSphere MQ classes for Java client performed a
second MQGET to retrieve the message of length only up to
the channel's MAXMSGL value.

(b) The V7.0 WebSphere MQ classes for Java client performed a
second MQGET to retrieve a message of 0 bytes in length.

This resulted in the application receiving:

in case (a): A part of the message which was smaller than the
specified BufferLength

in case (b): A zero-byte length message

In both cases, this resulted in the application not being
provided with the full message, as stored on the the queue, and
with the message getting removed from the queue.

Problem conclusion

* The following changes have been made to the client code:

(a) When the specified BufferLength is greater than the
MaxMsgLength on the channel, the V6 WebSphere MQ classes for
Java client has been changed so that the user can now configure
the client classes to provide the application with a
MQCC_FAILED and MQRC_DATA_LENGTH_ERROR error codes, and prevent
the client from receiving the message.

This fix introduces a new system property called:

com.ibm.mq.alertAboutDataLengthError

This property can be set by passing it as a JVM argument, for
example:

java -Dcom.ibm.mq.alertAboutDataLengthError=true MyApplication

The default value of alertAboutDataLengthError is false, which
retains the client behaviour prior to this code change.

When com.ibm.mq.alertAboutDataLengthError=true is defined, the
V6 WebSphere MQ classes for Java informs the application of
the problem using a MQRC_DATA_LENGTH_ERROR code, and does not
allow the application to remove the message from the queue.

When com.ibm.mq.alertAboutDataLengthError=false, the V6
WebSphere MQ classes for Java behaves as before. The client
allows the application to receive the message from the queue.
Although the 2010 error is thrown in the V6 client, it is
consumed internally and a second MQGET is performed with the
BufferLength reduced to a value equal to the channel's
MaxMsgLength. This removes the message from the queue, with
the client application receiving only a portion of the message,
limited by the size of MaxMsgLength.

(b) When the specified BufferLength is greater than the
MaxMsgLength on the channel, the V7.0 WebSphere MQ classes for
Java will hereby inform the application using MQCC_FAILED and
MQRC_DATA_LENGTH_ERROR, and not allow it to receive the message
from the queue. There is no property which can override this
behaviour.

Installing IBM DB2 Performance Expert on Linux/Unix - Middleware News

2011-01-16T01:54:00.000-08:00

Installing IBM DB2 Performance Expert on Linux/Unix - Middleware News

How to install IBM DB2 V9.7 on AIX

Create new database in DB2

MQRC and MQCC Understanding MQ reason codes and completion codes 2110, 2092,2080,2030 - Middleware News

2010-12-29T17:13:00.000-08:00

2110 0x0000083e MQRC_FORMAT_ERROR

Problem(Abstract)

You attempt to get a message from your queue. The getting application fails with a data conversion format error.
Symptom

2110 0x0000083e MQRC_FORMAT_ERROR
Cause

The most common reason for 2110 is an incorrect message format in the message descriptor.
Resolving the problem

Specify the correct MQMD Format for your message. The format 'MQSTR ' is what most applications use to convert string data (non numeric data).

2092 MQRC XMIT Q USAGE ERROR

Problem(Abstract)
You put a message to your queue remote and you expect that it will go to the transmission queue and flow across your sender channel. The putting application fails with the following symptom.

Symptom
2092 0x0000082c MQRC_XMIT_Q_USAGE_ERROR

Cause
2092 is returned because the transmission queue definition did not specify the xmitq parameter.

Resolving the problem
Alter the transmission queue and specify usage(xmitq) parameter.

Example:
alter ql(my_queue) usage(xmitq)

Additional information
USAGE
This parameter is supported only on local and model queues.

NORMAL
The queue is not a transmission queue

XMITQ
The queue is a transmission queue, which is used to hold messages that are destined for a remote queue manager. When an application puts a message to a remote queue, the message is stored on the appropriate transmission queue while awaiting transmission to the remote queue manager.

2080 MQRC TRUNCATED MSG FAILED

Problem(Abstract)
Your first MQGET fails with MQRC_TRUNCATED_MSG_FAILED. This happens because your message buffer is too small. You increased the buffer, and did another MQGET. When you process the message, you find the data is not converted.

Symptom
2080 0x00000820 MQRC_TRUNCATED_MSG_FAILED

Cause
This is working as designed. See the additional information listed below.

Resolving the problem

* Make your message buffer of sufficient size, to handle your largest message.
* Your application must handle MQRC_TRUNCATED_MSG_FAILED. Make sure that your program resets the MQMD FORMAT, ENCODING, and CCSID to the original value, else the message will not be converted by WebSphere MQ.

2030 MQRC MSG TOO BIG FOR Q

Problem(Abstract)
MQPUT fails and you receive the following:

2030 X’07EE’ MQRC_MSG_TOO_BIG_FOR_Q

Cause
The message length exceeds the maxmsgl specified in the WebSphere MQ queue manager, queue and channel definitions.

Resolving the problem
The queue manager, queue and channel must have maxmsgl set to be large enough to hold your messages.

1. Alter the queue manager maxmsgl.
2. Alter the queue maxmsgl.
3. Alter the channel maxmsgl.
4. Restart the queue manager.

Maxmsgl can be changed in runmqsc using the following commands:

C:\>runmqsc FRED
5724-B41 (C) Copyright IBM Corp. 1994, 2002. ALL RIGHTS RESERVED.
Starting MQSC for queue manager FRED.

alter qmgr maxmsgl(10000000)
1 : alter qmgr maxmsgl(10000000)
AMQ8005: WebSphere MQ queue manager changed.

alter ql(client.queue.local) maxmsgl(10000000)
2 : alter ql(client.queue.local) maxmsgl(10000000)
AMQ8008: WebSphere MQ queue changed.

alter chl(client.sdr) maxmsgl(10000000)
3 : alter chl(client.sdr) chltype(sdr) maxmsgl(10000000)
AMQ8016: WebSphere MQ channel changed.

Maxmsgl (Maximum Message Length) can also be changed using the MQSeries Explorer panels:

1. Alteration of the queue manager maxmsgl (Maximum Message Length) property:

2. Alteration of the queue maxmsgl (Maximum message Length) property:

3. Alteration of the channel maxmsgl (Maximum message Length) property:

Channel SSL Error - Middleware News

2010-12-04T23:10:00.001-08:00

Channel SSL Error

Channel SSL Error

WebSphere MQ client connection failures due to resource shortages - Middleware News

2010-11-29T11:47:00.000-08:00

WebSphere MQ client connection failures due to resource shortages
Technote (troubleshooting) - Middleware News

Problem(Abstract)
Your WebSphere MQ client suddenly fails when attempting to connect to your MQ server.

Symptom
You receive many FDCs for the AMQRMPPA and RUNMQLSR processes. The FDCs indicate a shortage of system resources.

xecP_E_NO_RESOURCE
rrcE_CREATE_THREAD_ERROR
xecL_E_TOO_MANY_HANDLES
rc 1450 (NO_SYSTEM_RESOURCES) from WriteFile
rc 12 (ENOMEM = insufficient system resources)

Cause
Recent changes to your Security Exit program caused the resource problem.

Diagnosing the problem
The following errors were reported in FDC files on the server:

Probe Id :- XC035007
Component :- xcsCreateThread
Process Name :- C:\Program Files\IBM\WebSphere MQ\bin\amqzlaa0.exe
Major Errorcode :- xecP_E_NO_RESOURCE
Comment1 :- Not enough space

Probe Id :- ZT049001
Component :- zutPreReadMachineIniFile
Process Name :- C:\Program Files\IBM\WebSphere MQ\bin\amqmsrvn.exe
Major Errorcode :- xecF_E_UNEXPECTED_RC
Minor Errorcode :- xecU_W_KEY_NOT_FOUND

Probe Id :- ZS266000
Component :- lpiObtainQMDetails
Process Name :- C:\Program Files\IBM\WebSphere MQ\bin\amqmsrvn.exe
Major Errorcode :- xecF_E_UNEXPECTED_RC
Minor Errorcode :- MQRC_UNEXPECTED_ERROR

Probe Id :- ZC000040
Component :- zcpCreatePipe
Process Name :- C:\Program Files\IBM\WebSphere MQ\bin\amqzxma0.exe
Major Errorcode :- xecF_E_UNEXPECTED_RC
Minor Errorcode :- xecL_E_TOO_MANY_HANDLES

Probe Id :- ZX005025
Component :- zxcProcessChildren
Process Name :- C:\Program Files\IBM\WebSphere MQ\bin\amqzxma0.exe
Major Errorcode :- zrcX_PROCESS_MISSING

Probe Id :- XY195001
Component :- xstSemaphoreRequest
Process Name :- C:\Program Files\IBM\WebSphere MQ\bin\amqxssvn.exe
Major Errorcode :- xecL_E_TOO_MANY_HANDLES
Comment1 :- Failed to create Event semaphore:Global\mqm.qmgrs.MAIL1!STATION
Comment2 :- Not enough storage is available to process this command.

Probe Id :- XC381009
Component :- xcsDisplayMessageForSubpool
Process Name :- C:\Program Files\IBM\WebSphere MQ\bin\RUNMQLSR.exe
Major Errorcode :- xecF_E_UNEXPECTED_SYSTEM_RC
Comment1 :- WinNT error 1450 from WriteFile.
Comment2 :- Insufficient system resources exist

Refer to the WebSphere MQ Messages manual, chapter 8, for a list of MQ reason codes and their meanings.

Resolving the problem
Make corrections to your security exit so that it does not leak system resources like handles and memory.

AMQ9508 RUNMQSC Command Fails
Technote (troubleshooting)

Problem(Abstract)

You make a user a member of the mqm group. You logon with that uid, test with the RUNMQSC command and fail with the following:

$ RUNMQSC
Starting MQSeries Commands.
AMQ9508: Program cannot connect to the queue manager.
No MQSC commands read.
No commands have a syntax error.
All valid MQSC commands were processed.

Resolving the problem
WebSphere MQ caches group membership for all users at startup. You must restart the queue manager to pick up changes in group membership.

AMQ9524 and AMQ9508 reason code MQRC_SECURITY_ERROR (2063)
Technote (troubleshooting)

Problem(Abstract)

Your queue manager fails to connect to another WebSphere® MQ Solaris queue manager. The connection fails with: AMQ9524 - queue manager not available.

Symptom
Error logs shows:

AMQ9508: Program cannot connect to the queue manager.
EXPLANATION:
The connection attempt to queue manager 'SDQA41' failed with reason code
2063 MQRC_SECURITY_ERROR.

AMQ9509: Program cannot open queue manager object.
EXPLANATION:
The attempt to open either the queue or queue manager object 'ICTXXT01'
queue manager 'SDQA41' failed with reason code 2085.

Cause

The issue is with the userid "mqm" being created LOCALLY. The Solaris box was using NIS+. The security error was due to a conflict between the local userid and NIS+ userid.

Resolving the problem
Delete the local userid "mqm".

Additional information
2063 0x0000080f MQRC_SECURITY_ERROR
2085 0x00000825 MQRC_UNKNOWN_OBJECT_NAME

FDC's report the following:

MQSeries First Failure Symptom Report
| =====================================
| Host Name :- XXXXXXXX (SunOS 5.6)
| PIDS :- 5765B75
| LVLS :- 520
| Product Long Name :- MQSeries for Sun Solaris 2 (Sparc)
| Vendor :- IBM
| Probe Id :- ZF048015
| Application Name :- MQM
| Component :- zfu_as_searchprincipallist
| Build Date :- Nov 7 2000
| CMVC level :- p000-L001106
| Build Type :- IKAP - (Production)
| UserID :- 00011001 (root)
| Program Name :- amqzlaa0_nd
| Process :- 00014376
| Thread :- 00000003
| QueueManager :- SDQA41
| Major Errorcode :- krcE_UNEXPECTED_ERROR
| Minor Errorcode :- OK
| Probe Type :- INCORROUT
| Probe Severity :- 2
| Probe Description :- AMQ6125: An internal MQSeries error has occurred.
|
+--------------------------------------------------------------

MQM Function Stack
zlaMainThread
zlaProcessMessage
zlaProcessMQIRequest
zlaMQCONN
zsqMQCONN
kpiMQCONN
kqiAuthorityChecks
gpiCheckObjectAuthority
zfu_as_checkobjectauthority
zfu_as_calculateauthority
zfu_as_searchprincipallist
xcsFFST

WebSphere MQ File Transfer Edition Two Minute Introduction - Middleware News

2010-11-22T03:02:00.000-08:00

WebSphere MQ File Transfer Edition Two Minute Introduction - Middleware News

ITIL Essentials Study Guide - Middleware News

2010-11-11T01:06:00.000-08:00

ITIL Essentials Study Guide

Introduction

Service Support Functions:

• Service Desk
• Incident Management
• Problem Management
• Change Management
• Configuration Management
• Release Management

Service Delivery Functions:

• Availability Management
• IT Services Continuity Management
• Capacity Management
• Financial Management
• Service Level Management

Configuration Management

Objectives:

• Providing information on the IT infrastructure
o To all other processes
o IT Management
• Enabling control of the infrastructure by monitoring and maintaining information
on:
o All the resources needed to deliver services
o Configuration Item (CI) status and history
o Configuration Item relationships
Tasks:
• Identification and naming
• Management information
• Verification
• Control
• Status Accounting

Asset: Component of a business process like people, accommodation, computer systems,
paper records, fax machines, etc.
Configuration Management Database: A database, which contains all relevant details of
each Configuration Item (CI) and details of the important relationships between CIs.

A Configuration Item (CI):
• Is needed to deliver a service
• Is uniquely identifiable
• Is subject to change
• Can be managed

A Configuration Item (CI) has:
• a Category
• Relationships
• Attributes
• a Status

Variant: A Configuration Item (CI) that has the same basic functionality as another
Configuration Item (CI) but is different in some small way (ex: has more memory)

Baseline: A snapshot of the state of a Configuration Item and any component or related
Configuration Items, frozen in time for a particular purpose (such as the ability to return a
service to a trusted state if a change goes wrong)
Configuration Management supports all other processes!
Scope vs. Detail

Relationships – Common Types:
• Is a component of
• Is a copy of
• Relates to
• Relates with
• Is used by

Service Desk

Objectives:

• To be the primary point of call for all:
o Calls
o Questions
o Requests
o Complaints
o Remarks
• To restore the service as quickly as possible
• To manage the incident life-cycle (coordinating resolution)
• To support business activities
• To generate reports, to communicate and to promote

Different Desks
• Call Center: Handling large call volumes of telephone-based transactions.
• Help Desk: To manage, coordinate, and resolve Incidents as quickly as possible.
• Service Desk: Allowing business processes to be integrated into the Service
Management infrastructure. It not only handles Incidents, Problems and questions,
but also provides an interface for other activities.

Service Desk Essentials:

• Single point of contact / Restore service ASAP
• Tasks: Customer Interface, Business Support, Incident Control & Management
Information
• Concentrates on incident lifecycle management
• Incident: Unexpected disruption to agreed service
• Priority determined by business impact and urgency
• Correct assessment of priorities enables the deployment of manpower and other
resources to be in the best interests of the customer
• Escalation and referral

Incident Management

Objectives:

• To restore normal service as quickly as possible
• Minimize the adverse impact on business operations
• Ensuring that the best possible levels of service quality and availability are
maintained according to SLAs.

Incident: Any event which is not part of the standard operation of a service and which
causes or may cause an interruption to or a reduction in the quality of that service.

Work-Around: Method of avoiding an Incident or Problem.
Service Request: Every Incident not being a failure in the IT Infrastructure.

Problem: The unknown root cause of one or more incidents.

Known Error: A condition that exists after the successful diagnosis of the root cause of a
problem when it is confirmed that a CI (Configuration Item) is at fault.
Impact on the business + Urgency / Effect upon business deadlines = Priority

Category: Classification of a group of Incidents (Application, Hardware, etc.)
Escalation (Vertical Escalation): escalates up the management chain.
Referral (Horizontal Escalation): escalates to a different knowledge group. Routing.

Incident Life-Cycle

• Accept Service Event, Register and Consult the CMDB
• Classification
• Solve
• Closure

Reporting is VERY important.
• Daily reviews of individual Incident and Problem status against service levels
• Weekly management reviews
• Monthly management reviews
• Proactive service reports

Problem Management

Objectives:

• Stabilizing IT services through:
o Minimizing the consequences of incidents
o Removal of the root causes of incidents
o Prevention of incidents and problems
o Prevent recurrence of Incidents related to errors
• Improving productive use of resources

Tasks:

• Problem Control
• Error Control (including raising RfCs – Request for Change)
• Proactive Prevention
• Identifying Trends
• Management Information
• Posit Implementation Review (PIR)
Goal is to get from reactive or proactive. Stop problems from occurring / recurring.
Inputs:
• Incident details
• Configuration details
• Defined work-arounds

Outputs:
• Known Errors
• Requests for Change
• Updated Problem Records including work-arounds and/or solutions
• Response to Incident Management from Matching Management Information

Problem Control
• Identification
• Classification
• Assign Resources
• Investigation and Diagnosis
• Establish Known Error

Error Control
• Error Identification and Recording
• Error Assessment
• Recording Error / Resolution (Send out RfC)
• Error Closure

Known Error: An Incident or Problem for which the root cause is known and for which a
temporary Work-around or a permanent alternative has been identified.
Proactive Problem Management:
• Trend Analysis
• Targeting Support Action
• Providing Information to the Organization
Known Errors resulting from Development should be made known to the Helpdesk.
Reporting is also key for Problem Management.

Change Management

Objective: To implement approved changes efficiently, cost-effectively and with minimal
risk to the existing and to the new IT infrastructure. Only approved changes made, risk
and cost minimized.
Change Management Tasks:
• Filtering Changes
• Managing Change Process
• Managing Changes
• Chairing CAB and CAB/EC
• Review and Closure
• Management Information

Inputs:

• Requests for Change (RfC)
• CMDB
• Forward Schedule of Changes (FSC)

Outputs:

• Forward Schedule of Changes (FSC)
• Requests for Change (RFC)
• CAB minutes and actions
• Change management reports

Impact of change:
• Category 1
o Little impact on current services. The Change Manager is entitled to
authorize this RfC.
• Category 2
o Clear impact on services. The RfC must be discussed in the Change
Advisory Board. The Change Manager requests advice on authorization
and planning.
• Category 3
o Significant impact on the services and the business. Considerable
manpower and/or resources needed. The RfC will have to be submitted to
the board level (CAB/EC – Change Advisory Board / Executive
Committee)

Priority Setting:
• Urgent
o Change necessary now (otherwise severe business impact)
• High
o Change needed as soon as possible (potentially damaging)
• Medium
o Change will solve irritating errors or missing functionality (can be
scheduled)
• Low
o Change leads to minor improvements

A change backout plan must always be possible.
Change management always ends with a review of the change.
Change: The addition, modification, or removal of approved, supported or baselined
hardware, network, software, application, environment, system, desktop build or
associated documentation.

Request for Change: Form or screen, used to record details of a request for a change to
any CI within an infrastructure or to procedures and items associated with the
infrastructure.

Forward Schedule of Changes (FSC): Schedule that contains details of all the Changes
approved for implementation and their proposed implementation dates.
Change Management Process
1. Request for a Change
2. Registration and Classification
3. Monitoring and Planning
4. Approve
5. Build & Test
6. Authorize Implementation
7. Implementation
8. Evaluate

Release Management

Objectives:

• Safeguard all software and related items
• Ensure that only tested / correct version of authorized software are in use
• Ensure that only tested / correct version of authorized hardware are in use
• Right software, right time, right place
• Right hardware, right time, right place

Tasks:

• Define the release policies
• Control of the Definitive Software Library (DSL)
• Control of the Definitive Hardware Storage (DHS)
• Distribute Software and Associated CIs
• Carry out S/W audits (using CMDB)
• Manage the software releases
• Oversee build of the software releases

Releases are done under the control of Change Management.
DSL : Definitive Software Library. Reliable versions of software in a single logical
location. However, software may be physically stored at different locations.

Release Policy:
• Release Unit
• Full / Package / Delta Releases
• Numbering
• Frequency
• Emergency Change

Version Control:
• Development
• Testing
• Live
• Archive

Process:
• Software Control and Distribution (operational)
• Change Management (control)
• Configuration Management (control and administration)
Only process which creates its own policy.

Availability Management

Objectives:

• To predict, plan for and manage the availability of services by ensuring that:
o All services are underpinned by sufficient, reliable and properly
maintained CIs
o Where CIs are not supported internally there are appropriate contractual
agreements with third party suppliers
o Changes are proposed to prevent future loss of service availability
• Only then can IT organizations be certain of delivering the levels of availability
agreed with customers in SLAs.

Aspects of Availability:
• Reliability
• Maintainability: Maintenance you do yourself, as a company
• Resilience: Redundancy
• Serviceability: Maintenance done by someone else
Availability Information is stored in an Availability Database (ADB). This information is
used to create the Availability Plan. SLAs provide an input to this process.
Unavailability Lifecycle
MTTR: Mean Time to Repair (Downtime) – Time period that elapses between the
detection of an Incident and it’s Restoration. Includes: Incident, Detection, Diagnosis,
Repair, Recovery, Restoration.
MTBF: Mean Time Between Failures (Uptime) – Time period that elapses between
Restoration and a new Incident.
MTBSI: Mean Time Between System Incidents – Time period that elapses between two
incidents. MTTR + MTBF.
“An IT service is not available to a customer if the functions that customer requires at
that particular location cannot be used although the agreed conditions under which the IT
service is supplied are being met”
Simplistic Availability Calculation:
Agreed Service Hours – Downtime 100
------------------------------------------ X ----
Agreed Service Hours 1

IT Service Continuity Management

Why plan?
• Increases Business dependency on IT
• Reduced cost and time of recovery
• Cost to customer relationship
• Survival

Many businesses fail within a year of suffering a major IT disaster.
Business Impact Analysis:
Risk Analysis:
• Value of Assets
• Threats
• Vulnerabilities

Risk Management:
• Countermeasures
• Planning for potential disasters
• Managing a disaster

Risk Analysis: Based on the CCTA Computer Risk Analysis and Management
Methodology (CRAMM)

Options:
1. Do nothing
2. Manual workarounds
3. Reciprocal arrangements
4. Gradual Recovery (cold standby)
5. Intermediate Recovery (warm standby)
6. Immediate Recovery (hot standby)
Cold start = accommodation. Environmental controls; power and communications
Hot start = cold start + computing equipment and software
7 Sections of the Plan:
1. Administration
2. The IT Infrastructure
3. IT Infrastructure management & Operating procedures
4. Personnel
5. Security
6. Contingency site
7. Return to normal
Test and Review:
• Initially then every 6 to 12 months and after each disaster
• Test it under realistic circumstances
• Move / protect any live services first
• Review and change the plan
• All changes made via the CAB – Change Advisory Board
Contingency Plan:
• Assists in fast, controlled recovery
• Must be given wide but controlled access
• Contents (incl. Admin, Infrastructure, People, Return to normal)
• Options (incl. Cold & Hot Start)
• Must be tested regularly – without impacting the live service

Capacity Management

Objective:

To determine the right, cost justifiable, capacity of IT resources such that the Service
Levels agreed with the business are achieved at the right time.
Objectives:
• Demand Management
o Business Capacity Management
• Workload Management
o Service Capacity Management
• Resource Management
o Resource Capacity Management
While doing the above, also need to do:
• Performance Management
o Internal and External Financial Data
o Usage Data
o SLM Data / Response Times
CDB – Capacity Data Base – Contains all Metrics, etc. Used to create a Capacity
Management Plan. Performance Management Data populates the CDB.

Essentials:

• From Customer Demands to Resources
• Demand Management
• Workload Management
• Performance Management
• Capacity Planning
• Defining Thresholds and Monitoring
Application Sizing: To estimate the resource requirements to support a proposed
application change to ensure that it meets its required service levels.

Modeling:

• Trend Analysis
• Analytical Modeling
• Simulation Modeling
• Baseline Models
• Used to Answer the “What If… “ questions
• Data for Modeling comes from the CDB

Financial Management

Objectives:

To provide information about and control over the costs of delivering IT services that
support customers business needs.
Costing is a must!
Input cost units recommended by ITIL:
• Equipment Cost Units (ECU)
• Organization Cost Units (OCU)
• Transfer Cost Units (TCU)
• Accommodation Cost Units (ACU)
• Software Cost Units (SCU)
Equipment = hardware
Organization = staff
Transfer = costs which IT incurs acting as an agent for the customer, they do not appear
as a cost against the IT department’s budget
Accommodation = buildings
Software = software

Different Cost Types:

• Fixed - unaffected by the level of usage
• Variable - varying according to the level of usage
• Direct - usage specific to one service
• Indirect or Overhead – usage not specific to one service
• Capital – not diminished by usage
• Revenue or running – diminish with usage

Charging Objectives:
• Recover from customers the full costs of the IT services provided
• Ensure that customers are aware of the costs they impose on IT
• Ensure that providers have an incentive to deliver and agreed quality and quantity
of economic and effective services
Charging and Pricing Options:

Charging:

• No Charging – IT treated as support center
• Notional Charging – IT treated as cost center
• Actual Charging

Pricing:

• Recover of Costs – IT treated as a service center
• Cost Price Plus – IT treated as a profit center
• Market Prices – IT treated as a profit center
Support and Cost centers used “soft charging” in which no money changes hands; service
and profit centers use “hard costing” in which money is transferred between bank
accounts
Profit centers focus on the value of the IT service to the customer
Good Financial Management minimizes the risks in decision making

3 Main Processes:

Budgeting: The process of predicting and controlling the spending of money within the
enterprise and consists of periodic negotiation cycle to set budgets (usually annual) and
the day-to-day monitoring of the current budgets. Key influence on strategic and tactical
plans.

IT Accounting: The set of processes that enable the IT organization to fully account for
the way its money is spent (particularly the ability to identify costs by customer, by
service, by activity).

Charging: The set of processes required to bill a customer for the services applied to
them. To achieve this requires sound IT Accounting, to a level of detail determined by
the requirements of the analysis, billing, and reporting procedures.

Service Level Management

Balance between the Demand for IT services and the Supply of IT services by knowing
the requirements of the business and knowing the capabilities of IT.

Objectives:

• Business-like relationship between customer and supplier
• Improved specification and understanding of service requirements
• Greater flexibility and responsiveness in service provision
• Balance customer demands and cost of services provision
• Measurable service levels
• Quality improvement (continuous review)
• Objective conflict resolution

Tasks:

• Service Catalog
• Service Level Requirements
• Service Level Agreement
• Operational Level Agreements (OLA) and Contracts
• Service Specsheet
• Service Quality Plan
• Monitor, Review and Report
• Service Improvement Programs
• Customer Relationship Management

Minimum Requirements for an Agreement:

• Period
• Service Description
• Throughput
• Availability
• Response Times
• Signature

Other Possible Clauses:

• Contingency arrangements
• Review procedures
• Change procedures
• Support services
• Customer responsibilities
• Housekeeping
• Inputs and Outputs
• Changes
Ideally contracts are based on targets in the SLA
SLAs must be monitored regularly and reviewed regularly
• Monitor to see if service is being delivered to specification
• Review to see if service specification is still appropriate

PCF commands - Middleware News

2010-11-09T12:01:00.000-08:00

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 the ADSI, visit the Microsoft web site at:

www.microsoft.com

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.