WebSphere MQ for OS 2200 Installation, Administration, and ...

WebSphere® MQ Version 6 for ClearPath
OS 2200
Installation, Administration, and Programming
Guide
Level 6R1
October 2010 3843 3744–002
unisys
imagine it. done.

NO WARRANTIES OF ANY NATURE ARE EXTENDED BY THIS DOCUMENT. Any product or related information
described herein is only furnished pursuant and subject to the terms and conditions of a duly executed agreement to
purchase or lease equipment or to license software. The only warranties made by Unisys, if any, with respect to the
products described in this document are set forth in such agreement. Unisys cannot accept any financial or other
responsibility that may be the result of your use of the information in this document or software material, including
direct, special, or consequential damages.
You should be very careful to ensure that the use of this information and/or software material complies with the
laws, rules, and regulations of the jurisdictions with respect to which it is used.
The information contained herein is subject to change without notice. Revisions may be issued to advise of such
changes and/or additions.
Notice to U.S. Government End Users: This is commercial computer software or hardware documentation developed
at private expense. Use, reproduction, or disclosure by the Government is subject to the terms of Unisys standard
commercial license for the products, and where applicable, the restricted/limited rights provisions of the contract
data rights clauses.
Unisys and ClearPath are registered trademarks of Unisys Corporation in the United States and other countries.
IBM and WebSphere are registered trademarks of International Business Machines Corporation in the United States,
or other countries, or both.
All other brands and products referenced in this document are acknowledged to be the trademarks or registered
trademarks of their respective holders.

Contents
Section 1. Introduction
1.1. About This Guide ................................................................................. 1–1
1.2. Concepts and Terminology .............................................................. 1–4
1.2.1. What is Message Queuing? .................................................. 1–4
1.2.2. Messages and Message Queues ........................................ 1–5
1.2.3. WebSphere MQ Objects ........................................................ 1–5
1.2.4. Instrumentation Events .......................................................... 1–9
1.3. WebSphere MQ for ClearPath OS 2200 Components
and Interfaces .............................................................................. 1–13
1.3.1. Message Queuing Interface (MQI) .................................... 1–14
1.3.2. WebSphere MQ Queue Manager (QM) ........................... 1–14
1.3.3. Basic Mode Interface ............................................................ 1–17
1.4. Hardware and Software Requirements ..................................... 1–18
1.5. Security ............................................................................................... 1–19
1.6. The UNX Shell Processor ............................................................... 1–20
1.7. What’s Different? ............................................................................. 1–21
1.7.1. Deployment Differences ...................................................... 1–21
1.7.2. Administrative Differences .................................................. 1–22
1.7.3. Programming Differences .................................................... 1–23
1.7.4. Security ..................................................................................... 1–24
Section 2. Installation and Configuration
2.1. Before You Install WMQ2200 ......................................................... 2–1
2.1.1. Release Media........................................................................... 2–1
2.1.2. Installation and Migration Considerations ......................... 2–2
2.1.3. MQ Performance Considerations ...................................... 2–15
2.2. Installing WebSphere MQ for ClearPath OS 2200 ................... 2–16
2.3. Verifying the Installation and Configuration ............................. 2–20
2.4. Adjusting WMQ2200 Configuration Parameters .....................2–22
2.4.1. Configurable Values Summary........................................... 2–23
2.4.2. Configurable Values Detail .................................................. 2–25
2.5. Setting up Communications ......................................................... 2–33
2.5.1. Overview ................................................................................. 2–33
2.5.2. Setting up Communications between OS 2200
QProcessor and Other Systems .................................. 2–33
2.5.3. Securing Your Channels with SSL ..................................... 2–37
2.6. Advanced Configuration ................................................................ 2–44
2.6.1. Creating and Using Exits ..................................................... 2–44
2.6.2. Configuring WMQ2200 as a Static Resource
Manager under Open Distributed Transaction
Processing .......................................................................... 2–47
3843 3744–002 iii

Contents
2.7. Generating Alternate WMQ2200 Installations Using
COMUS ......................................................................................... 2–49
2.8. Multiple WMQ2200 Installations as Static Resource
Managers under Open DTP ..................................................... 2–56
Section 3. Administration
3.1. Start Up or Shut Down WMQ2200 ................................................ 3–2
3.1.1. Start Up ....................................................................................... 3–2
3.1.2. Shut Down ................................................................................ 3–3
3.2. Startup or Terminate Queue Managers ...................................... 3–3
3.2.1. Starting Queue Managers ..................................................... 3–3
3.2.1.1. WMQ2200 Daemon START Command ................... 3–4
3.2.1.2. strmqm Command ........................................................ 3–4
3.2.2. Terminating Queue Managers ............................................. 3–4
3.3. Configure MQ .ini Files to Customize WMQ2200 and
the Queue Managers ................................................................... 3–7
3.3.1. Using OS 2200 Editors to Modify the .ini Files ................. 3–7
3.3.2. Using OS 2200 QProcessor Administration
Console .................................................................................. 3–7
3.3.3. Using the TED Editor .............................................................. 3–8
3.4. Secure Access to Queues from OS 2200 .................................. 3–8
3.4.1. Security and the UNX Demand Shell .................................. 3–8
3.4.2. The Root User and WebSphere MQ .................................. 3–8
3.4.3. WebSphere MQ Object Authority Manager .................... 3–9
3.4.4. Remote Users and OS 2200 Users ..................................... 3–9
3.4.5. The WebSphere MQ OAM Control Commands ............. 3–10
3.4.6. WebSphere MQ OAM Authentication .............................. 3–11
3.4.7. WebSphere MQ OAM and the mqm Group ................... 3–11
3.4.8. The "Nobody" User and Group ............................................ 3–12
3.4.9. Default Groups on the OS 2200 QProcessor .................. 3–12
3.4.10. Adding a Group on the OS 2200 QProcessor ................. 3–12
3.4.11. The OS 2200 QProcessor User Mappings ....................... 3–13
3.5. Manage Queue Manager Log Files ............................................. 3–16
3.5.1. Overview .................................................................................. 3–17
3.5.2. If You Use the UNX Shell to Administer
WMQ2200 ........................................................................... 3–17
3.5.3. If You Administer WMQ2200 Using OS 2200
QProcessor Administration Console............................ 3–18
3.6. Backup of Queue Manager Data .................................................. 3–18
3.7. WMQ2200 Administrative Tools and Sample
Programs ....................................................................................... 3–19
3.8. Remote Administration Using WebSphere MQ
Explorer ......................................................................................... 3–20
3.8.1. Preparing WMQ2200 for Remote
Administration ................................................................... 3–20
3.8.2. Connecting or Disconnecting to WMQ2200
from the WebSphere MQ Explorer .............................. 3–21
3.8.3. Restrictions .............................................................................. 3–21
iv 3843 3744–002

Section 4. Application Development
Contents
4.1. Exits ....................................................................................................... 4–1
4.1.1. Data Conversion Exits ............................................................. 4–1
4.1.2. Channel Exits ............................................................................ 4–2
4.1.3. Creating and Using Exits ....................................................... 4–3
4.2. Triggers ................................................................................................ 4–4
4.2.1. Configuring a Local Queue for Triggering......................... 4–5
4.2.2. Creating a User-Defined Trigger Monitor ......................... 4–9
4.2.3. Trigger Monitor Processing ................................................. 4–10
4.2.4. Configuration Examples ....................................................... 4–11
4.2.5. Starting the Trigger Monitors ............................................. 4–12
4.2.6. Terminating a Trigger Monitor ............................................ 4–12
4.3. Using Binary Data in the Message Area .................................... 4–13
4.3.1. The OS2200 Architecture ..................................................... 4–13
4.3.2. The OS 2200 QProcessor Architecture ............................ 4–13
4.3.3. Data Transmission and Conversion Challenges ............. 4–13
4.3.4. WebSphere MQ Encodings ................................................ 4–14
4.3.5. Message Formats: Built-In versus User-Defined ......... 4–14
4.3.6. Built-In Message Format Conversion .............................. 4–14
4.3.7. Special MQMDE Considerations ........................................ 4–15
4.3.8. Special MQGMO_CONVERT Considerations .................. 4–16
4.3.9. Chained Message Headers .................................................. 4–16
4.3.10. User-Defined Message Format Conversion ................... 4–17
4.3.11. User Application Development
Recommendations ............................................................ 4–17
4.4. Compiling and Linking WMQ2200 Application
Programs ....................................................................................... 4–17
4.4.1. C Programs ..............................................................................4–18
4.4.2. COBOL Programs .................................................................. 4–20
4.5. Sticking Transactions ..................................................................... 4–20
Section 5. MQI Client Connections
5.1. WebSphere MQ Client Applications ............................................. 5–1
5.2. Preparing WMQ2200 to Accept Client Connections ................ 5–1
5.3. Scaling Considerations ...................................................................... 5–2
5.3.1. MaxActiveChannels Attribute ............................................... 5–2
5.3.2. Listener Backlog Option ......................................................... 5–2
5.4. Restrictions ..........................................................................................5–3
Section 6. High Availability
6.1. Introduction .......................................................................................... 6–1
6.2. WMQ2200 Specific Changes to Support HA .............................. 6–1
6.3. Recommendations ............................................................................. 6–2
3843 3744–002 v

Contents
Section 7. Troubleshooting
7.1. Gather System and Queue Manager Status
Information ...................................................................................... 7–1
7.1.1. Gather System Status ............................................................. 7–2
7.1.2. Gather Queue Manager Status ............................................. 7–3
7.1.3. Gather Queue Manager Configuration
Information ........................................................................... 7–4
7.2. Obtaining Error Information ............................................................ 7–4
7.3. Obtain Queue Manager Traces ...................................................... 7–5
7.3.1. MQS Traces ............................................................................... 7–5
7.3.2. Using OS 2200 QProcessor Administration
Console to Gather Trace Information ............................ 7–6
7.3.3. UNX Shell Traces ...................................................................... 7–6
7.4. Core Dump ........................................................................................... 7–7
7.5. The WMQ2200 Daemon Background Run .................................. 7–7
7.5.1. Starting Daemon Keyin ........................................................... 7–7
7.5.2. Background Process Output File .........................................7–8
7.5.3. Using Daemon Keyin ...............................................................7–8
7.6. Diagnostic Gathering ......................................................................... 7–9
7.6.1. Check UNX Shell Processor Availability ............................. 7–9
7.6.2. Diagnostic Gathering Utility (DIAGN/RUN) ....................... 7–10
7.6.3. Gathering Usysreport Diagnostics .................................... 7–11
7.6.4. List of Files to RSS to Engineering .................................... 7–11
7.6.5. Running the CAT/ERRORS Addstream Manually ........... 7–12
7.7. Real-Time Run Priorities ................................................................. 7–14
7.8. Recover an Unstable WMQ2200 System .................................. 7–15
7.8.1. Deactivating WMQ2200 Subsystems............................... 7–15
7.8.2. Reinitializing the OS 2200 QProcessor System ............. 7–15
Section 8. Message Recovery Procedures
8.1. WebSphere MQ Recovery Capabilities ........................................ 8–1
8.1.1. Differences with MQS2200 ...................................................8–2
8.1.2. Media Recovery ........................................................................8–2
8.1.3. Point-in-time Message Recovery ....................................... 8–4
8.1.4. OS 2200 Database Synchronization .................................... 8–5
8.1.5. Open DTP Subsystem Abort and Deactivation ............... 8–5
8.1.6. OS 2200 Application Group Abort ...................................... 8–5
8.1.7. OS 2200 Daemon Abort ........................................................ 8–5
8.1.8. OS 2200 System Stop ............................................................ 8–5
8.1.9. OS 2200 QProcessor Stop .................................................... 8–6
8.1.10. OS 2200 QProcessor Disk Failure ....................................... 8–6
8.1.11. WMQ2200 Subsystem Abort and Deactivation ...............8–7
8.2. Manually Resolving Incomplete Global Transactions ...............8–7
Appendix A. Data Formatting Between Multiple Platforms
A.1. Library hton/o ..................................................................................... A–1
A.1.1. Host-to-Network Functions .................................................. A–1
A.1.2. Network-to-Host Functions .................................................. A–3
vi 3843 3744–002

Contents
A.2. Library htondb/o ................................................................................ A–5
A.3. Library hton-ucob/o .......................................................................... A–5
A.3.1. Host-to-Network Functions .................................................. A–5
A.3.2. Network-to-Host Functions .................................................. A–7
A.4. Library htondb-ucob/o ...................................................................... A–8
A.5. Library h9ton8/o ................................................................................ A–9
A.5.1. Host-to-Network Function .................................................... A–9
A.5.2. Network-to-Host Function .................................................. A–10
Appendix B. Sample TX/WMQ2200 API Scenarios and
Recommendations
Appendix C. Editing WMQ2200 QProcessor Files
Appendix D. Restrictions and Known Limitations
Appendix E. WMQ2200 Daemon Administrative Utility
Appendix F. UNX Shell
E.1. The Daemon Administrative Utility ................................................ E–1
E.1.1. Starting the Daemon Utility ................................................... E–1
E.1.2. Using the Daemon Keyin ........................................................ E–1
F.1. Using the UNX Shell ........................................................................... F–1
F.2. Using the Asterisk in the UNX Shell .............................................. F–1
F.3. Special Character Handling .............................................................. F–2
F.4. Terminating Input to the runmqdlq Control Command ............ F–2
F.5. Using the Paging Function in the UNX Processor ..................... F–2
F.6. UNX Commands ................................................................................. F–4
F.6.1. Linux Type Shell Commands ................................................. F–4
F.6.2. MQ Series Commands ............................................................ F–7
F.6.3. UNX Utilities ............................................................................... F–9
F.7. UNX Utility Command Reference ................................................ F–10
Appendix G. OS 2200 QProcessor Administrative Console
G.1. About the OS 2200 QProcessor Administration
Console ............................................................................................G–1
G.2. Accessing the Administration Console ....................................... G–2
Index ..................................................................................................... 1
3843 3744–002 vii

Contents
viii 3843 3744–002

Figures
1–1. Components and Interfaces in WMQ2200 .............................................................. 1–13
1–2. Open Distributed Transaction Processing Integration ......................................... 1–16
2–1. Communication Path Between Queue Managers ................................................ 2–34
3843 3744–002 ix

Figures
x 3843 3744–002

Tables
C–1. TED Commands ............................................................................................................... C–3
F–1. Common Pager Commands .......................................................................................... F–3
F–2. Linux Type Shell Commands ......................................................................................... F–4
F–3. MQ Series Commands .................................................................................................... F–7
F–4. UNX Utilities ....................................................................................................................... F–9
F–5. Shared Memory Segments......................................................................................... F–29
F–6. IPC Message Queues ................................................................................................... F–30
F–7. Semaphore Arrays ......................................................................................................... F–31
3843 3744–002 xi

Tables
xii 3843 3744–002

Section 1
Introduction
WebSphere® MQ for ClearPath OS 2200 product (hereafter referred to as WMQ2200)
allows TIP/HVTIP or batch programs on ClearPath OS 2200 servers to participate in
message-oriented processing applications. WMQ2200 is based on IBM®WebSphere®
MQ Version 6.0 and can communicate with any platform on which a compatible
version of WebSphere MQ is available.
1.1. About This Guide
Purpose
Audience
Prerequisites
This guide describes the WebSphere MQ for ClearPath OS 2200 product, which allows
TIP/HVTIP or batch programs on ClearPath Dorado 300, 700, and 4000 Series servers to
participate in message oriented processing applications. It explains how to install,
configure, and administer WMQ2200, and how to create applications that make use of
the Message Queuing Interface (MQI).
This guide is for site administrators and application programmers who intend to
• Install and configure WMQ2200.
• Perform administrative tasks for WMQ2200.
• Design and write message oriented processing applications.
This guide assumes the reader is familiar with general OS 2200 concepts such as
subsystems, and application development concepts such as C, COBOL, and LINK.
Readers must also be familiar with communications software such as
Communications Application Program Interface (previously known as COMAPI) and the
concept of message queuing.
For systems where WMQ2200 is used as a resource manager, knowledge of Open
Distributed Transaction Processing software (previously called Open/OLTP Transaction
Manager or OLTP-TM2200) is useful.
3843 3744–002 1–1

About This Guide
The following IBM documents are highly recommended as preliminary reading:
• MQ Series: An Introduction to Messaging and Queuing
• WebSphere MQ for Linux Version 6.0 Quick Beginnings
• WebSphere MQ System Administration Guide Version 6.0
This document describes many WebSphere MQ administration concepts that this
guide explains for the OS 2200 environment.
You can download WebSphere MQ documentation from the following location:
http://www-01.ibm.com/software/integration/wmq/library/library60.html
Note: WMQ2200 is based on version 6.0 of WebSphere MQ for Linux. Ensure that
you download versions that are applicable to that level.
You can also refer to the following documents which provide information that is
related to the subject of this guide.
• ClearPath Specialty Engine for OS 2200 Installation and Servicing Guide
• ClearPath Specialty Engine for OS 2200 Configuration Guide
• ClearPath OS 2200 QProcessor Administration Console Help
How to Use This Guide
Use the following table as a key to navigating this guide.
For this information … Go to …
An overview of message queuing concepts 1.2
WMQ2200 capabilities overview 1.3
Hardware and software requirements 1.4
Security 1.5
UNX shell processor 1.6
What's Different? 1.7
Installation and configuration, including migration
considerations and performance tuning
Section 2
Administrative tasks Section 3
Creating applications Section 4
MQI client connections Section 5
High Availability Section 6
Troubleshooting Section 7
Message Recovery procedures Section 8
1–2 3843 3744–002

For this information … Go to …
About This Guide
Data formatting between multiple platforms Appendix A
TX/WMQ2200 API scenario recommendations Appendix B
Editing WMQ2200 QProcessor Files Appendix C
Restrictions and known limitations Appendix D
WMQ2200 Daemon Administrative utility Appendix E
UNX Shell Appendix F
OS 2200 QProcessor Administration Console Appendix G
Notation Conventions
This guide uses the following notation conventions:
bold
italic
User input appears in bold.
Names of variables to which values must be assigned (such as password) appear
in italics.
constant width
[ ]
>
< >
Examples and system output, such as prompt signs and responses to commands,
appear in constant width.
Brackets enclose optional fields or subfields.
Screen examples often use one greater than (>) symbol to generically represent
any kind of command line prompt.
A value shown between the less than () symbols in screen
examples indicates the default value.
3843 3744–002 1–3

Concepts and Terminology
Documentation Updates
This document contains all the information that was available at the time of
publication. Changes identified after release of this document are included in problem
list entry (PLE) 18759136. To obtain a copy of the PLE, contact your Unisys
representative or access the current PLE from the Unisys Product Support Web site:
http://www.support.unisys.com/all/ple/18759136
Note: If you are not logged into the Product Support site, you will be asked to do
so.
1.2. Concepts and Terminology
This subsection is extracted from the IBM WebSphere MQ Application Programming
Guide Version 6.0 and the IBM document titled Monitoring WebSphere MQ. It
introduces WebSphere MQ and contains explanations of the following topics:
• Message Queuing
• Messages and Message queues
• WebSphere MQ objects
• Instrumentation events
1.2.1. What is Message Queuing?
Message queuing has been used in data processing for many years and is most
commonly used today in electronic mail. Without queuing, sending an electronic
message over long distance requires every node on the route to be available for
forwarding messages. The addressees need to be logged and you need to be
conscious of the fact that you are trying to send a message to the selected address. In
a queuing system, messages are stored at intermediate nodes until the system is
ready to forward them. At the final destination messages are stored in an electronic
mailbox until the addressee is ready to read them.
Even so, many complex business transactions are processed today without queuing.
In a large network, the system might maintain many thousands of connections in a
ready-to-use state. If one part of the system suffers a problem, many parts of the
system become unusable.
You can think of message queuing as being electronic mail for programs. In a message
queuing environment, each program from the set that makes up an application suite is
designed to perform a well-defined, self-contained function in response to a specific
request. To communicate with another program, a program must put a message on a
predefined queue. The other program retrieves the message from the queue, and
processes the requests and information contained in the message. Message queuing
is a style of program-to-program communication.
1–4 3843 3744–002

Concepts and Terminology
Queuing is the mechanism by which messages are held until an application is ready to
process them. Queuing allows you to
• Communicate between programs (that might each be running in different
environments) without having to write the communication code.
• Select the order in which a program processes messages.
• Balance loads on a system by arranging for more than one program to service a
queue when the number of messages exceeds a threshold.
• Increase the availability of your applications by arranging for an alternative system
to service the queues if your primary system is unavailable.
1.2.2. Messages and Message Queues
What Is a Message?
In message queuing, a message is a collection of data sent by one program and
intended for another program. WebSphere MQ defines four types of messages:
• Datagram: A simple message for which no reply is expected
• Request: A message for which a reply is expected
• Reply: A reply to a request message
• Report: A message about another message
What Is a Message Queue?
A message queue, known simply as a queue, is a named destination to which
messages can be sent. Messages accumulate on queues until they are retrieved by
programs that service those queues.
Queues reside in, and are managed by, a queue manager. A queue can either be a
volatile buffer area in the memory of a computer, or a data set on a permanent
storage device (such as a disk). The physical management of queues is the
responsibility of the queue manager and is not made apparent to the participating
application programs.
Programs access queues only through the external services of the queue manager.
Programs can open a queue, put messages on it, get messages from it, and close the
queue. In addition, programs can also set, and inquire about, the attributes of queues.
1.2.3. WebSphere MQ Objects
The WebSphere MQ objects are
• Queue managers
• Queues
• Namelists
• Process definitions
3843 3744–002 1–5

Concepts and Terminology
• Authentication information objects
• Channels
• Listeners
• Services
Queue Managers
Queues
A queue manager is a system program that provides queuing services to applications.
It provides an application programming interface so that programs can put messages
on, and get messages from, queues. A queue manager provides additional functions
so that administrators can create new queues, alter the properties of existing queues,
and control the operation of the queue manager.
For WebSphere MQ message queuing services to be available on a system, a queue
manager must be a running. You can have multiple queue managers running on a
single system (for example, to separate a test system from a live system). To an
application, each queue manager is identified by a connection handle (Hconn).
Many different applications that are completely unrelated can use the services of a
queue manager simultaneously. For a program to use the services of a queue
manager, it must establish a connection to that queue manager.
For applications to send messages to applications that are connected to other queue
managers, the queue managers must be able to communicate among themselves.
WebSphere MQ implements a store-and-forward protocol to ensure the safe delivery
of messages between such applications.
A WebSphere MQ queue is a named object on which applications can put messages,
and from which applications can get messages. Messages are stored on a queue, so
that if the putting application is expecting a reply to its message, it is free to do other
work while waiting for that reply. Applications use the Message Queue Interface
(MQI) to access a queue.
Before a message can be put on a queue, you need to ensure that the queue is
created. A queue is owned by a queue manager, and that queue manager can own
many queues. However, each queue must have a name that is unique within that
queue manager. A queue is maintained through a queue manager. In most cases, each
queue is physically managed by its queue manager but this is transparent to an
application program.
To create a queue use the WebSphere MQ commands (MQSC) or Programmable
command format (PCF) commands. You can create local queues for temporary jobs
dynamically from your application. For example, you can create reply-to queues (that
are not needed after an application ends).
1–6 3843 3744–002

Namelists
Concepts and Terminology
Before using a queue, you must open the queue, specifying what you want to do with
it. For example, you can open a queue for:
• Browsing messages only (not retrieving them)
• Retrieving messages (and either sharing the access with other programs, or with
exclusive access)
• Putting messages on the queue
• Inquiring about the attributes of the queue
• Setting the attributes of the queue
A namelist is a WebSphere MQ object that contains a list of cluster names, queue
names or authentication information object names. In a cluster, namelists can be used
to identify a list of clusters for which the queue manager holds the repositories.
You can define and modify namelists only using MQSC commands.
Programs can use the MQI to find out which queues are included in these namelists.
The organization of the namelists is the responsibility of the application designer and
system administrator.
Process Definitions
To allow an application to start without the need for operator intervention, the queue
manager must know the attributes of the application. These attributes are defined in a
process definition object.
The ProcessName attribute is fixed when the object is created; you can change the
other attributes using the WebSphere MQ commands.
Authentication information objects
Channels
An authentication information object contains authentication information used in
Secure Sockets Layer (SSL) encrypted transport of information. An authentication
information object of AUTHTYPE CRLLDAP provides the definitions required to
perform Certificate Revocation List (CRL) checking using LDAP servers. CRLs allow
Certification Authorities to revoke certificates that can no longer be trusted.
A channel is a communication link used by distributed queue managers. There are two
categories of channels in WebSphere MQ:
• Message channels, which are unidirectional, transfer messages from one queue
manager to another.
• MQI channels, which are bidirectional, transfer MQI calls from a WebSphere MQ
client to a queue manager, and responses from a queue manager to a WebSphere
MQ client.
3843 3744–002 1–7

Concepts and Terminology
Listeners
Services
You need to consider these categories when designing your application, but programs
are unaware of WebSphere MQ channel objects.
Listeners are processes that accept network requests from other queue managers, or
client applications, and start associated channels. The runmqlsr control command
starts the Listener process.
Listener objects are WebSphere MQ objects that allow you to manage the starting
and stopping of listener processes from within the scope of a queue manager. By
defining attributes of a listener object you do the following:
• Configure the listener process.
• Specify whether the listener process automatically starts and stops when the
queue manager starts and stops.
Service objects are a way of defining programs to be executed when a queue
manager starts or stops. The programs can be split into the following types:
Servers
A server is a service object that has the parameter SERVTYPE specified as SERVER. A
server service object is the definition of a program that is executed when a specified
queue manager is started. Only one instance of a server process can be executed
concurrently. While running, the status of a server process can be monitored using the
MQSC command, DISPLAY SVSTATUS. Typically, the server service objects are
definitions of programs such as dead letter handlers or trigger monitors; however the
programs that can run are not limited to those supplied with WebSphere MQ.
Additionally, a server service object can be defined to include a command that runs
when the specified queue manager is shutdown to end the program.
Commands
A command is a service object that has the parameter SERVTYPE specified as
COMMAND. A command service object is the definition of a program that is executed
when a specified queue manager is started or stopped. Multiple instances of a
command process can be executed concurrently. Command service objects differ
from server service objects in that once the program is executed the queue manager
will not monitor the program. Typically, the command service objects are definitions of
programs that are short lived and perform a specific task such as starting one, or
more, other tasks.
1–8 3843 3744–002

1.2.4. Instrumentation Events
Concepts and Terminology
In WebSphere MQ, an instrumentation event is a logical combination of conditions that
is detected by a queue manager or channel instance. Such an event causes the queue
manager or channel instance to put a special message, call an event message, on an
event queue.
WebSphere MQ instrumentation events provide information about errors, warnings,
and other significant occurrences in a queue manager. You can use these events to
monitor the operation of queue managers.
Queue Manager Events
Queue manager events are related to the use of resources within queue managers,
such as an application trying to put a message on a queue that does not exist. The
event messages for queue manager events are put on the
SYSTEM.ADMIN.QMGR.EVENT queue. The following queue manager event types are
supported:
• Authority
• Inhibit
• Local
• Remote
• Start and stop
For each event type in this list, there is a queue manager attribute that enables or
disables the event type.
Authority events
Authority events report an authorization, such as an application trying to open a queue
for which it does not have the required authority, or a command.
Inhibit events
Inhibit events indicate that an MQPUT or MQGET operation has been attempted
against a queue, where the queue is inhibited for puts or gets.
Local events
Local events indicate that an application (or the queue manager) has not been able to
access a local queue or other local object. For example, an application might try to
access an object that has not been defined.
Remote events
Remote events indicate that an application (or the queue manager) cannot access a
(remote) queue on another queue manager. For example, the transmission queue to
be used might not be correctly defined.
3843 3744–002 1–9

Concepts and Terminology
Performance Events
These events are notifications that a threshold condition has been reached by a
resource. For example, a queue depth limit has been reached or, following an MQGET
request, a queue has not been serviced within a predefined time.
For each event type in this list, there is a queue manager attribute that enables or
disables the event type.
Channel Events
Channels report events because of conditions detected during their operation. For
example, a channel event is generated when a channel instance is stopped.
Start and stop events
Start and stop events indicate that a queue manager has been started or has been
requested to stop or quiescent. Stop events are not recorded unless the default
message-persistence of the SYSTEM.ADMIN.QMGR.EVENT queue is defined as
persistent.
Channel and Bridge Events
Channel events are reported by channels as a result of conditions detected during
their operation, such as when a channel instance is stopped. The event messages for
channel and bridge events are put on the SYSTEM.ADMIN.CHANNEL.EVENT queue.
Channel events are generated
• By a command to start or stop a channel.
• When a channel instance starts or stops.
• When a channel receives a conversion error warning when getting a message.
• When an attempt is made to create a channel automatically; the event is
generated whether the attempt succeeds or fails.
Note: Client connections do not cause Channel Started or Channel Stopped events.
When a command is used to start a channel, an event is generated. Another event is
generated when the channel instance starts. However, starting a channel by a listener,
runmqchl, or a queue manager trigger message does not generate an event; in this
case the only event generated is when the channel instance starts.
A successful start or stop channel command generates at least two events. These
events are generated for both queue managers connected by the channel (provided
that the channel support events).
If a channel event is put on to an event queue, an error condition causes the queue
manager to create an event as usual.
1–10 3843 3744–002

Performance Events
Concepts and Terminology
Performance events report that a resource has reached a threshold condition. For
example, a queue depth limit might have been reached. The event messages for
performance events are put on the SYSTEM.ADMIN.PERFM.EVENT queue.
Performance events relate to conditions that can affect the performance of
applications that use a specified queue; they are not generated for the event queues
themselves.
The event type is returned in the command identifier field in the message data.
If a queue manager tries to put a queue manager event or performance event
message on an event queue and an error that would normally create an event is
detected, another event is not created and no action is taken.
MQGET and MQPUT calls within a unit of work can generate performance events
regardless of whether the unit of work is committed or backed out.
There are two types of performance events:
Queue depth events
Queue depth events relate to the number of messages on a queue; that is how full, or
empty the queue is. These events are supported for shared queues.
Queue service interval events
Queue service interval events relate to whether messages are processed within a
user-specified time interval. These events are not supported for shared queues.
Configuration Events
Configuration events are reported when objects are created or modified. A
configuration event message contains information about the attributes of an object.
For example, a configuration event message is generated if a namelist object is
created, and contains information about the attributes of the namelist object. The
event messages for configuration events are put on the
SYSTEM.ADMIN.CONFIG.EVENT queue.
There are four types of configuration events:
Create object events
Create object events are generated when an object is created.
Change object events
Change object events are generated when an object is changed.
Delete object events
Delete object events are generated when an object is deleted.
3843 3744–002 1–11

Concepts and Terminology
Refresh object events
Refresh object events are generated by an explicit request to refresh.
Command events
Logger events
A command event is reported when an MQSC or PCF command is executed
successfully. For example, a command event message is generated if the MQSC
command, ALTER QLOCAL, is executed successfully. A command event message
contains information about the origin, context, and content of a command. The event
messages for command events are put on the SYSTEM.ADMIN.COMMAND.EVENT
queue.
A logger event is reported when a queue manager that employs linear logging starts
writing log records to a new log extent. A logger event message contains information
specifying the log extents required by the queue manager for queue manager restart
or media recovery. The event messages for logger events are put on the
SYSTEM.ADMIN.LOGGER.EVENT queue.
1–12 3843 3744–002

WebSphere MQ for ClearPath OS 2200 Components and Interfaces
1.3. WebSphere MQ for ClearPath OS 2200
Components and Interfaces
Figure 1-1 illustrates the components and interfaces in WMQ2200.
Figure 1–1. Components and Interfaces in WMQ2200
3843 3744–002 1–13

WebSphere MQ for ClearPath OS 2200 Components and Interfaces
1.3.1. Message Queuing Interface (MQI)
The application program interface to WMQ2200 is called the Message Queuing
Interface (MQI). The MQI is a set of function names that are entry points into the
WMQ2200 subsystem. These functions are supported in the following languages:
• C (sometimes referred to as C Compiler, and previously called Universal Compiling
System [UCS C])
• COBOL (sometimes referred to as COBOL Compiler, and previously called
Universal Compiling System [UCS COBOL])
The MQI functions MQCONN, MQCONNX, MQOPEN, MQGET, MQPUT, MQPUT1,
MQCMIT, MQBACK, MQCLOSE, and MQDISC are supported by WMQ2200.
The MQI is described in detail in the IBM WebSphere MQ Application Programming
Reference manual.
WMQ2200 provides access to the MQI for new applications as well as the existing
MQSeries for ClearPath OS 2200 (hereafter referred to as MQS2200) applications.
Existing MQS2200 applications can use WMQ2200 without relinking provided you are
using the same MQS subsystem gate bank BDI (Bank Descriptor Index). The default
MQS subsystem BDI for WMQ2200 is the same as the one used for MQS2200. There
are some exceptions to this general relinking rule. Refer to Section 4, "Application
Development," for more information on multibyte data.
1.3.2. WebSphere MQ Queue Manager (QM)
The WebSphere MQ Queue Manager (QM) provides queuing services to applications
and manages the execution environment of the MQI. The WMQ2200 Queue Manager
includes the following standard or equivalent features:
• Syncpoint (data assurance)
WebSphere MQ Syncpoint coordination is the process by which units of work are
either committed or backed out with data integrity.
WMQ2200 supports, as a single unit of work, coordination of actions resulting
from multiple MQI calls made under Syncpoint within an application using the
MQCMIT and MQBACK MQI calls.
Where the actions of more than one resource manager need to be synchronized,
WMQ2200 requires the services of an external transaction manager. In this case,
WMQ2200 acts as a resource manager and Open Distributed Transaction
Processing software provides the transactional coordination.
This provides XA-compliant transactional coordination.
• Logging
The WebSphere MQ Log Manager maintains a sequential record of all persistent
changes made to the Queue Manager for purposes of recovery. By default, log
files are placed on a set of mirrored disks on the OS 2200 QProcessor system for
greater reliability. WebSphere MQ logs can be archived using a variety of tools.
1–14 3843 3744–002

• Triggers
WebSphere MQ for ClearPath OS 2200 Components and Interfaces
A trigger event is an event that causes a trigger message to be generated by the
queue manager and sent to an initiation queue. A trigger monitor application
processes the initiation queue. WMQ2200 provides a default, system-supplied
trigger monitor and allows a user-developed application as a trigger monitor.
Additionally, WMQ2200 provides trigger functions to perform an Open Distributed
Transaction Processing service, execute an OS 2200 batch runstream, or schedule
a TIP transaction.
• Exits
Applications can specify exit points during channel processing that allow
customized requirements to be included. WMQ2200 supports the standard exit
points for Message Retry, Message Channel, Data Conversion, and Transmission
Program.
• Security
WMQ2200 provides support for user-provided node authentication through
transmission program exits.
You can use the IBM WebSphere MQ Object Authority Manager (OAM) for user
authentication to access the queue manager based on user-defined group
permissions for operations and access to resources. Refer to the IBM WebSphere
MQ System Administration Guide for details on how user and groups are used by
OAM. Refer to Section 3, "Administration," for specific information on how users
and groups work in the ClearPath OS 2200 QProcessor environment.
• Distribution lists
The Queue Manager allows you to put multiple messages on the same queue
through the sequence of MQOPEN … MQPUT … MQPUT … MQCLOSE.
Distribution lists allow you to send a message to multiple destinations. MQOPEN
opens a distribution list and a single MQPUT sends the message.
• Backup and restore
The mqsave and mqload UNX shell commands, developed by Unisys, are provided
for backup and restore of Queue Manager files and data to the OS 2200. Backup
and restore of the OS 2200 QProcessor configuration and data can be also
accomplished using the OS 2200 QProcessor Administration Console.
• Instrumentation
WMQ2200 supports WebSphere MQ instrumentation events necessary to
monitor the operation of the queue manager.
• Diagnostics
WMQ2200 supports WebSphere MQ diagnostics, such as tracing, as described in
the IBM WebSphere MQ System Administration Guide. Refer to Section 7,
"Troubleshooting," of this document for more information. Several diagnostic
utilities are provided with the OS 2200 QProcessor Administration Console that
enables you to monitor disks (System Health), collect WMQ2200 traces and
dumps, and view system and message queue error logs. All WMQ2200 errors are
optionally written to the Server Sentinel console if configured on the OS 2200
QProcessor.
3843 3744–002 1–15

WebSphere MQ for ClearPath OS 2200 Components and Interfaces
In addition, ICLogLevel and MQLogLevel are provided for OS 2200 and OS 2200
QProcessor tracing. Refer to Section 2, "Installation and Configuration", for more
information.
Open Distributed Transaction Processing Integration
Transactional support is provided with WMQ2200 acting as a XA-compliant resource
manager (RM) under Open Distributed Transaction Processing.
Open Distributed Transaction Processing global units of work allow access to
WMQ2200 as a static resource manager in conjunction with the following resource
managers:
• File control superstructure (FCSS)
• Universal Database Control (previously called Universal Data System [UDS]
Control)
• Message Control Bank (MCB)
Figure 1-2 illustrates Open Distributed Transaction Processing integration.
Figure 1–2. Open Distributed Transaction Processing Integration
1–16 3843 3744–002

WebSphere MQ for ClearPath OS 2200 Components and Interfaces
WMQ2200 as a Resource Manager
To coordinate either persistent or nonpersistent message type updates within a global
transaction, you must use the WebSphere MQ Syncpoint option on the message put
or get when Open Distributed Transaction Processing is acting as the transaction
manager. This global transaction might not involve other resource managers.
This coordination is achieved by an Open Distributed Transaction Processing client or
server that
• Has its ap$name configured with the WebSphere MQ resource manager GROUP
name in tmsconfig.
• Uses the tx_* application interface verbs.
• Uses the WebSphere MQ Syncpoint option on put and get commands.
• Can invoke servers configured to do work in other resource managers.
• If using a nondefault queue manager, has the queue manager name in the
OPENINFO statement of a WebSphere MQ resource manager GROUP entry in
tmsconfig.
WebSphere MQ message integrity is assured when a message is persistent.
Persistence is determined by the DefPersistence attribute of the queue specified in
the MQOPEN command, or by the Persistence field of the MQMD structure for the
message.
The WebSphere MQ Syncpoint capability is not bound with OS 2200 integrated
recovery and WebSphere MQ message queues are not tied to an application group.
However, messages on the WebSphere MQ queues are assured recoverable across
system and subsystem crashes by the internal WebSphere MQ recovery mechanism
when persistent messages or persistent Syncpoint is used.
1.3.3. Basic Mode Interface
The purpose of the basic mode interface (BMI) is to allow the Business Information
Server for ClearPath OS 2200 product access to the WebSphere MQ MQI. The BMI is
a subsystem that consists of two installed files, wmq$*mqs$bmcommon and
wmq$*mqs$bmlib. The Business Information Server product provides its users the
capability to
• Connect to any number of queue managers
• Open a queue
• Put a message on a queue
• Get a message from a queue
• Inquire about the properties of a queue
• Close a queue
• Disconnect from a queue manager
The Basic Mode Interface is optional and is not part of a default installation.
3843 3744–002 1–17

Hardware and Software Requirements
Refer to the Business Information Server for ClearPath OS 2200 Installation and
Systems Analysis Guide for more information.
1.4. Hardware and Software Requirements
Hardware Requirements
You can run WMQ2200 on a ClearPath Dorado 300, 700, or 4000 Series server paired
with the ClearPath OS 2200 QProcessor (hereafter referred to as OS 2200
QProcessor). A separate OS 2200 QProcessor is required for each installation of
WMQ2200.
Software Requirements
For the OS 2200 operating environment and for most software products, WMQ2200
level 6R1 requires ClearPath OS 2200 release 11.3, ClearPath OS 2200 release 12.0 or
later. The following is also required:
• IC2200
The Interconnect (referred to as IC2200 in this document) allows WMQ2200
applications (including existing MQS2200 applications) to execute requests on the
OS 2200 QProcessor.
In addition, the following may be required:
• To have WMQ2200 function as a resource manager under Open Distributed
Transaction Processing, you must have Open Distributed Transaction Processing
(OLTP-TM2200) release 8R1 or later. You must also apply resolutions provided for
your Open Distributed Transaction Processing release in OLTP-TM2200 PLEs that
have a keyword of MQS2200.
Install Open Distributed Transaction Processing following the standard installation
procedures in the Open Distributed Transaction Processing Administration Guide
volume 1.
• The Business Information Server for the ClearPath OS 2200 product has
introduced a basic mode interface to WMQ2200. This optional interface is
packaged on the WMQ2200 release tape. It permits the Business Information
Server product to utilize the WMQ2200 MQI. To install the basic mode interface,
you must install mode WMQ$B of the WMQ2200 product. In addition to the
standard set of files installed with default mode WMQ$A, two other files,
WMQ$*MQS$BMCOMMON and WMQ$*MQS$BMLIB, are also installed.
1–18 3843 3744–002

1.5. Security
Security
WMQ2200 is supported in a Fundamental Security, Security Option 1, Security Option
2, or Security Option 3 environment. Depending on the environment, specific
requirements must be met for the WMQ2200 API daemon to start properly.
In a SecOpt Security environment, the owner of the WMQ2200 subsystem (the owner
of the MQS$COMMON file which is usually –MQS–) must meet the following criteria:
• Have BATCH privilege
• Have access to the account number of the user who runs the MQS$EXE.STARTUP
program to invoke the daemon if the QUOTA_ENFORCEMENT_BY_USERID is
TRUE.
• Be mapped as the root user and group on the OS 2200 QProcessor.
• Have ER KEYIN$ privilege
In a Fundamental Security environment, the OS 2200 user ID that starts the WMQ2200
daemon through the MQS$EXE.STARTUP command must:
• Have BATCH privilege
• Have ER KEYIN$ privilege
• Be mapped as the root user and group on the OS 2200 QProcessor.
User ID Requirements for the Owner of the WMQ$*MQS$COMMON
Subsystem and the WMQ$*MQS$BMCOMMON Subsystem Files
Access to a subsystem is granted by a combination of two conditions:
• Execute access to the subsystem file
• Execute access to the user ID record that owns the subsystem file.
The first condition is met because the two subsystem files are installed as public files.
The second condition requires the creation of a user ID that owns the subsystem files
and has the following attributes, depending on your security requirements. If you use
access control records (ACRs), this user ID must allow public execute access through
an ACR attached to the subsystem files. You must also set up a list of users who can
deactivate the subsystem (DELETE argument).
Set this parameter … To...
Processor Privilege Can Only Read Executive GRS
Access Privilege Trusted
Subsystem Sharing Level Application
General Access Permission Privilege True (set)
Refer to the Software Products Installation Guide for more information regarding
user ID requirements.
3843 3744–002 1–19

The UNX Shell Processor
Unisys recommends that you verify that the user ID of the owner of the WMQ2200
subsystem has the ER CALLs privilege, DUMP$SUBSYS. This ensures that WMQ2200
banks are included in Exec dumps.
User ID –MQS- should be set up and provided by the OS 2200 operating system, and
this user ID must then be owner of both the MQS$COMMON and the
MQS$BMCOMMON subsystem files.
init User ID Requirements
The user ID that starts the init or init-migrate script in the WMQ2200 Demand Shell
must have root authority on the OS 2200 QProcessor. This means the OS 2200 user
running the init script must be mapped as root on the OS 2200 QProcessor. OS 2200
users can be added to the OS 2200 QProcessor mappings as root through the OS 2200
QProcessor Administration Console. Refer to Section 3, "Administration," for more
information.
WMQ2200 Administrative Commands User ID Requirements
After you have installed the product and prepared the WMQ2200 system, you must
add users who are to run the WMQ2200 commands, for example crtmqm or strmqm,
to the Interconnect User Map file. This user map file determines the authority an
OS 2200 user ID has on the OS 2200 QProcessor. To execute WebSphere MQ
administrative commands, a user must be a member of the ‘mqm’ group on the
QProcessor. Refer to Section 3, "Administration," for more information on mapping
users.
1.6. The UNX Shell Processor
Throughout this guide, you will notice references to the UNX shell processor or UNX
shell. This processor is a shell interface for executing various WebSphere MQ
commands such as crtmqm, dspmqlog, and so on. The UNX shell processor also
provides
• A set of UNIX-like commands for accessing the file system and processes
• A set of utility commands
Format
>@wmq$*mqs$exe.unx
The UNX shell processor responds with output similar to the following:
>@wmq$*mqs$exe.unx
>Unx - 6R1 - 2010 Jun 29 Mon 08:14:30
>28140>
The number within the prompt is the process-id, or pid, of the UNX shell session
within your WMQ2200 system. Type a single question mark to display a list of
available WebSphere MQ and utility commands. To get help on a specific UNIX-like or
utility command, type a question mark followed by the command name.
1–20 3843 3744–002

What’s Different?
Use the backslash character ( \ ) to continue a UNX command input line to the next
line. Each entered input can be a maximum of 80 characters in length. You do not need
to place any spaces between the end of a line and the continuation character; all
characters prior to the continuation character are considered significant.
If you need to enter the "*" character in an UNX shell session, it must be preceded with
the “\” (escape) character as follows:
>dspmqfls –t \*
To exit the UNX shell processor, use the exit command.
Commands that output multiple screens require the user to enter ‘q’ to quit the
command session. After displaying the last screen, the user is presented the following
prompt:
>(END)>
To exit the command session, enter command ‘q’ in response to the END prompt.
Note: The API daemon background run does not need to be active to use the UNX
demand shell. Only the IC launcher daemon on the OS 2200 QProcessor needs to be
running to use the UNX demand shell.
1.7. What’s Different?
This list describes the programming and operational differences between MQS2200
and WMQ2200. If you were an MQS2200 user, read through this section to make sure
you are aware of changes that affect your deployment and administration of the new
product.
1.7.1. Deployment Differences
• The installation process has changed. The Solar install for WMQ2200 must install
additional software on the OS 2200 QProcessor. Refer to Section 2, "Installation
and Configuration," to become familiar with the WMQ2200 installation process.
• The Solar product installation installs files on both the OS 2200 and the OS 2200
QProcessor. This requires that an OS 2200 user be mapped to root to allow the
installation on the OS 2200 QProcessor to succeed. Use the OS 2200 QProcessor
Administration Console to manage user mappings.
• The installation process now uses different SOLAR installation modes to install
either to the OS 2200 or a OS 2200 QProcessor. The default mode, WMQ$A is
used to install to the OS 2200 only. Modes Q$1 through Q$8 are used to install to
the eight possible OS 2200 QProcessors. Multiple modes can be selected to install
the software on both the OS 2200 and the OS 2200 QProcessors.
3843 3744–002 1–21

What’s Different?
• Migration is no longer done with the *mqs$run.init/run addstream. Several
migration scenarios are documented in section 2.
• Although you can still generate alternate installations using COMUS, some of the
information solicited by COMUS during the generation of the build runstream has
changed. Refer to "2.7 Generating Alternate WMQ2200 Installations Using COMUS"
for more information.
• If you plan to install an additional WMQ2200 product with OS 2200 QProcessor on
your system, there is some configuration required. Refer to the ClearPath
Specialty Engine for OS 2200 Configuration Guide for information on how to do
this.
• For user programs to begin using MQI, the background daemon must first be
running and connected to the OS 2200 QProcessor. See the administration section
for directions on how to start and terminate the daemon run.
• The background daemon run accepts console keyins to control the WMQ2200
subsystem and API connection. The MQADMIN interface is integrated into the
background daemon.
• You no longer need the Exec configuration parameter HVTIPMACT set to true
when running HVTIP transactions that invoke MQI.
• Use the mqs$entry object module from the *mqs$lib file as the element
name of WMQ2200 RM XA gate bank object module in the Open DTP rminstall run
stream. This replaces the MQS2200 UNX-gates object module in the new
environment.
• There is a new and convenient web-based administrator interface used for
deployment and administration called the OS 2200 QProcessor Administration
Console. Refer to Appendix G for more information on how to use this console.
• The WMQ2200 product has not been validated for message recovery in an XTC
environment on a remote or alternate host.
• You no longer need to have the Exec configuration parameter NPECTRL set to
TRUE.
1.7.2. Administrative Differences
• The UNX shell communicates directly with the OS 2200 QProcessor operating
system. As a result, UNX help command operations are different. See Appendix F,
"UNX Shell," for more details.
• There are some new configuration tags to be aware of: ConvertMQMDE,
DaemonKeyId, LinuxIP, LinuxPort, ICLogLevel, MQLogLevel, MonitorInterval,
TermWaitTime, AffinitizeWaitTime, HighOffloadCount, LowOffloadCount,
MaxOffloads, LogMQAuthorityErrors, PrintConnectionDownWarnings. These are
described in Section 2,"Installation and Configuration."
• Since WebSphere MQ queue managers run on the OS 2200 QProcessor, START
and FIN messages for WebSphere MQ programs are no longer printed to the OS
2200 console.
• The daemon background run print files are now cycled and named
*daemon$out.
1–22 3843 3744–002

What’s Different?
• Since the WebSphere MQ queue manager objects, queue files, and log files now
reside on the OS 2200 QProcessor, there are no TIP file system writes to be
audited on the OS 2200 for purposes of OS 2200 Integrated Recovery. See the
section on Recovery Procedures for information on recovery under WMQ2200.
• The OS 2200 background daemon run does not set the run condition word.
• Configuration tags ICLogLevel and MQLogLevel are provided to enable different
levels of WMQ2200, OS 2200 (and OS 2200 QProcessor) tracing and logging. The
OS 2200 traces are collected through the DDP trace facility. You can use the
ICADMIN processor to collect current traces (done by the diagn/run) or there are
DDP trace add streams in the *mqstools file that allow you to select a specific
DDP trace or log file. Use the OS 2200 QProcessor Administration Console
interface to collect the generated OS 2200 QProcessor traces.
• The TED editor commands have changed. See Appendix C, "Editing WMQ2200
QProcessor Files," for commands that can be used.
• The OS 2200 QProcessor provides a clustering capability for High Availability (HA).
Refer to Section 6, "High Availability," for more information.
• Websphere MQ listeners started with the runmqlsr command do not terminate
when the queue manager ends. You must end listeners with the endmqlsr
command manually. Optionally, you can define and start listeners with the MQSC
DEFINE LISTENER command or use the queue manager’s start and stop scripts
provided by the WMQ2200.SERVICE object to start and stop listeners.
1.7.3. Programming Differences
• If you are linking new COBOL applications, you must include object module
*mqs$lib.cbl$entry in your program links. This object module replaces
the mqs$entry object module used by MQS2200. Your current MQS2200 COBOL
(and UC) applications should continue to work without relinking; if you have
installed the new WMQ2200 at the same BDIs as your previous MQS2200
installation.
• A user-written MQS2200 trigger monitor does not work correctly without
updating and relinking it under WMQ2200.The MQGMO_CONVERT option must be
set for the MQGET from the initiation queue.
• MQCONNX performs the same function as MQCONN (connect to a queue
manager) but it accepts extra parameters that allows the user to specify extra
connection options with special settings and attributes set. MQCONNX is now
supported with the following limitations:
− MQCNO (Connect Options structure) must be a Version 1 format structure.
− The MQCNO_HANDLE_SHARE_BLOCK, MQCNO_SHARE_NO_BLOCK, and
MQCNO_FASTPATH_BINDING Options values are accepted but ignored.
• Object module mqs$entryst is no longer needed in the link of programs that want
to stick. For sticking UC programs, include mqs$entry object module; for sticking
COBOL programs include cbl$entry object module.
• Sticking is no longer restricted for TIP/HVTIP OLTP servers.
3843 3744–002 1–23

What’s Different?
1.7.4. Security
In previous implementations of MQSeries for ClearPath OS 2200 (MQS2200), it was
possible that a message would never physically leave the OS 2200 operating
environment. An example of this is a message that is created and consumed on the
same OS 2200 as it flows through its normal business logic. This meant that the
well-known security attributes of the OS 2200 environment would apply at all times to
messages being handled by MQS2200. With the use of the Specialty Engine and the
new version of MQSeries for ClearPath OS 2200 (WMQ2200), messages are now
stored on a separate system that has its own rules with regard to system access. A
WMQ2200 user must review the message content for security purposes and decide
whether the message content must be encrypted at the application layer.
In addition, WebSphere MQ has a way to customize its behavior at various functional
levels called API exits. The use of API exits can create security-related issues. For
example, consider the case of a customer using a CHANNEL exit with MQS2200 to
encrypt a message prior to its leaving the OS 2200 system. With WMQ2200, the code
is no longer deployed on the OS 2200 but on the OS 2200 QProcessor. This means
that the message follows the same data flow as previously mentioned and is
unencrypted for some period of time on a non-OS 2200 environment. The WMQ2200
user must review their security requirements and make any required modifications to
their application if they use exit functionality.
1–24 3843 3744–002

Section 2
Installation and Configuration
This section discusses the processes involved before using WMQ2200 for the first
time. The following table outlines the steps in the process. You can use this table as a
checklist to track your progress.
Step Description Reference √
1 Read some practical information before
installing WMQ2200.
2 Install WMQ2200. 2.2
3 Verify the installation and configuration. 2.3
4 Adjusting WMQ2200 Configuration
Parameters
5 Setting up Communications 2.5
6 Advanced configurations 2.6
7 Generating alternate WMQ2200 installations
using COMUS
8 Multiple WMQ2200 Installations as Static
Resource Managers under Open DTP
2.1. Before You Install WMQ2200
This subsection provides some practical information for you to read before you begin
the WMQ2200 installation process.
2.1.1. Release Media
WMQ2200 software is supplied on a Solar-installable (Software Library Administrator)
tape. Tape assign options are TF (Tape File) and tape device type is VTS (Virtual Tape
Solution).
Note: WMQ2200 is based on version 6.0 of WebSphere MQ for Linux and was
developed by Unisys under license from IBM. The product is released as an
absolute-only product.
3843 3744–002 2–1
2.1
2.4
2.7
2.8

Before You Install WMQ2200
If WMQ2200 is being installed using the INSTALLPKG runstream, a specific mode must
be selected instead of choosing to install the default mode. Following is an example
for INSTALLPKG install of WMQ2200 mode WMQ$A:
>Install from , DISK, or RSS? >
>Enter reel number >T09999
>Install default modes? /N >N
>Enter product name,level,mode (xmit if done)
>WMQ2200,6R1,WMQ$A
>Enter logical package name,level >
>
>Enter product name,level,mode (xmit if done) >
>Register package also? Y/ >Y
Note: A separate runstream must be created for the OS 2200 install and each
OS 2200 QProcessor install.
2.1.2. Installation and Migration Considerations
Upgrading from MQS2200
Existing MQS2200 users have three options:
• Replacement – remove all existing queue manager data by uninstalling the existing
MQS2200 product and then installing WMQ2200.
Notes:
• This option requires that you be responsible for recreating any queue
manager data including messages and objects as they will be destroyed by
the uninstall.
• This option enables you to use the current MQS2200 application programs
without changing or re-linking except for multi-byte data that is passed
when using the user-defined message format capability. See “User-Defined
Message Format Conversion” in Section 4, for more information.
• Co-install – retain the existing MQS2200 installation alongside your new
WMQ2200 installation by generating and installing an alternate BDI version of
WMQ2200.
Note: This option requires you to re-link the current MQS2200 application
programs to access the alternate-BDI WMQ2200 installation.
• Migration – retain the existing queue manager data by following the migration
procedure.
Note: This option enables you to use the current MQS2200 application
programs without changing or re-linking except for multi-byte data that is
passed when using the user-defined message format capability. See “User-
Defined Message Format Conversion” in Section 4, for more information.
2–2 3843 3744–002

Option A, Replacement
This option can be used if
Before You Install WMQ2200
• You do not have any messages on your queues that need to be saved.
• You either have an alternate way to recreate your objects such as OS 2200
addstream or you do not wish to save your current objects.
This option does not retain any MQS2200 queue managers, associated objects, or
messages on local queues.
1. Verify you have no necessary queue data on the local MQS2200 queues.
2. Uninstall MQS2200.
3. Install WMQ2200 to both the OS 2200 and the OS 2200 QProcessors.
4. Create user IDs and groups on the OS 2200 QProcessors.
5. Create your queue managers and their associated objects.
This process assumes you have a default BDI version of MQS2200 installed and are
replacing it with a default BDI version of WMQ2200. If this is not the case, you must
build an alternate BDI version of WMQ2200 using the same BDIs as MQS2200. Refer
to "2.7 Generating Alternate WMQ2200 Installations Using COMUS" for more
information.
Option B, Co-install
This option allows you to run the new WMQ2200 product alongside the existing
MQS2200 product. This scenario might be used if you want to run a test version of
WMQ2200 while your MQS2200 remains in production.
This option requires generating an alternate WMQ2200 installation with alternate BDIs
by using the COMUS build process. The existing applications are still linked to
MQS2200. The new or alternate applications must be linked to use the new
WMQ2200 BDIs. Refer to "2.7 Generating Alternate WMQ2200 Installations using
COMUS" for more information.
Option C, Migration
This option can be used if you migrate messages on local queues, user IDs, group IDs,
or queue managers and their objects.
This option has two different scenarios. The first scenario involves migrating from
MQS2200 to WMQ2200 within the same OS 2200 system. The second scenario
involves migrating from MQS2200 to WMQ2200 on a different OS 2200 system.
If you migrate within the same OS 2200 system, perform the following steps:
1. Install WMQ2200 to the OS 2200 QProcessor.
2. Migrate objects, local queue messages, user IDs, and group IDs automatically.
3. Uninstall MQS2200.
4. Install WMQ2200 to the OS 2200 using the original MQS2200 BDIs.
3843 3744–002 2–3

Before You Install WMQ2200
If you migrate to a different OS 2200 system, perform the following steps:
1. Install the complete WMQ2200 product to the OS 2200 QProcessor and the
OS 2200 using the original MQS2200 BDIs.
2. Migrate objects, local queue messages, user IDs, and group IDs automatically.
Note: The migration is simpler and less time consuming if you do not migrate
objects and queue data and have an ECL runstream for creating the queue managers
and their associated objects. If this is the case, consider option A, replacement.
The following steps show how to migrate from MQS2200 to WMQ2200 without losing
any objects such as queue managers, queues, channels, or any messages on existing
local queues. It allows you to selectively transfer queue managers and their
associated objects, and transfer any messages stored on their local queues.
To migrate from MQS2200 to WMQ2200, complete the following steps.
Step 1: Install from the WMQ2200 product tape
Use one of the following scenarios to install from the WMQ2200 product tape:
Scenarios Installation Procedures
Scenario one – migrating
within the same OS 2200
system
Scenario two – migrating to a
different OS 2200 system
Install only the WebSphere MQ RPM (RPM Package
Manager) files to the OS 2200 QProcessor using SOLAR.
To do this, select mode Q$x where x is the designated
OS 2200 QProcessor number as defined in the
IC$*PROCESSORS file.
Installing to the OS 2200 QProcessor alone does not
provide a fully functional WMQ2200, but instead creates
an environment that allows you to migrate objects and
messages from MQS2200 to the OS 2200 QProcessor.
The full WMQ2200 product is installed in a later step.
Install the complete WMQ2200 product to the new
system from the release tape using SOLAR. To do this,
• Select either WMQ$A or WMQ$B modes to install to
the OS 2200.
• Select the Q$x mode to install the product on the
OS 2200 QProcessor, where x is the designated
OS 2200 QProcessor number.
Refer to "2.2 Installing WebSphere MQ for ClearPath OS 2200," for information on
installing WMQ2200.
2–4 3843 3744–002

Before You Install WMQ2200
Step 2: Download the IBM SupportPac MO03: WebSphere MQ Queue Load
/ Unload Utility
This step requires the MO03 utility to load and unload messages off queues. The
MO03 SupportPac can be found at the following URL:
http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg24009368&loc=en_US&cs=utf-8&lang=en
Follow the instructions on the Web page of the above URL to download the MO03.zip
file to your PC. After you have saved the zip file on your PC, unzip the files and transfer
the qload file from the Linux Intel 64 folder to the /opt/mqm/supportpacs/qload
directory on the OS 2200 QProcessor.
You can use the OS 2200 QProcessor Administration Console to transfer the qload
utility by following these instructions:
1. Log in to the OS 2200 QProcessor Administration Console.
2. Select Upload and Download.
3. Under Files to upload, browse and select the Linux Intel 64 version of the qload
utility.
4. Under File or directory to upload to, browse to the /opt/mqm/supportpacs
directory.
5. Type mqm in the owned by user text box.
6. Click Upload.
7. Select Command Shell on the OS 2200 QProcessor Administration Console.
8. Type chmod a+x /opt/mqm/supportpacs/qload and click Execute
command to set the correct permissions on the qload utility.
Step 3: Prepare for queue manager, user ID, and group ID migration
Perform the following steps on the OS 2200 where MQS2200 resides for both
migration scenarios.
1. In order to migrate queue manager, user ID, and group ID information, copy the
fourth and seventh files from the WMQ2200 product tape. Catalog two files as
shown in the following example:
>@cat,p WMQ$RPM*TOOLS.,///500
>@cat,p WMQ$RPM*MQS$LIB.,///500
Ensure that you use the file names WMQ$RPM*TOOLS and
WMQ$RPM*MQS$LIB as they are referenced by the migration tools.
2. Assign the product file tape and copy the tools and library file using the following
example:
>@asg,tf t.,vts,
>@move t.,3
>@copy,g t.,WMQ$RPM*MQS$LIB.
>@move t.,2
3843 3744–002 2–5

Before You Install WMQ2200
>@copy,g t.,WMQ$RPM*TOOLS.
>@free t.
Step 4: Migrate user IDs and group IDs from MQS2200 to WMQ2200
A user with an OS 2200 user ID mapped to root on the OS 2200 QProcessor (see "The
OS 2200 QProcessor User Mappings" in Section 3, "Administration") must run the
migrate/users SSG addstream. This creates a runstream in file mq*export$out for
exporting MQS2200 group/passwd files to the WMQ2200 user map file. The
migrate/users addstream calls the exportusers utility to extract the password and
group files from MQS2200 and populate the password and group files on the OS 2200
QProcessor.
Perform the following steps on the OS 2200 system where MQS2200 resides for both
migration scenarios:
1. Generate the migration addstream.
Sample Execution
The following is a sample execution of migrate/users.
>@ADD WMQ$RPM*TOOLS.MIGRATE/USERS
>Enter the qualifier of your MQS2200 subsystem, >MQS$
>I:002333 ASG complete.
>****************************************
>* 1. Check results in migrate$out. *
>* 2. Optionally update mq*export$out. *
>****************************************
The addstream generates another addstream for the actual migration. Enter the
MQS2200 file set qualifier in place of . Do the following:
• View breakpoint file migrate$out and make sure no errors occurred during the
execution of the addstream.
• View and optionally update file mq*export$out. Check the generated
addstream in file mq*export$out making sure the mquseradd commands are
formatted correctly. You can use the shell command mquseradd to add a
remote user ID on the OS 2200 QProcessor or an OS 2200 user mapping to a
remote user ID. Refer to “Appendix F UNX Shell,” for a description of the
format for the mquseradd command.
Section “3.4.11 The OS 2200 QProcessor User Mappings" has a complete
description of the OS 2200 QProcessor user mappings. A remote user account
is a user account created on the OS 2200 QProcessor for purposes of OAM
enforcement. An OS 2200 user mapping is an entry in the user map table that
maps an OS 2200 user to an OS 2200 QProcessor account.
2–6 3843 3744–002

Before You Install WMQ2200
If there are any non-OS 2200 users in the mq*export$out file, change the
mquseradd option from O (OS2200 user ID) to R (remote user ID). For
example, if the mquseradd command is migrating an MQS2200 user ID that
represents a Windows user ID, change the mquseradd command to use the -R
option. You can add a Windows user ID to the MQS2200 /etc/passwd file so
that you can configure your OAM-enabled MQS2200 queue manager to allow
access through the client connection to the foreign user ID.
The following example shows how to change an incorrect mquseradd
command:
Change from: mquseradd -O -g mqm admin
Change to: mquseradd -R -g mqm admin
2. Execute the generated runstream on the system.
Use one of the following scenarios to execute the generated runstream.
Scenarios Execution Procedures
Scenario one – migrating
within the same OS 2200
system
Scenario two – migrating to
a different OS 2200 system
Add the wmq-migrate/users runstream out of the
WMQ$RPM*TOOLS file specifying the OS 2200 QProcessor
designation number in place of .
Example:
>@add WMQ$RPM*TOOLS.WMQ-MIGRATE/USERS
>Enter QProcessor designation number, >1
>I:002333 CAT complete.
>I:002333 ASG complete.
>*** Check results in P$MIGUSER. ***
1. Transfer the mq*export$out file from the MQS2200
system to the system to which you are migrating.
Ensure that you use the filename mq*export$out as this
file is called by WMQ-MIGRATE/USERS.
2. Add the wmq-migrate/users runstream out of the
installed WMQ$*MQSTOOLS file while specifying the
OS 2200 QProcessor designation number in place of .
Example:
3. Verify the results in P$MIGUSER.
>@add WMQ$*MQSTOOLS.WMQ-MIGRATE/USERS
>Enter QProcessor designation number, >1
>I:002333 CAT complete.
>I:002333 ASG complete.
>*** Check results in P$MIGUSER. ***
Check the breakpoint file P$MIGUSER to make sure that the MQS2200 user IDs
are successfully added to the OS 2200 QProcessor. Look at the output of
mquserlist -O (the OS 2200 user IDs) and mquserlist –R (the remote user IDs).
3843 3744–002 2–7

Before You Install WMQ2200
Example of a valid mquserlist –O:
>-MQS-:root:root
>INSTALL:root:root
>MQM:mqm:mqm
>CLE:IC-CLE:mqm
Example of a valid mquserlist –R:
>root
>mqm
Step 5: Create the object and data migration addstream using the
migrate/qmgrs SSG skeleton
The user running the migrate/qmgrs SSG needs to be in the mqm group. Ensure that
the user applications are not putting or receiving messages. Also, enable all the
queues for put and get.
The following table identifies the input required by the migrate/qmgrs skeleton.
Input Description Example
MQS2200 file set qualifier wmq$
QProcessor designation number 1
The IP address of the OS 2200 hosting the
MQS2200 installation
The total number of queue managers you
want to migrate
The name of the first queue manager qmgr1
The name of the second queue manager qmgr2
The port number used by the listener for
The port number used by the listener for
191.82.923.283
2–8 3843 3744–002
2
6001
6002
While creating the data migration addstream, if you answer “N” to the “Are you
migrating MQS2200 to WMQ2200 on the same OS 2200 system” query, you will get
the following additional input:
Input Description Example
Tape number to store migration files T09643
Tape device such as HICL, HICM, or VTS HICM
Tape assign options such as TJ or TF TF
The tape label name Tape

Before You Install WMQ2200
For the migration, the new WMQ2200 queue manager uses a client connection to the
old MQS2200 queue manager to migrate messages. This requires the MQS2200
queue manager to have a client channel (SVRCONN) and a listener to accept the
connection from the new queue manager. Because of this, a SVRCONN channel is
defined under the MQS2200 queue manager. Start a listener at an identified port, if not
already started. This port number can be a free port number or a port number of a
currently running listener for the queue manager in question. The SAVEQMGR utility is
also used to save MQS2200 runmqsc definitions for migration to WMQ2200.
• Scenario one - migrating within the same OS 2200 system:
Following is a sample execution of creating a data migration addstream.
>@ADD WMQ$RPM*TOOLS.MIGRATE/QMGRS
>Are you migrating MQS2200 to WMQ2200 on the same OS 2200 system
/N?>Y
>Enter the qualifier of your MQS2200 subsystem, >
>Enter QProcessor designation number, >
>Enter your MQS2200 host IP address>
>Enter total number of queue manager(s) you want to
migrate:>
>Enter a queue manager name that you want to migrate.>
>Do have a listener running on MQS2200 for queue manager
'qmgr1'that can be used for migration y/?>N
>Please specify a free port number that can be used for migration
by the listener for queue manager 'qmgr1':>
>Enter a queue manager name that you want to migrate.>
>Do have a listener running on MQS2200 for queue manager
'qmgr2'that can be used for migration y/?>Y
>Please specify the port number being used by the MQS2200 listener
for queue manager 'qmgr2' you would like to use:>
*** Add stream placed in tpf$.migrate/qmgrs ***
• Scenario two – migrating to a different OS 2200 system.
The following addstream generates a program file MQ*MQS2200MIG that is
transferred to the OS 2200 system where the new WMQ2200 installation resides.
This program file can be transferred by tape or by any other method such as FTP.
If you want to transfer it using a tape, you must know the tape number before
executing the addstream.
Following is a sample execution of creating a data migration addstream.
>@ADD WMQ$RPM*TOOLS.MIGRATE/QMGRS
>Are you migrating MQS2200 to WMQ2200 on the same OS 2200 system
/N?>N
>Do you wish to transfer migration files using tape /N?>Y
>Please enter tape number (Reel Id)>
>Please enter tape device Type HICL/HICM>
>Please enter tape assign Options (/TF)>
>Please enter the tape label name.>
>Enter the qualifier of your MQS2200 subsystem, >
>Enter QProcessor designation number, >
3843 3744–002 2–9

Before You Install WMQ2200
>Enter your MQS2200 host IP address >
>Enter total number of queue manager(s) you want to
migrate:>
>Enter a queue manager name that you want to migrate.>
>Do have a listener running on MQS2200 for queue manager
'qmgr1'that can be used for migration y/?>N
>Please specify a free port number that can be used for migration
by the listener for queue manager 'qmgr1':>
>Enter a queue manager name that you want to migrate.>
>Do have a listener running on MQS2200 for queue manager
'qmgr2'that can be used for migration y/?>Y
>Please specify the port number being used by the MQS2200 listener
for queue manager 'qmgr2' you would like to use:>
*** Add stream placed in tpf$.migrate/qmgrs ***
Step 6: Review the resulting migration addstream, TPF$.migrate/qmgrs
The migrate/qmgrs addstream is saved temporarily in TPF$. Save the migrate/qmgrs
addstream permanently in a user file and review. Unless edited and modified, the
addstream saves the objects of all queue managers and all queue data.
Step 7: Terminate all user applications that use the MQS API
While migrating objects and data, an active application cannot issue MQPUT calls to
put messages on queues or MQGET calls to retrieve messages from queues.
Step 8: Run the object migration addstream
Use one of the following scenarios to run the object migration addstream.
Scenarios Execution Procedures
Scenario one – migrating
within the same OS 2200
system
Example
>@add tpf$.migrate/qmgrs
Note: Although the previous example shows the execution
of migrate/qmgrs out of tpf$, it is recommended that you
save and execute the runstream out of your own user file.
2–10 3843 3744–002

Scenarios Execution Procedures
Scenario two – migrating to
a different OS 2200 system Example
>@add tpf$.migrate/qmgrs
Before You Install WMQ2200
Note: Although the previous example shows the execution
of migrate/qmgrs out of tpf$, it is recommended that you
save and execute the runstream out of your own user file.
If you use a tape to transfer the migration file, copy the
migration file MQ*MQS2200MIG off the tape to the
WMQ2200 system.
Example:
>@cat,p MQ*MQS2200MIG.,///99999
>@asg,tf t.,HICM,
>@copy,g t.,MQ*MQS2200MIG.
>@free t.
If you use any other method to transfer the migration file,
make sure to use the filename ‘MQ*MQS2200MIG’.
Once you copy file MQ*MQS2200MIG to the different
OS 2200 system, add the wmq-migrate/qmgrs.SSG skeleton
in the WMQ2200 system and verify the result.
Example:
Step 9: Verify the migration results
>@ADD WMQ$*MQSTOOLS.WMQ-MIGRATE/QMGRS
The output of the migration addstream is captured in the P$MIGRATE file.
Before completing the installation make sure you do the following:
• Review the file for possible errors before continuing.
• Verify that the migration of all objects from MQS2200 to WMQ2200 is successful
by ensuring no errors occur on queue manager, queues, and channels creation.
• Ensure that all messages are migrated to the OS 2200 QProcessor if you have any
queues with messages. For each queue migrated from MQS2200, the results of
the write function of the message data to the OS 2200 QProcessor file is similar to
the following:
Read - Files: 0 Messages: 100 Bytes: 102400
Written - Files: 1 Messages: 100 Bytes: 102400
• The OS 2200 QProcessor file data is then written to the queue on the OS 2200
QProcessor. The output is similar to the following:
Read - Files: 1 Messages: 100 Bytes: 102400
Written - Files: 0 Messages: 100 Bytes: 102400
3843 3744–002 2–11

Before You Install WMQ2200
• Ensure there are no errors generated by the QLOAD. For example,
MQCONN on object 'qmgr_1' returned 2058 QMgr name error.
If you use OAM on your MQS2200, your queue manager authorities are migrated
to the OS 2200 QProcessor. The amqoamd command is executed in MQS2200,
which creates authorization definitions for each queue manager objects (setmqaut
commands). These setmqaut commands are then executed for each queue
manager in the OS 2200 QProcessor.
• Verify that all the setmqaut commands return the following message:
The setmqaut command completed successfully.
Step 10: Complete the installation
Use one of the following scenarios to complete the installation.
Scenarios Execution Procedures
Scenario one – migrating
within the same OS 2200
system
Scenario two – migrating to
a different OS 2200 system
To complete the installation, perform the following:
1. Terminate all MQS2200 batch runs including queue
managers and listeners.
2. Ensure that the SOLAR-installed MQS2200 files are not
assigned by anyone.
3. It is recommended that you do the following:
• Make a backup copy of the System Services files.
• Backup your queue manager data by executing
MQSAVE utility from the MQS$EXE file. If the
migration fails and you have to revert to the
MQS2200 installation, restore the System Services
files or execute the MQLOAD to restore the queue
manager data.
4. Using SOLAR, uninstall MQS2200 to free up its BDIs for
use by WMQ2200, when all the objects and queue data
are transferred to the WMQ2200.
5. Install WMQ2200 to the OS 2200 using the original
MQS2200 BDIs.
Use installation mode WMQ$A (or WMQ$B if the BIS
interface is required) to install WMQ2200 to the OS 2200
and complete the product installation.
Refer to "2.2 Installing WebSphere MQ for ClearPath
OS 2200" for information on how to install WMQ2200 to
the OS 2200. By reinstalling WMQ2200 with the original
MQS2200 BDIs, you do not have to relink your
applications.
The installation is complete. No further action is required.
2–12 3843 3744–002

Upgrading from a Previous Level of WMQ2200
Preparation
Before You Install WMQ2200
If you are also updating your Linux System Software image make sure to use one of
the following options to save your queue manager objects and data before updating
your image and your WMQ2200 level.
Option 1: Backup and restore your queue manager objects and data using
UNX shell commands
1. Backup your queue manager objects and data using the mqsave UNX shell
command.
2. Update the Linux System Software image.
3. Install new level of WMQ2200.
4. Restore your queue manager objects using the mqload UNX shell command.
Option 2: Use the OS 2200 Administration Console Filesystem Backup
feature
1. Use the OS 2200 Administration Console Filesystem Backup module to backup a
profile that includes your /var/mqm directory to the OS 2200 or an external disk.
2. Update the Linux System Software.
3. Install new level of WMQ2200.
4. Restore your queue manager objects using the Filesystem Backup module.
Installing a new level of WMQ2200 first removes the MQS subsystem as well as the
previously installed WebSphere MQ RPM on the OS 2200 QProcessor. Installing a new
level of WMQ2200 does not affect your queue manager objects or queue data. In
other words, the content of /var/mqm is not removed.
Choose one of the following procedures depending upon whether or not you are
upgrading a HA environment. The OS 2200 QProcessor provides a clustering capability
for high availability known as HA cluster. Refer to Section 6, "High Availability," for
more information.
Non-HA environment
When upgrading to a new WMQ2200 level you must first:
1. Terminate all user applications that use the MQI API.
2. Terminate all WMQ2200 queue managers and listeners using one of the following
methods
• Use the OS 2200 QProcessor Administration Console to stop all your queue
managers and listeners
Or
3843 3744–002 2–13

Before You Install WMQ2200
• Use the UNX demand shell as follows:
a. Call the UNX demand shell @wmq$*mqs$exe.unx.
b. Use the dspmq command to display the state of all the queue managers
on the system.
c. Stop any listeners associated with the queue managers, using the
command:
endmqlsr -m QMgrName
d. Use the endmqm command to stop all running queue managers.
e. Ensure that you have stopped all of the necessary WebSphere MQ
processes by executing:
ps -ef | more
f. Check that there are no processes listed that are running command lines
beginning amq or runmq.
Note: The mqstatus daemon keyin can also be used to see if any
WebSphere MQ processes are active. Refer to Section 7, "Troubleshooting,"
for more information on using Daemon Keying. See Appendix F, "UNX Shell,"
for more information on using the UNX shell.
3. Shutdown the WMQ2200 daemon - @@cons wmq shutdown.
4. Install the new level of WMQ2200. Refer to "2.2 Installing WebSphere MQ for
ClearPath OS 2200" for more details.
5. On completing the installation, start your queue managers, listeners, and other
objects. For example, channels.
Ensure none of the SOLAR-installed WMQ2200 files are assigned to anyone.
Specifically, check the wmq$*mqs$exe file and wmq$*mqs$om files.
HA environment
1. Terminate all user applications that use the MQI API.
2. On the cluster node that is running MQ resources, click Stop in the Manage High
Availability module of the OS 2200 QProcessor Administration Console for all
queue managers and their listeners. This will stop all MQ resources.
3. Use SOLAR to install the WMQ2200 update to both of the cluster nodes and the
OS 2200.
a. Use SOLAR to register the WMQ2200 install tape.
b. Use SOLAR to install the registered tape by selecting the product modes for
the systems you want to install. Generally, this will be mode WMQ$A for the
OS 2200 and modes Q$1 and Q$2 for the OS 2200 QProcessors. Your actual
mode selections will depend upon the OS 2200 mode selection and the
OS 2200 QProcessor Designation numbers used for your initial installation.
2–14 3843 3744–002

Before You Install WMQ2200
4. On completing the installation, on the same cluster node that is running MQ
resources:
a. Click Start in the Manage High Availability module of the OS 2200 QProcessor
Administration Console for all queue managers and their listeners.
b. Start any other necessary MQ objects. For example, channels.
5. Restart the user applications.
Ensure none of the SOLAR-installed WMQ2200 files are assigned to anyone.
Specifically, check the wmq$*mqs$exe file and wmq$*mqs$om files.
Refer to "2.2 Installing WebSphere MQ for ClearPath OS 2200" for more details.
2.1.3. MQ Performance Considerations
When running with an HA configuration or significant message traffic, a decision must
be made prior to the installation of WMQ2200 if it is appropriate to use internal drives
or if external drives are required. The main factors involved in this decision are the
message traffic rate in messages per second, average size of message, and their
arrival rate.
As a general performance guideline, the higher your message traffic rate in an HA
environment, the more likely the use of external disks will be required.
Consider as an example the following test case of persistent messages each of 2K
bytes in size. The test driver used multiple threads that could vary the delay time or
think time between messages being submitted. In the following table, the first test
case used zero think time between messages that were submitted. The second test
case result included a 5 millisecond pause between messages that were submitted.
The results are in messages handled per second.
Drives Zero Think
Time
5ms Think
Time
Internal drives 2515 479
Internal drives HA enabled 112 107
External drives 2479 479
External drives HA enabled 2450 479
The base configuration for internal disks is software RAID 1 with LVM and SNAPSHOT
enabled. Internal disks in an HA configuration use DRBD to mirror the disks between
systems. The SAN used for this test consisted of disks located in an EMC CX/3
subsystem using 4 Gb fibre channel connections. The disks in the EMC subsystem
were configured using hardware RAID10 with LVM and SNAPSHOT enabled.
As in all tests of this type, the individual results are different based on the
environment.
3843 3744–002 2–15

Installing WebSphere MQ for ClearPath OS 2200
The following are the conclusions drawn from the example:
• Performance using internal or external disks is roughly equivalent in an HA or
non-HA environment.
• The use of DRBD limits message throughput significantly compared to external
disks in an HA environment. If you expect significant message traffic, external
disks are required.
2.2. Installing WebSphere MQ for ClearPath
OS 2200
Install WMQ2200 from the release tape using the SOLAR processor. WMQ2200 is
contained on a labeled tape, so be sure to specify tape format TF instead of defaulting
to the TJ format. A complete installation of the product performs software installation
on both the OS 2200 and the OS 2200 QProcessor. WMQ2200 has two OS 2200
installation modes, and eight OS 2200 QProcessor installation modes as described in
the following text.
Installation Modes
Mode WMQ$A is the default installation mode and installs a set of seven OS 2200
files.
Mode WMQ$B also installs the same set of seven files. In addition, Mode WMQ$B
installs two files that provide the basic mode interface for the Business Information
Server for ClearPath OS 2200 product.
In addition, eight installation modes exist for installing to the OS 2200 QProcessor.
Installation modes Q$1, Q$2, Q$3, Q$4, Q$5, Q$6, Q$7, and Q$8 correspond to the
eight possible Specialty Engines as configured in the IC$*Processors file and managed
by the ICADMIN utility. Generally you will be using mode Q$1. In an HA environment,
you will typically be using modes Q$1 and Q$2. Refer to the ClearPath Specialty
Engine for OS 2200 Configuration Guide for more details on ICADMIN.
For each of the OS 2200 QProcessor installation modes (Q$1-Q$8), the following two
files are installed to the OS 2200.
• WMQ$*MQS$RPM –Set of RPM files that are installed on the OS 2200
QProcessor. This file is removed after the installation is complete.
• WMQ$*MQS$QP – Set of elements that control the installation and removal of
the WebSphere MQ RPM files on the OS 2200 QProcessor.
2–16 3843 3744–002

File Set Qualifier
Installing WebSphere MQ for ClearPath OS 2200
Unless generating an alternate WMQ2200 installation, you will be using the default
qualifier WMQ$. Refer to "2.7 Generating Alternate WMQ2200 Installations Using
COMUS," for more information on generating an alternate WMQ2200 installation at
your site.
Installation to the OS 2200 QProcessor is done through IC2200. All installations to the
OS 2200 QProcessor using a tape with the default qualifier, WMQ$, are preconfigured
in the IC$PROCESSOR file to install on host QPRM1 as described in the following text.
The Interconnect
The IC2200 software maintains a list of devices, associated WMQ2200 software
qualifiers, and other configuration information in the IC$*PROCESSORS public data file.
The last field of each entry in the IC$*Processors file defines the qualifier of the
WMQ2200 files installed on the OS 2200. By default, the qualifier is WMQ$. The host
field identifies the OS 2200 QProcessor, where the WebSphere MQ RPM files are
installed during an installation from a product tape using the associated WMQ2200
qualifier.
Following is an example of what the ICADMIN utility displays (using default values),
when responding to the list_processor command:
Processor Managed Processor Product
Type Num IC-Mode host:port Qualifier\Mode
JPROCESSOR 1 DEFAULT JPRM1:22719
QPROCESSOR 1 DEFAULT QPRM1:22719 WMQ$
Any installation from the Unisys supplied product tape uses a default qualifier of
WMQ$. This is true for all installation modes (WMQ$A, WMQ$B, and Q$1 - Q$8). In
this example, any installation to an OS 2200 QProcessor from the product tape using
the default qualifier, WMQ$, installs the RPM files on host QPRM1.
The Solar Installation
When installing from the default product tape, SOLAR displays the following screen
for WMQ2200:
Name Level Mode
< > WMQ2200 6R1 WMQ$A
< > WMQ2200 6R1 WMQ$B
< > WMQ2200 6R1 Q$1
< > WMQ2200 6R1 Q$2
3843 3744–002 2–17

Installing WebSphere MQ for ClearPath OS 2200
Name Level Mode
< > WMQ2200 6R1 Q$3
< > WMQ2200 6R1 Q$4
< > WMQ2200 6R1 Q$5
< > WMQ2200 6R1 Q$6
< > WMQ2200 6R1 Q$7
< > WMQ2200 6R1 Q$8
Although installing to the OS 2200 and the OS 2200 QProcessor can be done in two
different SOLAR sessions, it will typically be done in one. Select mode WMQ$A for a
default installation or WMQ$B for an installation supporting the basic mode interface,
and select one of the eight modes for installing to the OS 2200 QProcessor. This will
typically be Q$1.
As described earlier, the IC$*PROCESSORS file (administered by the ICADMIN tool)
controls the mapping of the chosen qualifier to an OS 2200 QProcessor.
Note: If configuring a standby device in an HA environment, select two OS 2200
QProcessor modes to install on multiple OS 2200 QProcessors.
Results of Installation
For both modes WMQ$A and WMQ$B, a successful installation of the WMQ2200
product catalogs and populates the following files in the OS 2200 environment:
• WMQ$*MQS$COMMON.
• WMQ$*MQS$LIB.
• WMQ$*MQS$EXE.
• WMQ$*MQS$RUN.
• WMQ$*MQS$SAMPLES.
• WMQ$*MQSTOOLS
• WMQ$*MQS$OM.
A successful mode WMQ$B installation also catalogs and populates these two files:
• WMQ$*MQS$BMCOMMON.
• WMQ$*MQS$BMLIB.
2–18 3843 3744–002

Installing WebSphere MQ for ClearPath OS 2200
The mode WMQ$A installation produces an entry like the following in the
SYS$*DATA$.CO$INSTALL$/COMUS$ element:
INSTALL ;
PRODUCT,WMQ2200,6R1 ;
MODE,WMQ$A,DEFAULT ;
TIME,100217,131927 ;
FILE,WMQ$*MQS$COMMON(1),9999,PACK,NOPREP,NOROLLOUT,WRITEABLE,FIXED_NAME ;
FILE,WMQ$*MQS$LIB(1),9999,PACK,PREP,NOROLLOUT,WRITEABLE,FIXED_NAME ;
FILE,WMQ$*MQS$EXE(1),20000,PACK,NOPREP,NOROLLOUT,WRITEABLE,FIXED_NAME ;
FILE,WMQ$*MQS$RUN(1),9999,PACK,NOPREP,NOROLLOUT,WRITEABLE,FIXED_NAME ;
FILE,WMQ$*MQS$SAMPLES(1),9999,PACK,NOPREP,NOROLLOUT,WRITEABLE,FIXED_NAME ;
FILE,WMQ$*MQSTOOLS(1),9999,PACK,NOPREP,NOROLLOUT,WRITEABLE,FIXED_NAME ;
FILE,WMQ$*MQS$OM(1),9999,PACK,NOPREP,NOROLLOUT,WRITEABLE,FIXED_NAME ;
CBD,0405477,WMQ$*MQS$COMMON(1),MQS-SSDEF$,'''',''FIXED GATE SUBSYSTEM'' ;
SSDEF,WMQ$*MQS$COMMON(1),MQS-SSDEF$,FIXED_GATE ;
CBD,0400436,WMQ$*MQS$COMMON(1),UNX-SSDEF$,'''',''FIXED GATE SUBSYSTEM'' ;
SSDEF,WMQ$*MQS$COMMON(1),UNX-SSDEF$,FIXED_GATE ;
STYLE ;
PACKAGE,WMQ2200,6R1,T12614,WMQ2200,6R1 ;
REGISTER,REG_CBD,'''','''','''' ;
$FIN
The mode WMQ$B installation produces an entry like the following in the
SYS$*DATA$.CO$INSTALL$/COMUS$ element:
INSTALL ;
PRODUCT,WMQ2200,6R1 ;
MODE,WMQ$A,DEFAULT ;
TIME,100217,131927 ;
FILE,WMQ$*MQS$COMMON(1),9999,PACK,NOPREP,NOROLLOUT,WRITEABLE,FIXED_NAME ;
FILE,WMQ$*MQS$LIB(1),9999,PACK,PREP,NOROLLOUT,WRITEABLE,FIXED_NAME ;
FILE,WMQ$*MQS$EXE(1),20000,PACK,NOPREP,NOROLLOUT,WRITEABLE,FIXED_NAME ;
FILE,WMQ$*MQS$RUN(1),9999,PACK,NOPREP,NOROLLOUT,WRITEABLE,FIXED_NAME ;
FILE,WMQ$*MQS$SAMPLES(1),9999,PACK,NOPREP,NOROLLOUT,WRITEABLE,FIXED_NAME ;
FILE,WMQ$*MQSTOOLS(1),9999,PACK,NOPREP,NOROLLOUT,WRITEABLE,FIXED_NAME ;
FILE,WMQ$*MQS$OM(1),9999,PACK,NOPREP,NOROLLOUT,WRITEABLE,FIXED_NAME ;
FILE,WMQ$*MQS$BMCOMMON(1),9999,PACK,NOPREP,NOROLLOUT,WRITEABLE,FIXED_NAME ;
FILE,WMQ$*MQS$BMLIB(1),9999,PACK,PREP,NOROLLOUT,WRITEABLE,FIXED_NAME ;
CBD,0405477,WMQ$*MQS$COMMON(1),MQS-SSDEF$,'''',''FIXED GATE SUBSYSTEM'' ;
SSDEF,WMQ$*MQS$COMMON(1),MQS-SSDEF$,FIXED_GATE ;
CBD,0400436,WMQ$*MQS$COMMON(1),UNX-SSDEF$,'''',''FIXED GATE SUBSYSTEM'' ;
SSDEF,WMQ$*MQS$COMMON(1),UNX-SSDEF$,FIXED_GATE ;
CBD,0404777,WMQ$*MQS$BMCOMMON(1),BM$MQSSSDEF$,'''',;
''FIXED GATE SUBSYSTEM'' ;
SSDEF,WMQ$*MQS$BMCOMMON(1),BM$MQSSSDEF$,FIXED_GATE ;
STYLE ;
PACKAGE,WMQ2200,6R1,T12614,WMQ2200,6R1 ;
REGISTER,REG_CBD,'''','''','''' ;
$FIN
3843 3744–002 2–19

Verifying the Installation and Configuration
A mode Q$1 installation catalogs file MQS$Q1 and produces an entry like the following
in the SYS$*DATA$.CO$INSTALL$/COMUS$ element:
INSTALL ;
PRODUCT,WMQ2200,6R1 ;
MODE,Q$1 ;
TIME,100217,131928 ;
FILE,WMQ$*MQS$Q1(1),9999,PACK,NOPREP,NOROLLOUT,WRITEABLE,FIXED_NAME ;
DEINSTALL_ROUTINE,WMQ$*MQS$Q1(1),Q$1/REMOVE,0 ;
STYLE ;
PACKAGE,WMQ2200,6R1,T12614,WMQ2200,6R1 ;
REGISTER,'''','''','''','''' ;
$FIN
For the installation, verification, and product usage to be successful, the file
WMQ$*MQS$COMMON, containing the subsystems required by the product must
have the correct owner if you are in a Security Level 1, 2, or 3 environment (SECOPT1,
SECOPT2, or SECOPT3). Refer to Section 1,"Introduction," for more information.
Note: See file /var/mqm/diag/WMQ.diagnostic on the OS 2200 QProcessor for the
results of the RPM installations. An installation always performs an uninstall
therefore, if the product RPM files were previously removed, a subsequent
installation now shows errors trying to remove the nonexistent RPM files. The
errors state that the files to uninstall do not exist. It is normal to see these errors in
this case. You can view the diagnostic file by navigating to the View System Logs
module in the Diagnostic section of the OS 2200 Administration Console or you can
use the UNX demand shell to view the WMQ.diagnostic file. See Appendix F for
information on UNX shell and the QProcessor Administration Console Help for
information on View System Logs.
After successful installation, you must configure WMQ2200. See the following
subsections for details.
2.3. Verifying the Installation and Configuration
After installing and configuring WMQ2200, execute a few simple commands to verify
the resulting files. You can verify your installation locally, without involving
communication links to other WebSphere MQ machines.
For example, type the following commands to install and test a simple configuration of
one queue manager and one queue.
• Bring up the daemon (See Appendix E, "WMQ2200 Daemon Administrative Utility,"
for more information.)
• Create and start a queue manager.
• Define a local queue.
• Put a message onto a queue.
2–20 3843 3744–002

• Read a message from a queue.
Verifying the Installation and Configuration
>@wmq$*mqs$exe.startup
>Daemon started successfully.
>Daemon connected to QProcessor successfully!
>API is ready for use.
>@wmq$*mqs$exe.unx
Unx - 6R1 - 2010 May 26 Tue 12:46:00
>16311#>crtmqm my.qmgr
>WebSphere MQ queue manager created.
>Creating or replacing default objects for my.qmgr.
>Default objects statistics : 40 created. 0 replaced. 0 failed.
>Completing setup.
>Setup completed.
>16311#>strmqm my.qmgr
>WebSphere MQ queue manager 'my.qmgr' starting.
>4 log records accessed on queue manager 'my.qmgr' during the log
replay phase.
>Log replay for queue manager 'my.qmgr' complete.
>Transaction manager state recovered for queue manager 'my.qmgr'.
-WebSphere MQ queue manager 'my.qmgr' started.
>16311#>runmqsc my.qmgr
>5724-H72 (C) Copyright IBM Corp. 1994, 2005. ALL RIGHTS RESERVED.
>Starting MQSC for queue manager my.qmgr..
>
>
>define qlocal (my.local.q)
>1 : define qlocal (my.local.q)
>AMQ8006: WebSphere MQ queue created.
>end
>2 : end
>One MQSC command read.
>No commands have a syntax error.
>16311#>exit
>exit
>
Note: Any text entered in MQSC in lowercase is converted automatically to
uppercase unless you enclose it in single quotes ( ' ). This means that if you create a
queue with the name my.local.q, you must remember to refer to it in any command
outside MQSC as MY.LOCAL.Q.
>@wmq$*mqs$samples.amqsput
>Usage: @Q*F.AMQSPUT QueueName [QMgrName]
>Enter parameter(s):> MY.LOCAL.Q my.qmgr
>Sample AMQSPUT0 start
>target queue is MY.LOCAL.Q
>installation test message
>xmit
>Sample AMQSPUT0 end
>@wmq$*mqs$samples.amqsget
>Usage: @Q*F.AMQSGET QueueName [QMgrName]
3843 3744–002 2–21

Adjusting WMQ2200 Configuration Parameters
>Enter parameter(s):>MY.LOCAL.Q my.qmgr
>Sample AMQSGET0 start
>message
>no more messages
>Sample AMQSGET0 end
The verification is complete.
2.4. Adjusting WMQ2200 Configuration
Parameters
You can customize WMQ2200 at your site by adjusting the WMQ2200 configuration
values as explained in the following subsections. WMQ2200 expects the configuration
element of the site, MQSERIES/CONFIG, to be in the WMQ$*MQS$CONFIG file. This
location is not overwritten by a subsequent install of WMQ2200.
If this is your first install of WMQ2200, file WMQ$*MQS$CONFIG is cataloged for you.
During the installation process, the administrator must review the installed WMQ2200
configuration file (WMQ$*MQSTOOLS.MQSERIES/CONFIG) to become familiar with
the default configuration values. A template configuration file can be found in the
WMQ$*MQSTOOLS.MQSERIES/CONFIG file.
Compare the content of the newly installed configuration template file to the contents
of any saved configuration file and to your site’s needs. Update the
WMQ$*MQS$CONFIG.MQSERIES/CONFIG file appropriately to reflect new, deleted, or
changed configuration parameters. You can also start fresh by replacing the saved file
with the installed configuration template file and then perform updates as needed.
Be sure to set up your WMQ$*MQS$CONFIG.MQSERIES/CONFIG file before starting
the WMQ2200 daemon.
You can modify the configuration parameters at any time, but most are referenced
only on the initial invocation of the MQS subsystem after installation or after the
subsystem is reloaded. Therefore, if you modify any of the values in your configuration
file, you must deactivate your MQS subsystem for the changes to take effect. Refer
to Section 7, "Troubleshooting," for more information on deactivating the WMQ2200
subsystems.
You will not need to change many of the values in the installed version of the
configuration file. For a production environment, Unisys recommends that you leave
most values unchanged. You are most likely to change the following values:
• ConvertMQMDE – automatically convert messages to or from the native encoding
of the queue manager.
• HighOffloadCount – maximum number of offloads at the current time.
• LowOffloadCount* – initial number of offloads started.
• MaxOffloads* – maximum number of offloads allowed.
2–22 3843 3744–002

Adjusting WMQ2200 Configuration Parameters
• McbEntryBdi – the MCBBNK CBD address that identifies the MCB instance
through which a user-written trigger monitor schedules TIP/HVTIP transaction
programs.
• MQAuthority – MQ OAM enablement.
• PrintConnectionDownWarnings – print a warning to the OS 2200 console when
the connection to the OS 2200 QProcessor is unavailable.
*Offloads are OS 2200 QProcessor processes. There should be one offload per
active MQ API user.
2.4.1. Configurable Values Summary
The following table summarizes the configurable values.
Note: The configuration parameter names are not case sensitive; however, the
values can be case sensitive.
Item Default Brief Explanation
AffinitizeWaitTime 0 Amount of time to wait for an offload to
become available to service an activity.
Negative value: infinite; Zero value: no wait;
positive value: number of seconds to wait.
BackgroundWait 15 seconds The number of seconds to wait for the
OS 2200 batch background daemon to
start.
BatchRunLoc no default, but it should
generally be
wmq$*mqs$run.mqsrun
ConvertMQMDE
Location of the OS 2200 batch background
daemon start stream.
Format: qualifier*filename.element/version.
OFF Determines whether MQMDE in user
messages must be automatically converted
to/from the queue manager’s native
encoding during MQPUT/MQPUT1 and
MQGET processing. To automatically
convert, set this to ‘ON’ and equate all
other values to OFF.
DaemonKeyId no default KEYIN$ id for unsolicited requests max of 8
characters (A-Z, 0-9, and *).
DaemonRetryInt 0 The number of seconds daemon should
wait between attempts to reestablish
communications with the OS 2200
QProcessor after the API connection is lost.
FileSystem no default, but it should be
wmq$ unless an alternate
installation mode is being
used
The OS 2200 qualifier of the installed
WMQ2200 product files.
Minimum: 1 character.
Maximum: 12 characters.
HighOffloadCount no default Maximum number of OS 2200 activities
that can be serviced at any given time.
3843 3744–002 2–23

Adjusting WMQ2200 Configuration Parameters
Item Default Brief Explanation
ICLogLevel 0 Initial IC log level. Valid values are:
LinuxIP no default
must normally be
172.28.102.10
LinuxPort no default
LogMQAuthorityEr
rors
must normally be 22719
0 = IC_LOG_ONLY
4 = IC_AUDIT
5 = IC_DEBUG
6 = IC_VERBOSE
Linux IP address
Port the IC tag launcher is bound to.
OFF Should MQ authority errors be logged to
the queue manager error logs? ON: yes;
OFF: no.
LowOffloadCount no default Minimum number of offloads to keep
running at all times waiting to service
OS 2200 activities.
MaxOffloads no default Maximum number of offloads that can ever
be started to service OS2200 activities.
McbEntryBdi 0 The installed MCB MCBBNK BDI that the
default trigger monitor uses to schedule
triggered TIP programs.
Form: 040nnnn. The MCB must have
UDBASE set to 0600000 or higher.
MonitorInterval 60 Monitor Interval for detecting loss of
OS 2200 QProcessor connectivity. Valid
values are 0-120 seconds. A value of 0
causes default of 60 seconds to be used.
MQAuthority OFF MQ OAM is enabled if ON, and is not
enabled if OFF.
MQLocalLanguage en Local language used. en, de, es, fr, it, and pt
MQLogLevel 0 Initial MQ log level. Valid values are:
PrintConnection
DownWarnings
0 = MQ_LOG_ONLY
4 = MQ_AUDIT
5 = MQ_DEBUG
6 = MQ_VERBOSE
ON Prints warning to console when API
connection to OS 2200 QProcessor is
unavailable.
RealTimeLevel 0 Real time level of the daemon run.
TermWaitTime 60 Timeout period to wait for offloads to
terminate on OS 2200 QProcessor before
causing them to terminate with a signal.
2–24 3843 3744–002

2.4.2. Configurable Values Detail
Adjusting WMQ2200 Configuration Parameters
This subsection describes each of the WMQ2200 configuration parameters in detail.
AffinitizeWaitTime
This is the amount of time to wait for an offload to become available to service an
activity.
Values
A negative value indicates an infinite wait. A value of zero indicates no wait. A positive
value indicates the number of seconds to wait. The default value is 0, no wait.
BackgroundWait
This defines the number of seconds to elapse before the STARTUP program assumes
the daemon is not going to start. If the timeout elapses, an error message is printed to
the user who executed STARTUP and the user must determine why the daemon run
did not start within the timeout period.
Values
BatchRunLoc
Any integer value can be used. The default value is 15 seconds. On a busy production
system, care must be taken not to set this value too low. The default value of 15 is
generally sufficient.
This is the location of the start runstream that starts the daemon. This must always be
qual*MQS$RUN.MQSRUN where qual is the qualifier of your installed WMQ2200 files.
Values
There is no default value, but for default installations of WMQ2200 this must be
‘wmq$*mqs$run.mqsrun’.
ConvertMQMDE
This determines whether MQMDE in user messages must be automatically converted
to or from the native encoding of the queue manager during MQPUT/MQPUT1 and
MQGET processing. An MQMDE is a message descriptor extension structure that can
be attached to a user message buffer to provide additional information about a
message. This is used when specialized or legacy applications are using a MQMD
version 1 and additional information not present in the MQMD version 1 needs to be
provided to the queue manager. If a MQMDE is provided in the user message during
an MQPUT or MQPUT1, it must conform to the following rules to be honored by the
queue manager:
• MQMDE must be at the start of the message data.
• MQMDE must be in the queue manager’s local encoding and character set.
3843 3744–002 2–25

Adjusting WMQ2200 Configuration Parameters
In the WMQ2200 environment, OS 2200 user applications run on a big endian
byte-ordering architecture (OS 2200), while the queue manager they interact with now
run on an OS 2200 QProcessor that is running on a little endian byte-ordering
architecture (Linux). This means that user applications on the OS 2200 that put
messages containing an MQMDE in the local encoding for the OS 2200 are not in the
local encoding of the queue manager. This has the effect of causing the queue
manager to accept, but not honor, MQMDE structures in messages put from the OS
2200. This means the message is put to the queue, but the MQMDE is not used by the
queue manager. Instead, it is not used and treated as ordinary message data. Also,
when messages are retrieved from queues, they can contain an MQMDE that is in the
queue manager’s local encoding, but not the local encoding of the OS 2200 user
application.
To provide backward compatibility for legacy applications, the WMQ2200 subsystem
provides this configuration tag. If this tag is enabled, the WMQ2200 subsystem
converts any outgoing MQMDE in user message data to the queue manager’s local
encoding before the MQPUT or MQPUT1 is performed. Conversely, the subsystem
converts MQMDE in message data to the local encoding of the OS 2200 applications
before the MQGET returns.
If this tag is not enabled and an OS 2200 user application does a MQPUT or MQPUT1
of a message containing an MQMDE, the put is accepted but the MQMDE is not
honored by the queue manager. On an MQGET, the MQMDE returned in the user
message is returned in its original encoding (which might be different than the OS
2200 local encoding).
The subsystem only converts MQMDE structures if
• They are at the beginning of the user message.
• They are in the wrong encoding given the destination.
• The user message is large enough to accommodate an MQMDE.
• The Format field of the MQMD provided with the message is
MQMFT_MD_EXTENSION.
Note: Whether the queue manager ultimately honors an MQMDE is subject to all of
the rules set forth in the WebSphere MQ Application Programming Reference
manual.
Values
ON specifies that the WMQ2200 subsystem must automatically convert MQMDE
structures at the beginning of user messages to the native encoding relative to its
destination. Any other value equates to OFF. Default is off.
2–26 3843 3744–002

DaemonKeyId
Adjusting WMQ2200 Configuration Parameters
This defines the keyin that the daemon must register with the EXEC to accept
unsolicited input from a console. This is the keyin used to interact with the daemon.
The daemon stores the information such as the output, error logs, and diagnostics in
several places. The daemon can also display the following information:
1. Responses to the unsolicited input with console keyins are sent back to the
terminal that sent the unsolicited keyin. In some cases, a message might be
printed to the main console as well if the terminal that sent the unsolicited input
was not the main console.
2. Errors and other status information is stored in the DAEMON$OUT file which is
used as the breakpoint file in the MQS$RUN.MQSRUN file that is used to start the
daemon. This file can be inspected for errors. Contingency snaps and other
information can be found in this file, if the daemon terminates in error.
3. If the daemon encounters a contingency and aborts, the DAEMON$DIAG file might
contain a PADS diagnostic file for post-mortem debugging.
4. DDP trace and log files is the primary location where trace and log data is stored
for debugging. The level of the trace/log level is determined by the MQLOG and
ICLOG keyins as described in the following sections.
Values
By default, the keyin identifier is the same as your subsystem qualifier. However, a
keyin cannot contain certain characters including a dollar sign ($). Therefore, if your
subsystem qualifier contains a dollar sign, it is omitted from the DaemonKeyId
specification. The DaemonKeyID for the default qualifier, WMQ$, is WMQ.
DaemonRetryInt
This is the number of seconds the daemon should wait between attempts to
reestablish communications with the OS 2200 QProcessor after the API connection is
lost. If configured, the daemon will automatically attempt to reestablish
communications with the OS 2200 QProcessor after the API connection is terminated
abnormally. The daemon will not attempt to reconnect the API connection if the user
terminates the API connection administratively using the SHUTDOWN or DOWN
keyins. The configured retry interval and whether the daemon is currently retrying the
API connection can be determined with the APISTATUS keyin. User applications that
were connected to queue managers before the connection terminated are required to
perform a new MQCONN. This is to reestablish communication with the queue
manager after the API connection is restored. User applications can attempt an
MQCONN periodically until the API connection is restored, at which point the
MQCONN should succeed.
You can display the values related to the DaemonRetryInt using the APISTATUS keyin.
The Automatic Reconnect field specifies whether automatic reconnects are enabled.
The Currently Retrying field specifies whether the daemon currently attempts to
reconnect to the OS 2200 QProcessor. The Reconnect Interval field displays the
number of seconds between retries.
3843 3744–002 2–27

Adjusting WMQ2200 Configuration Parameters
Note: It is important that the DaemonRetryInt value is set to a value greater than
zero in an HA environment. This enables the daemon to reestablish the link to the
OS 2200 QProcessor automatically after a failure or failover of the HA nodes.
Values
FileSystem
A value greater than zero indicates the daemon should automatically attempt to
reconnect to the OS 2200 QProcessor after the API connection terminates
abnormally. The configured value is the number of seconds between retries until the
connection is restored.
A value of zero indicates that the daemon must not automatically reconnect. If the
daemon does not automatically retry, the connection will have to be manually
restarted using the UP keyin. The default value is 0, no automatic reconnects.
FileSystem defines the qualifier for the installed system files. This includes
• MQS$COMMON
• MQS$LIB
• MQS$EXE
• MQS$RUN
• MQS$SAMPLES
• MQSTOOLS
• MQS$OM
In addition, FileSystem must be the qualifier of your mqs$config file.
Values
The default installation requires you to define this as ‘wmq$’ as there is no default
value.
HighOffLoadCount
This is the largest number of OS 2200 user activities that can be serviced using the API
at the present time. This value is configurable at run-time using the ‘OHIGH’ keyin.
Values
The value cannot exceed the value for MaxOffloads. There is no default for this
parameter.
2–28 3843 3744–002

ICLogLevel
LinuxIP
LinuxPort
Adjusting WMQ2200 Configuration Parameters
This value controls the level of trace in the Interconnect library on the OS 2200 and the
level of trace for the interconnect library and offloads in the OS 2200 QProcessor log.
This level can be modified dynamically with the ICLOG keyin.
Values
Valid values are:
0 = IC_LOG_ONLY
4 = IC_AUDIT
5 = IC_DEBUG
6 = IC_VERBOSE
The default value is 0, IC_LOG_ONLY. Refer to the ClearPath Specialty Engine for
OS 2200 Configuration Guide for more information on IC2200 logging.
The IP address of the OS 2200 QProcessor that the daemon must attempt to connect
to.
Values
There is no default value for this parameter, but this must be 172.28.102.10 in most
cases.
The port the Interconnect launcher is bound to on the OS 2200 QProcessor.
Values
There is no default for this value, but this must be 22719 in most cases and typically
does not need to be modified.
LogMQAuthorityErrors
This determines whether or not MQ authority errors must be logged to the queue
manager error log. This value must be set prior to starting the queue manager.
Otherwise changes will not take effect until the queue manager is restarted.
Values
The possible values for this parameter are ON or OFF. By default it is OFF.
3843 3744–002 2–29

Adjusting WMQ2200 Configuration Parameters
LowOffloadCount
The minimum number of offloads to keep running at all times waiting to service OS
2200 activities. This value can be modified at run time with the OLOW keyin.
Values
MaxOffloads
There is no default for this parameter, but it cannot exceed the HighOffLoadCount or
the MaxOffloads.
This defines the maximum number of offloads that can ever be started to service
OS 2200 activities. There is one offload for every OS 2200 activity. This value is not
configurable at run-time.
Values
McbEntryBdi
There is no default for this parameter. The maximum value is 10,000 due to IC
limitations.
This defines the MCB through which the WMQ2200 default trigger monitor is to
schedule (trigger) TIP transactions. Provide the installed MCBBNK CBD VA of form
040nnnn.
Values
The default value is 0. You can only specify an MCB whose UDBASE is equal to or
higher than the default of 0600000.
MonitorInterval
This is the monitor interval (in seconds) for detecting a loss of OS 2200 QProcessor
connectivity.
Values
MQAuthority
The default value is 60 seconds. Valid values range from 0 to 120 seconds. A value of
zero causes the default value of 60 seconds to be used.
This determines whether the OAM is enabled by default. The OAM is a component
provided with WMQ2200 to provide access control to queue manager resources. You
can choose to have the OAM enabled or disabled for each queue manager on an
individual basis. Refer to the IBM WebSphere MQ System Administration Guide
Version 6.0 for more information on using the OAM.
2–30 3843 3744–002

Adjusting WMQ2200 Configuration Parameters
Note: If the OAM is enabled for your queue manager and you intend to run TIP or
HVTIP MQI applications or Open Distributed Transaction Processing TIP or HVTIP
servers whose services use the WebSphere MQ API, you must establish
permissions for the user IDs of these transaction programs. All TIP or HVTIP
programs or servers are known to WMQ2200 as user ‘nobody’ when the default TIP
system user ID is configured (12 ASCII spaces). In this case, MQCONN calls fail with
Reason Code 2035 (MQRC_NOT_AUTHORIZED). Otherwise, TIP or HVTIP programs
or servers are known to WMQ2200 as the OS 2200 user specified in the TIP system
user ID.
When the value of MQAuthority is OFF (or not set), all UNX demand shell sessions
begin with the environment variable MQSNOAUT set. It is the existence of the
MQSNOAUT environment variable when you execute crtmqm command that
determines whether the OAM is in use for a queue manager. If MQSNOAUT exists
when you execute crtmqm, the queue manager runs with the OAM disabled. If
MQSNOAUT does not exist when you execute crtmqm, the queue manager runs with
the OAM enabled.
Note: Do not alter the values of any environment variables except for
MQSNOAUT.
Within your UNX demand processor session, you can create or destroy the
MQSNOAUT environment variable by using the UNX set command. For example, to
create the MQSNOAUT environment variable, enter
set MQSNOAUT=YES
To destroy the MQSNOAUT environment variable, enter
set MQSNOAUT=
To check for the existence and value of MQSNOAUT or any environment variable,
execute the set command with no parameters. If MQSNOAUT is listed, the OAM is
currently disabled for queue manager creation.
Note: Refer to the IBM WebSphere MQ Security manual and the IBM WebSphere
MQ System Administration Guide for more information.
Values
ON specifies that the OAM is enabled. Any other value equates to OFF. The default is
OFF.
3843 3744–002 2–31

Adjusting WMQ2200 Configuration Parameters
MQLocalLanguage
Specifies the language of the message catalog to be used when WMQ2200 issues
informational and error messages. The maximum length of this value is two
characters. Change this value to fit your language preference.
Values
MQLogLevel
The local language designator must be one of the authorized two-character alphabetic
values. Authorized values include en, de, es, fr, it, ja, ko, cn, tw, and pt, which
represent English, German, Spanish, French, Italian, Japanese, Korean, Simplified
Chinese, Traditional Chinese, and Portuguese, respectively. The default value is ‘en’.
This parameter defines the initial WMQ2200 subsystem log/trace level to be used in a
DDP log/trace. This level can be modified dynamically with the MQLOG keyin.
Values
The default value is 0, MQ_LOG_ONLY. Valid values are:
0 = MQ_LOG_ONLY
4 = MQ_AUDIT
5 = MQ_DEBUG
6 = MQ_VERBOSE
PrintConnectionDownWarnings
The value of this parameter determines whether or not a warning is printed to the
OS 2200 console if a user application attempts to use the WebSphere MQ API to
connect to a queue manager on the OS 2200 QProcessor and fails because the
connection is not currently available. The connection might be unavailable due to the
following reasons:
• The WMQ2200 background daemon is not running.
• The daemon is running but the connection to the OS 2200 QProcessor is not
available because it terminated in error or it was disconnected through the
administrative DOWN keyin by an operator.
The console message is triggered when a user application attempts to use the
MQCONN, MQCONNX, or MQRMIOpen API calls, which begin a connection with a
queue manager. The first user application to encounter this situation generates the
console message. Subsequent applications do not generate the console message.
Once connectivity to the OS 2200 QProcessor is re-established, the flag that controls
whether the console message is printed is reset. If connectivity is lost subsequently,
the first application to encounter a lack of connectivity then generates the console
message. In this way, only one console message is generated per loss of connectivity
with the OS 2200 QProcessor.
2–32 3843 3744–002

Values
Setting up Communications
Valid values are ON (the warning is printed) and OFF (the warning is not printed). The
default value is ON.
RealTimeLevel
Determines the real-time processing level for the WMQ2200 daemon.
Values
You can specify any real-time processing level from 2 to 35. The default is zero, which
specifies that processing is not real-time.
TermWaitTime
This specifies the time period to wait for offloads to terminate on OS 2200
QProcessor before causing them to terminate with a signal.
Values
The default value is 60 seconds.
2.5. Setting up Communications
This section describes how to set up communications between your OS 2200
QProcessor and a Sun Solaris, a Windows XP, or another OS 2200 system.
2.5.1. Overview
The following pages provide a brief overview of channels and listener and port setup.
2.5.2. Setting up Communications between OS 2200
QProcessor and Other Systems
A message channel provides a communication path between two queue managers on
the same, or different, platforms. The message channel is used for the transmission of
messages from one queue manager to another, and shields the application programs
from the complexities of the underlying networking protocols.
A message channel can transmit messages in one direction only. If two-way
communication is required between two queue managers, two message channels are
required.
3843 3744–002 2–33

Setting up Communications
Figure 2-1 is from the WebSphere MQ Intercommunication manual; refer to this manual
for more information on channels and how to use them.
Figure 2–1. Communication Path Between Queue Managers
Listener and Port Setup
For applications to be able to exchange messages, you must start a listener program
for inbound connections. Before you can use channels, you need to do listener and
port setup.
Use the RUNMQLSR command to start the WebSphere MQ listener process. Any
inbound requests for channel attachment start Message Channel Agents (MCA) as
children of this listener process.
RUNMQLSR [-m queue_manager_name] [-p port] [&]
Note: You must open the port in the OS 2200 QProcessor firewall to allow
incoming channels to connect. By default, no ports are open on the public LAN. If
you need to open other ports, use the OS 2200 QProcessor Administration Console.
2–34 3843 3744–002

Setting up Communications
If you do not specify queue_manager_name and port, default values are used (default
for port is 1414). The optional trailing ampersand allows the listener program to
execute as a background run, thus not tying up the demand session. The optional
trailing ampersand can also be used on a RUNMQCHL control command.
Alternatively, you can use the RUNMQSC START LISTENER command if your queue
manager is running. It accepts no parameters, and the TCP/IP port value is derived
from the queue manager’s qm.ini file, or defaults to 1414.
To stop all WebSphere MQ listeners running on a queue manager that is inactive, type
ENDMQLSR [-m queue_manager_name]
Connecting Two Queue Managers Using Channels
After starting a listener for a queue manager, you need to define one or more receiver
(RCVR) channels that accept incoming connections. The WebSphere MQ listener
accepts incoming channel requests and starts receiver (RCVR) channels to service the
incoming requests. These child processes are called responders. To connect two
queue managers each queue manager must have a channel with the same name.
Channels are unidirectional; the sending end transmits messages to the receiving end.
A sender (SDR) channel must be created with the same name on the sending queue
manager to partner with the RCVR channel on the receiving end. You can define
channels using the RUNMQSC utility.
A basic receiver (RCVR) channel definition is similar to the following:
DEFINE CHANNEL (TO.RCVR) CHLTYPE(RCVR) TRPTYPE(TCP)
A basic sender (SDR) channel definition is similar to the following:
DEFINE CHANNEL(TO.RCVR) CHLTYPE(SDR) CONNAME('10.10.10.10(1414)') +
XMITQ(MY.TRANSMIT.Q)
The format of the CONNAME parameter is IP-Address(Port). If you omit the port, 1414
is assumed. The listener on the receiving end must be listening on the given IP
address and port specified.
Sender channels service transmission queues, taking messages off of the queue and
sending them over the network to the receiving queue manager. You specify the
transmission queue the sender channel services in the SDR channel definition with the
XMITQ specification. The transmission queue must be created in RUNMQSC:
DEFINE QL(MY.TRANSMIT.Q) USAGE(XMITQ)
Refer to the WebSphere MQ Script (MQSC) Command Reference manual for full
documentation on how to define various types of channels.
3843 3744–002 2–35

Setting up Communications
Once the channel has been defined on the sending and receiving queue manager and
the listener is running on the receiving end, you can start the channel using
RUNMQSC:
START CHANNEL(TO.RCVR)
Alternatively, you can start the channel from the UNX shell:
>@WMQ$*MQS$EXE.UNX
>runmqchl -m MY.QMGR -c TO.RCVR &
The following is a simple example of how to use a channel to send messages from
one queue manager to a second queue manager. The sending queue manager is
named SEND and the receiving queue manager is named RECEIVE.
Sending system
Receiving system
>crtmqm SEND # Create queue manager
>strmqm SEND # Start queue manager
>runmqsc SEND # Start MQSC utility to define objects
>* Define a transmission queue for the sending channel
>DEFINE QL(MY.TRANSMIT.Q) USAGE(XMITQ)
>* Define sending channel
>DEFINE CHANNEL(TO.RECEIVE) CHLTYPE(SDR) +
>CONNAME('10.10.10.10(1414)') XMITQ(MY.TRANSMIT.Q)
>* Define the queue remote that applications will use to send
>* messages to the remote system. The queue remote puts
>* messages to the transmission queue and the channel
>* takes them and delivers them to the remote system.
>DEFINE QREMOTE(TO.RECEIVE.Q) RNAME(RECEIVEQ) +
>RQMNAME(RECEIVE) XMITQ(MY.TRANSMIT.Q)
>END
>crtmqm RECEIVE # Create queue manager
>strmqm RECEIVE # Start queue manager
>runmqlsr -m RECEIVE -t TCP -p 1414 & # Start listener
>runmqsc RECEIVE # Start MQSC utility to define objects
>* Define destination queue that sending end sends messages to
>DEFINE QL(RECEIVEQ)
>* Define receiver channel
>DEFINE CHANNEL(TO.RECEIVE) CHLTYPE(RCVR)
>END
Next, start the channel from the sending end and verify it is running:
>runmqsc SEND
>START CHANNEL(TO.RECEIVE)
>DISPLAY CHSTATUS(TO.RECEIVE)
>END
2–36 3843 3744–002

The channel must be listed as RUNNING.
Setting up Communications
At this point, on the sending end you can put a message to the TO.RECEIVE.Q. The
message must be delivered and retrievable from the receiving queue manager on its
destination queue, RECEIVEQ.
2.5.3. Securing Your Channels with SSL
Introduction
WMQ2200 uses OpenSSL to provide SSL (Secure Sockets Layer) capability. This
version of OpenSSL provides a Federal Information Processing Standards (FIPS) 140-2
compliant SSL implementation.
You can create SSL certificates for WMQ2200 queue managers using OpenSSL
utilities. You can find information about OpenSSL at
http://www.openssl.org
You can also refer to the IBM WebSphere MQ Security manual for more information
related to SSL in Websphere MQ.
Note: Since WMQ2200 uses OpenSSL instead of IBM GSKit for SSL, various
documentation in the IBM manual including (but not limited to) procedures using
GSKit utilities to create and maintain certificates for queue managers do not apply.
The following topics describe procedures for creating certificates, exchanging them
with a partner (either another WMQ2200 or IBM retail implementation using GSKit),
supported SSL Cipher Suites, and FIPS 140-2 considerations.
In the following topics, the terms server and client are used. In the context of SSL for
Websphere MQ, the server is the queue manager with the SSL enabled receiver
(RCVR) channel and the client is the queue manager with the SSL enabled sender
(SDR) channel that is connecting to the receiving queue manager.
Federal Information Processing Standards (FIPS)
A WMQ2200 channel configured to use SSL can be run in a FIPS compliant mode
because the OpenSSL library it uses has been validated as conforming to the Federal
Information Processing Standards (FIPS) 140-2, Security Requirements for
Cryptographic Modules. The Cryptographic Module Validation Program (CMVP) is a
joint program of the US National Institute of Standards and Technology and the
Communications Security Establishment Canada (CSEC). A channel can be run in FIPS
mode if the queue manager has enabled FIPS and the cipher used by the channel is
FIPS compliant.
3843 3744–002 2–37

Setting up Communications
Valid Cipher Suites for WMQ2200
The following lists the supported SSL cipher suites in WMQ2200. This list indicates
which ciphers are FIPS compliant.
Name FIPS Compliant?
DES_SHA_EXPORT No
NULL_MD5 No
NULL_SHA No
RC4_MD5_US No
RC4_SHA_US No
TLS_RSA_WITH_DES_CBC_SHA No
TRIPLE_DES_SHA_US No
TLS_RSA_WITH_3DES_EDE_CBC_SHA Yes
TLS_RSA_WITH_AES_128_CBC_SHA Yes
TLS_RSA_WITH_AES_256_CBC_SHA Yes
Setting up Queue Manager Objects
Refer to the IBM WebSphere MQ Security manual for more information on setting up
the server/client objects.
The following is an example of setting up the server and client objects on two queue
managers. The example demonstrates how a channel can be configured to allow SSL
encrypted messages to be sent from one queue manager to another. This is a basic
example.
Server setup
The following creates and starts a server (receiving) queue manager. It also creates a
local queue, an SSL enabled receiver channel configured to require client
authentication, and a listener to accept incoming connections.
Example
@WMQ$*MQS$EXE.UNX
crtmqm SERVER
strmqm SERVER
runmqsc SERVER
define ql(INPUTQ)
define channel(SSLCHAN) chltype(RCVR) SSLCAUTH(REQUIRED) +
SSLCIPH(TRIPLE_DES_SHA_US)
END
runmqlsr -p port# -t tcp -m SERVER &
exit
2–38 3843 3744–002

Client setup
Setting up Communications
The following creates and starts a client (sending) queue manager. It also creates a
transmission queue, a remote queue, and an SSL enabled sender channel.
Example
@WMQ$*MQS$EXE.UNX
crtmqm CLIENT
strmqm CLIENT
runmqsc CLIENT
define ql(TRQ) usage(XMITQ)
define qremote(TO.INPUTQ) RNAME(INPUTQ) RQMNAME(SERVER) XMITQ(TRQ)
DEFINE CHANNEL(SSLCHAN) CHLTYPE(SDR) XMITQ(TRQ) +
CONNAME('(port#)') TRPTYPE(TCP) +
SSLCIPH(TRIPLE_DES_SHA_US) DESCR('SSL Sender channel')
END
exit
Special GSKit Considerations When Using FIPS
If you intend to use WMQ2200 as the server (receiving) end of a SSL enabled channel
with a GSKit client (a retail IBM installation) and FIPS is enabled on the queue
managers, you must perform an extra step to ensure the FIPS enabled channel starts.
The FIPS standard requires that certificates are created with a strong signature
encryption. Some levels of WebSphere MQ that use GSKit may not create certificates
with a compliant signing algorithm. Certificates created with GSKit must be created
with the SHA signing algorithm, not the MD5 algorithm. If the certificate is created
with the MD5 algorithm, it will be rejected by the WMQ2200 server during the SSL
handshake if FIPS is enabled.
To fix this, you must edit this file on your system running the retail IBM WebSphere
MQ product:
/usr/local/ibm/gsk7/classes/ikminit.properties
The line in the file that starts with #DEFAULT_SIGNATURE_ALGORITHM= must be
enabled (by removing the #) and must specify the SHA1 algorithm, rather than MD5, as
shown below:
DEFAULT_SIGNATURE_ALGORITHM=SHA1_WITH_RSA
You can use gsk7cmd to create the client certificate (or the certificate request to be
used to obtain a certificate from a trusted authority). If the above scenario is not
followed, the certificate is not valid in FIPS mode in OpenSSL. When OpenSSL
receives the certificate it will reject it and the channel will not run.
You can verify that the certificate you created was created with the correct signature
algorithm, like this:
$ gsk7cmd -cert -details -db key.kdb -pw cms -label
ibmwebspheremq
3843 3744–002 2–39

Setting up Communications
The signature algorithm must be this:
Signature Algorithm: 1.2.840.113549.1.1.5
This number equates to:
1.2.840.113549.1.1.5 - SHA-1 with RSA Encryption
Create Certificates using OpenSSL
Certificates are created for WMQ2200 using OpenSSL. The following combinations
can be used:
• Option A – Partner is another WMQ2200 installation using OpenSSL.
• Option B – Partner is a retail IBM WebSphere MQ installation using GSKit.
OpenSSL utilities such as certificate creation are supported in the UNX shell. The
OpenSSL command line utility accepts password arguments through either -passin
and -passout for input and output passwords respectively.
These options take a single argument whose format is described below. If no
password argument is given and a password is required, the user is not prompted to
enter one. So it is very important to use -passin or -passout with one of these options.
• Pass: – is the actual password for the certificate.
• Stdin – Reads the password from standard input.
The following example creates a certificate request and uses the -passout pass
option.
Example
>openssl req -new -x509 -passout pass: -keyout private/cakey.pem -out
cacert.pem
The is the password you are assigning to the certificate request.
Example
This example uses the -passout stdin option.
>openssl req -new -x509 -passout stdin -keyout private/cakey.pem -out cacert.pem
>
The is the password you are assigning to the certificate.
OpenSSL provides a Perl script named CA.pl to simplify the process of certificate
generation. The CA.pl script can be called in UNX shell.
You can directly use the OpenSSL command line utility, which the CA.pl script calls to
do its work.
2–40 3843 3744–002

Setting up Communications
To combine multiple certificates into one, you can use the combine command in UNX
shell.
Example
@wmq$*mqs$exe.unx
>combine client.pem server.pem key.pem
exit
This example concatenates the client.pem and the server.pem certificates and saves
the output into key.pem.
Generate Certificate Request and Sign Certificate
When you create your certificate request, you are prompted for a passphrase to
assign to the certificate. You must specify webspheremq for the passphrase.
WMQ2200 cannot use your certificate if the passphrase for the private key is not
webspheremq. After creating the certificate request, you must have it signed by a
trusted authority or you must self-sign your certificate.
Convert Certificate into DER Format
This step is only necessary when the server (receiving end) is GSKit, and WMQ2200 is
the client (sending end). You must convert the OpenSSL certificate to a format GSKit
can understand before you copy the certificate to the system using GSKit. Once the
DER format file is created, you must copy the certificate to the GSKit server system
and import it into the key repository for the queue manager. Refer to the IBM
WebSphere MQ Security manual for more information.
Example
$ openssl x509 -outform der -in cacert.pem -out client.der
Exchanging Certificates with the Partner
Option A – Partner is Another WMQ2200 Installation Using OpenSSL
After you have created and signed your certificate on each WMQ2200 system, you
must exchange certificates.
The root certificate file must be named cacert.pem. The root certificate verifies that
the certificates are signed by the root private key. WMQ2200 expects a file named
cacert.pem to be in the /var/mqm/qmgrs//ssl directory. You must copy the
root certificate for one queue manager to the other queue manager’s
/var/mqm/

Setting up Communications
For an SSL channel to start between two WMQ2200 queue managers, each queue
manager must have a cacert.pem file that has the root certificate for the other queue
manager’s and key.pem file that contains concatenation of both the server and client
certificates.
Option B – Partner is a Retail IBM WebSphere MQ Installation Using GSKit
There are special considerations when exchanging certificates between the client and
server when one system is a retail IBM WebSphere MQ installation using GSKit.
OpenSSL and GSKit certificates use different file formats. The only format both
understand are PKCS12 (.p12) and DER (.der) formats. It is important to convert
OpenSSL certificates to either .der or .p12 and GSKit certificates to .p12 format.
If you intend to use FIPS, see the special considerations in the subsection above
entitled “Special GSKit Considerations When Using FIPS.”
You must export the certificate for the queue manager on the system using GSKit for
use by WMQ2200. You must export this file using the PKCS12 format, which OpenSSL
can understand.
Export Certificate in PKCS12 Format from the GSKit Key Repository
Use the following commands to export a certificate using iKeycmd:
On UNIX
gsk7cmd -cert -export -db filename -pw password -label label -type
cms -target filename -target_pw password -target_type pkcs12
On Windows
runmqckm -cert -export -db filename -pw password -label label -type
cms -target filename -target_pw password -target_type pkcs12
Where:
-db filename is the fully qualified path name of the CMS key database.
-pw password is the password for the CMS key database.
-label label is the label attached to the certificate.
-type cms is the type of the database.
-target filename is the name of the destination file.
-target_pw password is the password for encrypting the certificate.
-target_type pkcs12 is the type of the certificate.
2–42 3843 3744–002

Example
Setting up Communications
gsk7cmd -cert -export -db key.kdb -pw cms -label ibmwebspheremqqmc -
type cms -target client.p12 -target_pw webspheremq -target_type
pkcs12
Next, copy the pkcs12 file created from the system using GSKit to the OS 2200
QProcessor using OpenSSL. After copying the file to the OS 2200 QProcessor, the
file must be converted into the .pem file format.
Use the openssl utility to convert the pkcs12 file to the PEM format:
>openssl pkcs12 -in infile.p12 –out outfile.pem
When prompted for a passphrase, specify ‘webspheremq’.
The contents of the PEM file you create with the openssl utility must be appended
to the key.pem file in the /var/mqm/qmgrs//ssl directory.
Import DER Format File from OpenSSL into the GSKit Repository
You must import the certificate from the OS 2200 QProcessor queue manager
(OpenSSL) into the GSKit key repository. Use the following commands to add the
certificate using iKeycmd:
On UNIX:
gsk7cmd -cert -add -db filename -pw password -label label -file
filename -format binary
On Windows:
runmqckm -cert -add -db filename -pw password -label label -file
filename -format binary
Where:
-db filename is the fully qualified path name of the CMS key database.
-pw password is the password for the CMS key database.
-label label is the label attached to the certificate.
-file filename is the name of the file containing the certificate.
-format binary is the format of the certificate. The value can be ASCII for
Base64-encoded ASCII or binary for Binary DER data. The default is ASCII.
3843 3744–002 2–43

Advanced Configuration
Example
gsk7cmd -cert -add -db key.kdb -pw cms -label ibmwebspheremqqms -file
server.der -format binary
The SSL channel should start successfully once you have
• Imported the OpenSSL certificate from the OS 2200 QProcessor system into the
GSKit repository on the system using GSKit
• Copied the GSKit certificate to the OS 2200 QProcessor and deployed it into the
key.pem and cacerts.pem files
2.6. Advanced Configuration
This subsection discusses two optional configuration tasks:
• Creating and using exits.
• Configuring MQS2200 as a static resource manager under Open Distributed
Transaction Processing.
2.6.1. Creating and Using Exits
If your site requires special handling procedures during channel processing, such as
enhanced security processing, you can include user-provided code, referred to as exit
code. To use this functionality, you must create and deploy exit code to the OS 2200
QProcessor.
Creating Exit Code
Write your exit code in C (COBOL is not currently supported). If the exit is a data
conversion exit, the function your code resides in must be named MQStart. If the exit
is any other type of exit, you can use any function name you want for your exit code,
but you must add the following line to your code to create an empty MQStart
function:
void MQStart() {;} /* dummy entry point */
The MQStart entry point is required for the exit to be recognized by WebSphere MQ.
Deploying Exit Code
Once you have written your exit code, it must be deployed to the OS 2200
QProcessor. The UNX shell processor provides a tool to deploy exit code to the
OS 2200 QProcessor. This tool is called buildexit.
Use the buildexit tool to deploy your C source file containing your exit code to the
OS 2200 QProcessor:
@WMQ$*MQS$EXE.UNX
>buildexit -o
2–44 3843 3744–002

Advanced Configuration
For example, to deploy an exit written in C located in OS 2200 file
JOHN*EXIT.SECURITY/C to the OS 2200 QProcessor into an object named secexit can
use the following command:
>buildexit -o secexit JOHN*EXIT.SECURITY/C
The output looks similar to the following:
buildexit: Transferred 2231 bytes to file /tmp/secexit.c
Buildexit complete. secexit installed into /var/mqm/exits64
Note: If you are deploying a data conversion exit, the object name you use MUST
be _r where is the user-defined format you are using in
your MQMD.Format field. The format name must be all uppercase and no more than
eight characters. You must also add the _r suffix to your object name. For example,
if you want to create a data conversion exit to convert an MQMD.Format you define
named OURFMT you would deploy an exit with an object name of OURFMT_r.
If the source file has errors, you will see the errors in the output. If errors are noted,
correct the code and try to deploy again.
Once the exit is deployed, verify it is valid. First, verify the object module has been
deployed to /var/mqm/exits64:
>cd /var/mqm/exits64
>ls -l
Verify that the file with the name of your target object name exists.
Next, use the nm command to verify that the object module is valid and contains an
MQStart entry point and an entry point with your main exit code (if not a data
conversion exit). In the following example, the main entry point is TESTchan and is a
channel security exit:
>cd /var/mqm/exits64
>nm -g scyexit
The output looks similar to the following:
000000000000079c T MQStart
00000000000007a2 T TESTchan
At this point you have deployed your exit. WebSphere MQ can now use your exit.
Refer to IBM documentation for examples of how to configure your exit code in
WebSphere MQ.
When configuring exits other than data conversion exits in WebSphere MQ, you must
refer to the exit as follows:
/var/mqm/exits64/(EntryPoint)
3843 3744–002 2–45

Advanced Configuration
Replace with the object name you created with buildexit and replace
EntryPoint with the function with your exit code in the object. Do not use the MQStart
dummy entry point. For example, if your exit object module is scyexit and the entry
point for your exit code is SecFunction you can specify the following:
/var/mqm/exits64/scyexit(SecFunction)
The object module and entry point function name are case sensitive.
Note: WebSphere MQ does not use the exit and generates an error to the error log
files if the object module created by buildexit does not contain an MQStart entry
point. WebSphere MQ needs this entry point to verify the exit code is valid (or is
used for data conversion in the case of data conversion exits).
The following is an example of a channel security exit:
#include
#include
#include
#include
void MQStart() {;} /* dummy entry point MQ requires */
void MQENTRY SecurityGate(PMQCXP pExitParms
,PMQCD pChannelDef
,PMQLONG pDataLength
,PMQLONG pAgentBufferLength
,PMQCHAR pAgentBuffer
,PMQLONG pExitBufferLength
,PMQCHAR *pExitBuffer )
{
if(pExitParms->ExitReason == MQXR_INIT)
{
/* This is the first entry into the exit, at channel initialization
*/
}
else if(pExitParms->ExitReason == MQXR_INIT_SEC)
{
/* This is where we do security checks */
/* Reject caller, stop channel, security checks failed */
pExitParms->ExitResponse = MQXCC_CLOSE_CHANNEL;
}
else if(pExitParms->ExitReason == MQXR_TERM)
{
/* This is at channel termination, cleanup resources */
}
return;
}
2–46 3843 3744–002

Advanced Configuration
To use this security exit, you must deploy the code to the OS 2200 QProcessor using
buildexit and then configure your channel to use the security exit. For example, if the
object module you created was named secexit, you must define a channel to use the
security exit as follows:
>@wmq$*mqs$exe.unx
>runmqsc QMGR
>DEFINE CHANNEL(TO.LOCAL) CHLTYPE(RCVR) +
>SCYEXIT('/var/mqm/exits64/secexit(SecurityGate)')
>END
2.6.2. Configuring WMQ2200 as a Static Resource Manager
under Open Distributed Transaction Processing
If you want to take advantage of the features of online transaction processing (OLTP)
such as Two-Phase Commit for committing or rolling back global transactions that
process WMQ2200 messages, configure WMQ2200 as a static resource manager
under Open Distributed Transaction Processing (Open DTP).
Multiple WMQ2200 installations can be configured as static resource managers under
one Open Distributed Transaction Processing or under separate Open Distributed
Transaction Processing installations. Refer to "2.8 Multiple WMQ2200 Installations as
Static Resource Managers under Open DTP" for more information on configuring
multiple WMQ2200s.
Perform the following steps to configure WMQ2200 as a static resource manager
(RM) under Open Distributed Transaction Processing.
Note: File installation qualifier wmq$ is assumed.
1. Update element wmq$*mqstools.mqswitch/comp-example to contain the qualifier
of your default Open Distributed Transaction Processing installation. In the
following steps, file installation qualifier otm$ is assumed.
2. Add the runstream you edited in step 1 to compile the resource manager XA
switch structure found in element wmq$*mqs$samples.mqswitch/c. This places
the compiled object module MQSWITCH/O in the file wmq$*mqs$samples.
3. Add the new resource manager to the TMSCONFIG *groups section, using name
MQSeries_XA_RMI for the resource manager identifier, RMID. The following
TMSCONFIG statements adds the default queue manager (a queue manager
created with the –q option) as a resource manager:
*groups
mqdefault ;
RMID="MQSeries_XA_RMI"
If you want to run transactions to a non-default queue manager (a queue manager
created without the –q option), you must also include the openinfo statement in
your group entry, to contain the non-default queue manager name. This instructs
Open Distributed Transaction Processing as to which queue manager to involve in
the global transaction:
3843 3744–002 2–47

Advanced Configuration
*groups
mqnondef1 ;
RMID="MQSeries_XA_RMI" ;
openinfo = "QMGR2"
4. Add the new group to any server or client in TMSCONFIG that uses this resource
manager. Following is an example of a client TMSCONFIG configuration entry:
*clients
MQCLIENT ;
group = mqdefault
5. Load or append this TMSCONFIG.
6. Add otm$*tm$util.rminstall to make Open Distributed Transaction Processing
aware of the RM. Provide the following answers:
Enter file name of the RM xa_switch OM >WMQ$*MQS$SAMPLES.
Enter elt/vers name of RM xa_switch OM >MQSWITCH/O
Enter switch name for the RM >MQRMIXASwitch
Enter file containing RM XA gate bank object module >WMQ$*MQS$LIB.
Enter elt/vers name of RM XA gate bank object module >MQS$ENTRY
Enter file name of the xa/h header >
Enter file name of the TM gate bank >
Automatically @ADD RMLOADER {Y|} >
End RMINSTALL. RMLOADER resides in RMINS$TEMP.
7. Add the generated runstream found in *rmins$temp.rmloader. At the end of the
load, verify you see a successful load message.
8. Bring up the Open Distributed Transaction Processing TMSC processor.
External Transaction Manager (TM) Notes
WebSphere MQ XA/Open XA interface rules that are important to remember
regarding the use of Open Distributed Transaction Processing with WMQ2200 include:
• The tx_open call in your user application causes Open Distributed Transaction
Processing to issue a xa_open call to the RM. The xa_info structure passed on any
xa_open call by the TM includes the name of a non-default queue manager; if
blank, it uses the default queue manager. This name takes the same form as the
name of the queue manager on an MQCONN or MQCONNX call.
• Only one queue manager at a time can participate in a transaction coordinated by
an external TM.
• Applications calling an external TM can connect only to the queue manager
participating in the transaction.
• The queue manager that is participating in a transaction must be started and
running before the transaction starts.
2–48 3843 3744–002

TMSC Recovery Server Notes
Generating Alternate WMQ2200 Installations Using COMUS
If the TM invokes the Open Distributed Transaction Processing recovery server to
resolve a global transaction that involves WMQ2200 messaging in one of the
transaction branches, the UNX shell ps command displays a process assigned to
program TMSC. The recovery server is a child activity of program TMSC.
The following example shows the recovery server process as program TMSC with
runid OTMA:
UID USERID PPID PID ST TIME COMMAND
1001 mqm 4219 4220 Sl 57:39 TMSC (OTMA)
The existence of the TMSC recovery server process is expected when a recovery
situation occurs, and is standard operating procedure. The Open Distributed
Transaction Processing recovery server calls WMQ2200 as the resource manager to
resolve its branch in the global transaction. The recovery server remains active as long
as the TMSC background run is up, and remains in the ps display until the TMSC
background job is terminated.
If you want to end the queue manager after a recovery has taken place (a process for
TMSC exists in the UNX shell ps display), the proper procedure is to first terminate the
Open Distributed Transaction Processing TMSC background run to allow the recovery
server to disassociate. Then end the queue manager.
2.7. Generating Alternate WMQ2200 Installations
Using COMUS
WebSphere MQ allows you to generate multiple alternate WMQ2200 installations at
your site. Each alternate installation requires a unique file qualifier for its product file
set, as well as unique BDIs. The product remains an absolute-only product; therefore,
no PRIMUS changes or local code can be applied through this build capability. You can
then install both test and production versions of WMQ2200 on the same
OS 2200 host.
A WMQ2200 installation has a one to one relationship between the installed product
and an OS 2200 QProcessor. This relationship is configured in the IC$*Processors file
and managed by the IC2200 ICADMIN utility. (Refer to the ClearPath Specialty Engine
for OS 2200 Configuration Guide for more details on ICADMIN). The WMQ2200
product can have only one mode of the product installed on each OS 2200
QProcessor. WMQ2200 needs the ability to select which OS 2200 QProcessor to
remotely install on for each WMQ2200 installation mode.
To generate a new installation tape from the release master using COMUS, complete
the following:
• Establish a COMUS database using the COMUS COINIT processor.
• Register the tape in the database using the COMUS REGISTER command.
3843 3744–002 2–49

Generating Alternate WMQ2200 Installations Using COMUS
• Generate the build runstream using the BUILD command.
During the generation of the build runstream, the following information is solicited
from the user:
• WMQ2200 file set qualifier
• MQS subsystem gate bank BDI
• UNX subsystem gate bank BDI
• Whether or not the BIS interface is used
• OLTP-TM2200 library file
• Installed MCB filename
Note: Soliciting for the OLTP-TM2200 library files allows for the use of different
libraries by the different WMQ2200 installations.
Basically, the build capability is a relinking of object modules to generate and obtain
new entry point addresses created by a different set of BDIs supplied to the build
routine.
Two files exist on the WMQ2200 release tape to facilitate the COMUS build:
WMQ$OM and WMQ$BLDPRT. File WMQ$OM contains the compiled or assembled
object modules for the WMQ2200 subsystems, and for the WMQ2200 utilities and
executables. File WMQ$BLDPRT contains the COMUS build results after the build is
completed.
The COMUS build capability offers selection of an OLTP-TM2200 library. The alternate
WMQ2200 installation can be registered as a resource manager under an
OLTP-TM2200 installation already acting as the transaction manager for the default
WMQ2200 installation, or an alternate OLTP-TM2200 installation. Instructions for
registering multiple WMQ2200 installations as a resource manager under the same, or
alternate, OLTP-TM2200 can be found in Section 2.8, “Multiple WMQ2200 Installations
as Static Resource Managers under Open DTP.”
The WMQ2200 COMUS build creates a new product tape that is SOLAR installable.
Note: This new product tape cannot be used as input to the build process to
generate another installable version of the product.
Requirements for a Successful Build
The build process requires the following products:
• ED. The COMUS PBR calls @ED to edit in site-unique values.
• PADS. The WMQ2200 build stream includes SYS$LIB$*PADS.PADS$DIAGDMP in
the link of MQS$SUBS.
• URTS. The WMQ2200 build stream includes elements from file
SYS$LIB$*EMSRVC.
2–50 3843 3744–002

Information Needed Prior to the Build
Build Steps
Generating Alternate WMQ2200 Installations Using COMUS
Output from the COMUS build command is a product generation runstream. This
runstream is stored in the COMUS database file WMQ2200*COMRUN.
When issuing a COMUS build command to create an alternate WMQ2200 product
tape, the following values are needed for input:
• The qualifier for the alternate installation product file set. This qualifier is indicated
on the destination file names in the alternate file sets CO$UTIL.SOLAR$SGS
element. The default qualifier is "WMQ$." The new qualifier must be added to the
Product Qualifier\Mode field of the associated OS 2200 QProcessor host in the
IC$*PROCESSOSRS file by using the ICADMIN utility.
Note: The source files created from this build, and written to the alternate
installation tape, acquires the project-id of this build's execution as their file
qualifier.
• The new BatchRunId value (1-4 alphanumeric chars) to differentiate this alternate
installation's batch runs from any other WMQ2200 installation's batch runs. The
default BatchRunId value is "WMQA."
• The new MQS subsystem gate bank BDI. There is no default value.
• The new UNX subsystem gate bank BDI. There is no default value.
• The BM$MQS subsystem gate bank BDI (if the Business Information Server basic
mode interface is to be used). There is no default value.
• The fully qualified name of the OLTP-TM2200 library file "TM$LIB" (enables server
program triggering). The default OLTP-TM2200 library file name is "OTM$*TM$LIB."
• The fully qualified name of the MCB installation (library) file "MCB$" (enables TIP
program triggering). The default MCB installation (library) file name is
"MCB3*MCB$."
This procedure assumes a COMUS database has been established on the system
(through the COMUS CO$INIT processor). To create the alternate installation, perform
the following steps:
1. Set the COMUS database qualifier.
2. Call COMUS.
3. Register the release master.
4. Create the product generation runstream through the COMUS build command.
5. View the runstream in the COMRUN file to verify that it contains the correct
information for this build.
6. When you are satisfied, @START the product generation runstream.
7. When the execution completes, COMUS sends the COMUS print file to the default
printer.
3843 3744–002 2–51

Generating Alternate WMQ2200 Installations Using COMUS
8. The WMQ2200 part of the product generation runstream contains a breakpoint at
file *MQS$BLDPRT. This file is written to your alternate installation tape
as file #13 and is then deleted by COMUS. In order to view this file, you must
obtain it from the alternate installation tape.
9. If the product generation completes successfully, the alternate installation tape is
available to be registered and installed through SOLAR.
Example of a Generation and Installation
In this example, the following sample values are used:
COMUS database qualifier : SYLVESTER
Product name : WMQ2200
Tape Assign Mnemonic : HICM (for 36-track tapes)
WMQ2200 release master : 295H (Assigned as 'MASTER')
File set qualifier : WMQ$Z
Alternate BatchRunId : WMQZ
Alternate MQAdminKeyId : WMQZ
Alternate MQS BDI : 206051
Alternate UNX BDI : 206052
Alternate BM$MQS BDI : 206053
Alternate project ID : WMQ$Z$6R1
Alternate installation tape : 300H (Assigned as 'NEWMASTER')
1. Set the COMUS database qualifier:
@QUAL SYLVESTER
2. Call COMUS to register the WMQ2200 product release master (if the WMQ2200
product release master spans multiple tapes, separate the tape numbers with
slashes).
For example:
@SYS$LIB$*COMUS.COMUS WMQ2200
COMUS 6R8D (060216 1257:26) 2006 Apr 26 Wed 0929:34
Copyright (c) 1995-2010 Unisys Corporation.
All rights reserved.
UNISYS CONFIDENTIAL
Database Qualifier: SYLVESTER
COMMAND ? >default
DIRECTIVE ? >p regttype
DEFAULT: REGTTYPE VALUE: HICL
DIRECTIVE ? >u regttype hicm
DIRECTIVE ? >p regttype
DEFAULT: REGTTYPE VALUE: HICM
DIRECTIVE ? >p ttype
DEFAULT: TTYPE VALUE: HICL
2–52 3843 3744–002

Generating Alternate WMQ2200 Installations Using COMUS
DIRECTIVE ? >u ttype hicm
DIRECTIVE ? >p ttype
DEFAULT: TTYPE VALUE: HICM
DIRECTIVE ? >e
DEFAULT TABLE UPDATED - DATE: 060426 TIME: 0929
DEFAULTS INSERTED/DELETED/UPDATED - 0 / 0 / 2
DEFAULTS AT START/END OF SESSION - 31 / 31
DEFAULTS TASK COMPLETED *************************
COMMAND ? >register,sl reel=295H
PRODUCTS CONTAINED ON REEL# 295H
PRODUCT LEVEL TYPE BUILD-STATUS
WMQ2200 6R1 MASTER BUILD
REGISTER PRODUCT 'WMQ2200 6R1' - /N/E(END) ? >Y
************ PRODUCT INFO FOR 'WMQ2200
6R1'***************************
(C) Copyright 2010, Unisys Corporation
All rights reserved (Unpublished work)
UNISYS PROPRIETARY
This program(s) including the information
contained herein, is confidential and proprietary
to Unisys Corporation, and shall not be used or
reproduced for any purpose, except with written
consent/license of Unisys Corporation.
******************** END INFO
*****************************************
PRESS TRANSMIT TO CONTINUE OR T(TOP) > (transmit)
NO KEYWORDS FOR 'WMQ2200 6R1'.
@BRKPT PRINT$/042606093001 .
@SYM 042606093001.,,[pr] . srl sel num
#1 NUM SELECT LIST: 1
LIST DIRECTIVE ?>cview,r
ACTIVE LIST: 1
ENTER FIELD NAMES FOR REPORT>product level dsu
ENTER FIELD NAMES FOR REPORT>build-flag install-flag config-flag
ENTER FIELD NAMES FOR REPORT>(transmit)
PRODUCT : WMQ2200 LEVEL : 6R1 DSU :
BUILD-FLAG : BUILDABLE INST-FLAG : NON-INSTALL CONFIG-FLAG :
NON-CONFIG
***************************************************************
END OF REPORT
VIEW DIRECTIVE ?>
3843 3744–002 2–53

Generating Alternate WMQ2200 Installations Using COMUS
3. Use the build command to create a product generation runstream:
VIEW DIRECTIVE ?>build,q WMQ2200,6R1
LIST TASK COMPLETED *************************
For each default question, you can enter one of the following responses:
• An appropriate value.
• A null string or spaces to maintain the current default value.
• QUERY causes COMUS to ask for the default on every BUILD of the product.
• BLANK sets the value of the default to null.
4. At this point, you can change one or more of the WMQ2200 product default
values. For each default question, you can enter one of the following responses:
• An appropriate value.
• A null string or spaces to maintain the current default value.
• QUERY causes COMUS to ask for the default on every BUILD of the product.
• BLANK sets the value of the default to null.
Default generation recovery mode (ON or ) ? >(transmit)
Default project id () ? >WMQ$Z$6R1
Default run id () ? >WMQZ
Default run options () ? >(transmit)
Default run priority () ? >(transmit)
Default tape equipment type () ? >(transmit)
Default tape assign options () ? >(transmit)
Default generation type (DISK/DISK or ) ? >(transmit)
Permanent SGSs () ? >(transmit)
COMUS copies the registered WMQ2200 6R1 release master’s CO$UTIL file into
[project-id]*CO$UTIL.COMUS, then references the release master's DEFMAKE
routine in [project-id]*CO$UTIL in order to query specific values associated with this
alternate installation:
*** Define Alternate WMQ2200 Installation Values ***
Enter the new WMQ2200 file set qualifier () >WMQ$Z
Is qualifier, WMQ$Z, correct ( or N) ? >(transmit)
Enter the new BatchRunId () >WMQZ
Is BatchRunId, MQSZ, correct ( or N) ? >(transmit)
Enter the MQS subsystem gate bank BDI, form 20nnnn >206051
Is the MQS gate bank BDI, 206051, correct ( or N) ? >(transmit)
Enter the UNX subsystem gate bank BDI, form 20nnnn >206052
Is the UNX gate bank BDI, 206052, correct ( or N) ? >(transmit)
Is the basic mode interface to be installed (Y or ) ? >Y
Enter the BM$MQS subsystem gate bank BDI, form 20nnnn >206053
Is the BM$MQS gate bank BDI, 206053, correct ( or N) ? >(transmit)
Enter full name of OLTP-TM2200 library file TM$LIB, without the period
() >(transmit)
Enter the full name of MCB installation (library) file, without the
period () >MCB8*MCB$
2–54 3843 3744–002

Generating Alternate WMQ2200 Installations Using COMUS
Is the MCB installation (library) file, MCB8*MCB$, correct ( or N) ?
>(transmit)
*** Alternate WMQ2200 Installation Values defined ***
Project id for this generation () ? >(transmit)
Run id for this generation () ? >(transmit)
MASTER - reel/file./ ? >295H
Generation id ? >6R1
Generation heading () ? >WMQ$Z BUILD - LEVEL 6R1
Generation reason () ? >BUILD OF WMQ$Z LOCALLY
Generation reason () ? >(transmit)
New change number () ? >(transmit)
Type of generation (FULL or ) ? >FULL
NEWMASTER - reel/file./NONE/ ? >300H
The runstream has been saved in 'SYLVESTER*COMRUN(1).1/WMQ22006R1'
View the runstream (Y or ) ? >(transmit)
Print a copy of the runstream (Y or ) ? >(transmit)
Start the runstream (Y or ) ? >(transmit)
The runstream has been saved in 'SYLVESTER*COMRUN(1).1/WMQ22006R1'
UPDATING ACCESS FILES ...
ACCESS FILES HAVE BEEN UPDATED
BUILD TASK COMPLETED *************************
COMMAND ? >EXIT
END COMUS
5. Execute the following alternate installation build:
@START,A SYLVESTER*COMRUN.1/WMQ22006R1
After executing the COMUS-created product generation runstream in the
COMRUN file, check the results for errors.
Installing the Alternate Build
If the product generation completes successfully, you can register and install your
alternate installation tape through SOLAR, using the standard procedure for registering
and installing product tapes in use at your site.
Before installing your alternate installation tape with SOLAR you must use the
ICADMIN utility to configure the OS 2200 QProcessor designation number, port, and
new WMQ2200 installation qualifier. Doing this populates the IC$*PROCESSORS file
with the proper entries for the SOLAR install. Since only one installation of WMQ2200
is allowed on one OS 2200 QProcessor at a time, it might be necessary to remove old
entries in addition to adding new entries. For example, assume you are ready to install
an alternate build of WMQ2200 with qualifier WMQ$Z on OS 2200 QProcessor
designation 1 and designation 2.
First determine if there are any current entries for any OS 2200 QProcessors.
@ICADMIN
list_processor Q
3843 3744–002 2–55

Multiple WMQ2200 Installations as Static Resource Managers under Open DTP
Sample output:
QPROCESSOR 1 DEFAULT QPRM1:22719 WMQ$
QPROCESSOR 2 DEFAULT QPRM2:22719 WMQ$
Since there are two entries for OS 2200 QProcessors 1 and 2 with a mode of WMQ$,
you must remove those entries.
@ICADMIN
delete_processor Q 1
delete_processor Q 2
Now add back the new entries for OS 2200 QProcessors 1 and 2 with the mode of
WMQ$Z.
@ICADMIN
add_processor Q 1 WMQ$Z
add_processor Q 2 WMQ$Z
list_processor Q
Sample output:
QPROCESSOR 1 DEFAULT QPRM1:22719 WMQ$Z
QPROCESSOR 2 DEFAULT QPRM2:22719 WMQ$Z
Now you are ready to install your alternate mode of WMQ2200.
Refer to the ClearPath Specialty Engine for OS 2200 Configuration Guide for more
information on ICADMIN.
2.8. Multiple WMQ2200 Installations as Static
Resource Managers under Open DTP
The capability of building and installing an alternate version of WMQ2200 on site
provides you the ability of configuring both the default and alternate WMQ2200
installations as resource managers under Open DTP in two ways:
• You can configure each WMQ2200 installation as a resource manager under
separate Open DTP installations (one-to-one).
• You can configure all WMQ2200 installations under one Open DTP installation
(many-to-one).
Configuring Each WMQ2200 Installation under a Separate Open DTP
Follow the steps in Section 2.6.2, "Configuring WMQ2200 as a Static Resource
Manager under Open Distributed Transaction Processing" to configure the default
WMQ2200 installation under the default Open DTP installation. Then follow the same
steps again using the file names and qualifiers for your new WMQ2200 installation and
the alternate Open DTP installation.
2–56 3843 3744–002

Multiple WMQ2200 Installations as Static Resource Managers under Open DTP
Configuring Multiple WMQ2200 Installations under the Same Open
DTP
You can configure the default WMQ2200 installation and an alternate WMQ2200
installation as two unique resource managers under one Open DTP. This helps
conserve system resources and simplify system management.
1. Configure the default WMQ2200 installation as a resource manager under your
Open DTP installation following steps in "Configuring WMQ2200 as a Static
Resource Manager."
In the following steps, qualifier OTM$ is assumed for the Open DTP installation
used to manage multiple WMQ2200 installations as resource managers.
2. Build and install your alternate version of WMQ2200.
3. Update *MQSTOOLS.MQSWITCH/COMP-EXAMPLE to change
to the qualifier of the Open DTP installation to otm$ (or the qualifier
of an alternate Open DTP if using one). Ensure that the qualifier for the
MQS$SAMPLES file is changed to the new .
4. Update element *MQS$SAMPLES.MQSWITCH/C. Change the resource
manager name member in the xa_switch_t MQRMIXASwitch structure. This name
can be up to 32 characters long. For example, the default name is
“MQSeries_XA_RMI”. You can change it to “MQSeries_XA_RMI_1” to denote the
alternate WMQ2200 installation.
Note: Retain the double quotes around the name.
5. Add element *MQSTOOLS.MQSWITCH/COMP-EXAMPLE to compile
code module MQSWITCH/C and create the object module MQSWITCH/O in
*MQS$SAMPLES.
6. Add the new resource manager to the TMSCONFIG *GROUPS section. Use a
unique group name and the new resource manager name for the RMID,
MQSeries_XA_RMI_1.
The following GROUPS entry is an example for a default queue manager:
*GROUPS
mqdefalt ;
RMID = "MQSeries_XA_RMI_1"
If you want to run transactions to a non-default queue manager, you must include
the openinfo statement in your new group entry to contain the non-default queue
manager name as follows:
*GROUPS
mqnondefalt ;
RMID = "MQSeries_XA_RMI_1" ;
openinfo = "ALTQMGR"
3843 3744–002 2–57

Multiple WMQ2200 Installations as Static Resource Managers under Open DTP
7. Add the new GROUPS entry to any Open DTP server or client definition in
TMSCONFIG that uses this resource manager. The following is a client example:
*CLIENTS
MQCLIENTALT ;
group = mqdefalt
8. Load or append the TMSCONFIG.
9. Add OTM$*TM$UTIL.RMINSTALL and respond as in the following example:
Enter file name of the RM xa_switch OM >
*MQS$SAMPLES
Enter elt/vers name of RM_xa_switch OM >
MQSWITCH/O
Enter switch name for the RM
MQRMIXASwitch
Enter file containing RM XA gate bank object module >
*MQS$LIB
Enter elt/vers name of RM XA gate bank object module > >
MQS$ENTRY
Enter file name of the xa/h header >
Enter file name of TM gate bank >
Automatically @ADD RMLOADER {Y|}> <
10. Add the generated runstream RMINS$TEMP.RMLOADER and make sure you see
the successful load message.
You can now build and execute application programs that use the tx_* API verbs to
participate in global transactions with your alternate WMQ2200 installation under the
same Open DTP.
2–58 3843 3744–002

Section 3
Administration
Introduction
This section discusses WMQ2200 administrative tasks.
WMQ2200 is a hybrid architecture composed of two systems—the OS 2200 and the
OS 2200 QProcessor. WebSphere MQ runs on the OS 2200 QProcessor while user
applications and the shell (the UNX demand shell) run on the OS 2200.
Administration of WebSphere MQ for OS 2200 is accomplished through a variety of
ways including:
• WMQ2200 Daemon Administrative Utility
• UNX Shell
• OS 2200 QProcessor Administration Console
• WebSphere MQ Explorer
• Third-party software
The tools and utilities mentioned above provide overlapping functionality which allows
the WMQ2200 administrator a variety of means to configure, manage and administer
the WebSphere MQ for OS 2200 system. Full upwards compatibility is provided for
scripts created and used with previous levels of WMQ2200. In addition, some of the
WMQ2200 system tasks such as security, backup/restore, diagnostic gathering, and
configuration have been added to the new web-based OS 2200 QProcessor
Administration Console.
In this section, each task references the various utilities that perform the task. Details
on command syntax can be found in Appendix E for WMQ2200 Daemon
Administrative Utility, Appendix F for UNX Shell, and Appendix G for OS 2200
QProcessor Administration Console.
Use the following table as a key to navigating this section.
To … See subsection …
Start up or shut down WMQ2200 3.1
Start up and terminate queue managers 3.2
Configure MQ .ini files to customize WMQ2200 3.3
3843 3744–002 3–1

Start Up or Shut Down WMQ2200
To … See subsection …
Secure access to Queues from OS 2200 users 3.4
Manage Queue Manager log files 3.5
Backup of Queue Manager data 3.6
WMQ2200 administrative tools and sample programs 3.7
Use MQSeries Explorer for remote administration 3.8
3.1. Start Up or Shut Down WMQ2200
To ensure data integrity and recoverability, complete the following startup and
shutdown procedure.
3.1.1. Start Up
1. Start the OS 2200 QProcessor. Ensure the IC Launcher starts. You can use the
Interconnect Configuration module in the Configuration category of the
Administration Console to verify the IC Launcher is active. The service status must
be listed as Running.
2. Boot the OS 2200 system.
3. Ensure COMAPI, CPCOMM, and DDP-FJT is running. These can normally be started
when the OS 2200 system is booted. You can use the @@CONS T,B keyin to verify
that each interface has started. Refer to the documentation of each product for
more information.
4. Start the WMQ2200 daemon and ensure connectivity is established with the
OS 2200 QProcessor. Execute @*MQS$EXE.STARTUP to start
the WMQ2200 daemon. The startup program reports if the connection to the
OS 2200 QProcessor is successful.
>@WMQ$*MQS$EXE.STARTUP
Daemon started successfully.
Daemon connected to QProcessor successfully!
API is ready for use.
In addition, you can use the @@CONS APISTATUS command to
view the current status of the WMQ2200 QProcessor API connection. The WMQ
Keyin is configured in the WMQ2200 configuration file in the Daemon KeyId
section. The Connection Status must be listed as “Connected”:
STATUS:
-------------------------------
Connection Status: Connected
5. Use the UNX shell to start queue managers, listeners, trigger monitors, and all
other WebSphere MQ activities. The exact procedure and commands depend on
the site requirements.
3–2 3843 3744–002

Startup or Terminate Queue Managers
6. If running with WMQ2200 as a resource manager under Open DTP, reload the
OLTP tmsconfig and run RMINSTALL.
7. Start the OLTP TMSC background run.
8. Start user programs on the OS 2200.
3.1.2. Shut Down
1. Put a system hold on BATCH and/or TIP application starts.
2. Use the UNX shell to stop all WebSphere MQ queue managers, channels,
listeners, and all other activities.
3. Verify all MQ activity has stopped. You can use the mqstatus command in the UNX
shell to verify if all WebSphere MQ activity has terminated:
>@WMQ$*MQS$EXE.UNX
>mqstatus
>There are no MQ activities. It is safe to shut down.
Alternatively, you can use the OS 2200 QProcessor Administration Console to
check the status of WebSphere MQ activity on the OS 2200 QProcessor. Use the
Manage MQ module in the Management category.
4. Shut down the WMQ2200 daemon. Use the SHUTDOWN keyin to the daemon:
>@@CONS SHUTDOWN
The following is returned to the terminal that issued the SHUTDOWN keyin:
WMQ$ daemon terminating.
Daemon may take a minute to end.
WMQ$ daemon terminated.
In addition, the daemon background run must terminate:
WMQ FIN
5. Terminate OLTP (if using).
6. Shut down the OS 2200.
7. Shut down the OS 2200 QProcessor.
3.2. Startup or Terminate Queue Managers
3.2.1. Starting Queue Managers
A queue manager can be started in the following ways:
• Using the START command of the WMQ2200 Daemon.
• Using the strmqm command.
3843 3744–002 3–3

Startup or Terminate Queue Managers
3.2.1.1. WMQ2200 Daemon START Command
You can use the WMQ2200 daemon START command to start one queue manager or
to start every queue manager that has been created within your WMQ2200 system.
@@CONS keyinid START queuemanager
@@CONS keyinid START ALL
Where queuemanager is the name of a particular queue that has previously been
created. See Appendix E, "WMQ2200 Daemon Administrative Utility," for more
information on the START command.
Note: Remember that the MQAuthority parameter determines whether Object
Authority Manager (OAM) is enabled for a queue manager when it was created.
Refer to Section 2," Installation and Configuration," for more information.
3.2.1.2. strmqm Command
The strmqm command can also be used to start queue managers. Enter the strmqm
command to start each queue manager.
If You Use the UNX Shell to Administer WMQ2200
@WMQ$*MQS$EXE.UNX
>strmqm
>exit
See Appendix F, "UNX Shell," for more information on using UNX.
If You Use OS 2200 QProcessor Administration Console for
Non-interactive WMQ2200 Commands
Navigate to the Manage MQ module under the Management tab.
Select the queue manager to start by clicking on the start action associated with the
queue manager. All created queue managers appear in the queue manager table. All
queue managers can be started by selecting the Start All button found in this
module.
Refer to the QProcessor Administration Console Help for more information on using
the Command Shell module.
3.2.2. Terminating Queue Managers
Queue managers are meant to run indefinitely, to protect queue manager resources
and message recoverability and to stop only after all applications are disconnected. If
you need to end a queue manager, for example, to upgrade to a newer WMQ2200
level, you must end it properly. Follow these guidelines to properly stop a queue
manager and its related activities.
1. Stop or throttle user applications that use the MQI if possible.
3–4 3843 3744–002

Startup or Terminate Queue Managers
2. Stop running local sender channels; these are channels that send messages out
from the local machine.
a. Check which sender channels are active in a UNX session using the runmqsc
processor ‘display channel status’ command for all channels.
@WMQ$*MQS$EXE.UNX
runmqsc
>DIS CHS(*)
AMQ8417: Display Channel Status details.
CHANNEL(A.TO.B.CHANNEL) XMITQ(A.TO.B.QUEUE)
CONNAME(999.22.444.333(2011)) CURRENT
CHLTYPE(SDR) STATUS (RUNNING)
AMQ8417: Display Channel Status details.
CHANNEL(B.TO.A.CHANNEL) XMITQ( )
CONNAME(999.22.444.333) CURRENT
CHLTYPE(RCVR) STATUS (RUNNING)
b. Use the runmqsc STOP CHANNEL command to stop all sender channels in the
RUNNING state as follows:
>STOP CHANNEL (A.TO.B.CHANNEL)
AMQ8019: Stop MQSeries channel accepted.
The status of the sender channel should now be stopped.
>DIS CHS(*)
AMQ8417: Display Channel Status details.
CHANNEL(A.TO.B.CHANNEL) XMITQ(A.TO.B.QUEUE)
CONNAME(999.22.444.333(2011)) CURRENT
CHLTYPE(SDR) STATUS (STOPPED)
AMQ8417: Display Channel Status details.
CHANNEL(B.TO.A.CHANNEL) XMITQ( )
CONNAME(999.22.444.333) CURRENT
CHLTYPE(RCVR) STATUS (STOPPED)
c. Enter the END command to exit the runmqsc processor.
3. Stop sender channels on remote machines in a similar manner if possible. These
are channels that send messages into the local machine. If an application on a
remote machine sends data to one of your local queues, the queue manager will
not end because the listener (receiver channel) is busy.
4. After channel activity has stopped, end the queue manager. This can be done in a
variety of ways.
3843 3744–002 3–5

Startup or Terminate Queue Managers
If You Administer WMQ2200 with Daemon Administrative Utility
Enter the following command to achieve a controlled shutdown for all queue
managers.
Or
>@@CONS WMQ TERM ALL
>@@CONS WMQ TERM,C ALL
If you are unable to stop user application programs that use the MQI before
ending the queue manager, use the I-option to prevent any new MQI calls from
starting. This is referred to as an immediate shutdown. The queue manager
completes processing the in-progress MQI before ending.
>@@CONS WMQ TERM,I ALL
If You Use the UNX Shell to Administer WMQ2200
Enter the endmqm command for controlled (no option or -c option) or immediate
(-I option) shutdown of each queue manager.
@WMQ$*MQS$EXE.UNX
>endmqm -i
>exit
If You Use OS 2200 QProcessor Administration Console to Administer
WMQ2200
Navigate to the Manage MQ module under the Management tab. Find the queue
manager to stop from the queue manager table. Select the "Stop" action for the
queue manager.
To stop all queue managers, select the Stop All button.
Note: WMQ2200 offers the preemptive shutdown option P for endmqm and
MQADMIN. However, this type of shutdown can only be used in exceptional
circumstances. It is similar to an e-keyin of a batch run and it is not advised.
If you manually stop a sender channel and do not end and restart your queue
manager, you have to manually restart the channel. The channel initiator does
not automatically start channels for you after the runmqsc STOP CHANNEL
command. You can restart the sender channels with the runmqsc START
CHANNEL command, or end and restart the queue manager. If you configure
your channels with shorter disconnect intervals, they disconnect and shut down
for you automatically after shorter periods of inactivity. Channels that stop as a
result of a disconnect interval are restarted by the channel initiator if a trigger
condition is met.
5. After stopping queue managers, the WMQ2200 daemon run (WMQ) is still active.
You can end the daemon run with the following command:
>@@CONS WMQ DOWN
3–6 3843 3744–002

Configure MQ .ini Files to Customize WMQ2200 and the Queue Managers
3.3. Configure MQ .ini Files to Customize
WMQ2200 and the Queue Managers
The .ini files can be modified to customize WMQ2200. The files can be edited in any of
the following ways:
• Use the OS 2200 editor and then transfer the file to the OS 2200 QProcessor.
• Use the OS 2200 QProcessor Administration Console to edit selected files using
your web browser.
• Use the TED command within the UNX Shell.
3.3.1. Using OS 2200 Editors to Modify the .ini Files
To use your OS 2200 editor, update the initialization (.ini) file in the following manner:
1. Catalog file to use with MQEXPORT command.
2. Copy this file to an OS 2200 element using the UNX MQEXPORT command.
3. Modify the file using your choice of editor.
4. Stop the queue manager.
5. Make the modified information accessible to the OS 2200 QProcessor using the
UNX MQIMPORT command.
6. Restart the queue manager. The changes take effect when the queue manager is
restarted.
Example
>@cat,p wmq*inifile.
@WMQ$*MQS$EXE.UNX
>mqexport qm.ini wmq*inifile.
>mqexport: Transferred 1294 bytes to file wmq*inifile.
After you edit your file, import it back into the OS 2200 QProcessor.
@WMQ$*MQS$EXE.UNX
>mqimport wmq*inifile. qm.ini
>mqimport: Transferred 1351 bytes to file qm.ini
See Appendix F, "UNX Shell," for more information on mqimport and mqexport.
3.3.2. Using OS 2200 QProcessor Administration Console
To use the OS 2200 QProcessor Administration Console to edit the initialization files,
1. Log into the Administration Console and navigate to the Management Tab.
2. Double-click on the Manage MQ module.
3843 3744–002 3–7

Secure Access to Queues from OS 2200
3. Either edit the global mqs.ini configuration file by selecting Edit in the MQ Server
table or edit a particular queue manager’s .ini file by selecting the Edit action on
the particular queue manager entry in the table.
4. Stop and restart the queue manager by selecting the stop action followed by the
start action once the queue manager is terminated. The changes will take place
when the queue manager is restarted.
Refer to the QProcessor Administration Console Help for more information.
3.3.3. Using the TED Editor
The TED editor is a line based editor available through the UNX shell. It allows basic
functions such as insert, delete, and update of text.
See Appendix C, "Editing WMQ2200 QProcessor Files," for more information on using
TED.
3.4. Secure Access to Queues from OS 2200
3.4.1. Security and the UNX Demand Shell
When an OS 2200 user starts a UNX shell, the OS2200 user ID is mapped to an
OS 2200 QProcessor identity (user and group). If the user has not been explicitly
mapped by an administrator, the user runs as the "nobody" user and group. If the
group to which the OS 2200 user is mapped is not in the mqm group, the OS 2200
user cannot execute WebSphere MQ control commands, view various directories, and
perform other administrative tasks. The UNX shell warns users if they are not in the
mqm group when it starts.
3.4.2. The Root User and WebSphere MQ
An OS 2200 user can be mapped to the root user and group on the OS 2200
QProcessor. This user has authority to perform all system-wide administrative
functions on the OS 2200 QProcessor. At least one OS 2200 user must be mapped to
root to allow the WMQ2200 software to be installed on the OS 2200 QProcessor.
For security reasons, by default, the root user is not a member of the mqm group. This
means that OS 2200 user IDs mapped to the root user cannot run WebSphere MQ
control commands by default. If you want the OS 2200 users mapped to the root user
to also have access to run WebSphere MQ control commands, use the ‘rootmod -a’
command in the UNX shell. The rootmod command can be used to add or remove the
root user from the mqm group on the OS 2200 QProcessor. The rootmod command
can only be run by the OS 2200 user mapped to root on the OS 2200 QProcessor. The
root user can be removed from the mqm group with the ‘rootmod –r’ command.
Because the root user has high levels of permissions on the OS 2200 QProcessor,
users are encouraged to use caution when using the UNX shell while running as the
root user. The UNX shell warns users when entering the shell if they are mapped as
the root user.
3–8 3843 3744–002

Secure Access to Queues from OS 2200
3.4.3. WebSphere MQ Object Authority Manager
WebSphere MQ provides an interface that allows an administrator to restrict access
to queue manager objects. This interface is called Object Authority Manager (OAM).
Additional information on the OAM can be found in the IBM WebSphere MQ Security
manual.
The OAM can be enabled or disabled on a per queue manager basis. Whether OAM is
enabled on a given queue manager is determined when the queue manager is created.
The presence of OAM on a queue manager is determined by the existence of the
MQSNOAUT environment variable in the shell that performs the create queue
manager (crtmqm) command. This is controlled through the WMQ2200 configuration
parameter MQAuthority, which is documented in Section 2.4 Adjusting MQS2200
Configuration Parameters.
If OAM is enabled when the queue manager is created, it cannot be disabled later.
OAM also cannot be added to a queue manager after it has been created. A queue
manager must be deleted and recreated to change its OAM setting. If OAM is enabled
on a given queue manager, API access to the queue manager is controlled by OAM
and users are authenticated for the type of access they are attempting on an object
basis.
Note that OAM does not affect the MQ control commands; you must always be in the
mqm group to execute MQ control commands from a shell.
The WebSphere MQ OAM is only aware of OS 2200 QProcessor users and groups. It
is not aware of OS 2200 user IDs. The WebSphere MQ OAM is presented with the
OS 2200 QProcessor mapping, for the OS 2200 user and validates the user based on
those credentials.
3.4.4. Remote Users and OS 2200 Users
There are two types of user IDs for purposes of OS 2200 QProcessor administration:
• Remote user ID
• OS 2200 user ID
A remote user ID is a user ID installed on the OS 2200 QProcessor that maps to a user
ID on a remote system (other than the OS 2200 assigned to the OS 2200 QProcessor).
For example, you may need to create a user ID on your OS 2200 QProcessor that
matches your Windows user ID so that you can administer an OAM enabled queue
manager over the client connection through WebSphere MQ Explorer.
3843 3744–002 3–9

Secure Access to Queues from OS 2200
In this case, your user ID is called a remote user ID. This user ID must be created on
the OS 2200 QProcessor using either the mquseradd command in the UNX shell or the
OS 2200 QProcessor Administration Console. This user ID must be all lowercase
because WebSphere MQ converts all incoming foreign user IDs to lowercase before
attempting to map it to a user and group on the OS 2200 QProcessor for security
validation. Therefore, if your Windows user ID is JohnQSmith, you would need to
install this user ID on the OS 2200 QProcessor as a remote user ID with the name
‘johnqsmith’. The term "remote" is somewhat misleading because although it
represents and matches a user ID on another system, it is installed on the OS 2200
QProcessor as well.
An OS 2200 user who wishes to access WebSphere MQ queue managers and
execute WebSphere MQ control commands must be mapped to a local user ID and
group on the OS 2200 QProcessor. If an OS 2200 user is not mapped explicitly to an
OS 2200 QProcessor user ID and group, it runs as the nobody user and group and
have no authority to access WebSphere MQ control commands or access the MQ API
(if the queue manager has OAM enabled).
3.4.5. The WebSphere MQ OAM Control Commands
WebSphere MQ provides two control commands for displaying and configuring
authorities on an OAM enabled queue manager. The control commands are setmqaut
(set an MQ OAM authority) and dspmqaut (display an MQ OAM authority). These
commands accept a principal (user ID) or a group name specification. Any group
specified must exist on the OS 2200 QProcessor and is case-sensitive. When a
principal (user ID) is specified, both commands assume that the principal is a remote
user ID by default. A common case where you would grant access to a remote user ID
would be granting authorities to a Windows user ID so it can access a queue manager
on the OS 2200 QProcessor through the WebSphere MQ Explorer. If you specify a
remote user ID (the default), the user ID is case-sensitive and normally will be all
lowercase if the remote user ID was added correctly.
Alternatively, the user can use the –O option to specify to the commands that the
supplied principal is an OS 2200 user ID. This can be done when you want to grant an
OS 2200 user application authority to the queue manager. The user ID supplied can be
in any case when specifying an OS 2200 user ID using the –O option. The commands
attempt to map the principal name from the OS 2200 user ID to the equivalent
OS 2200 QProcessor user ID using the OS 2200 QProcessor user mapping table. The
OS 2200 QProcessor user ID is then passed to the WebSphere MQ OAM component.
If the principal name cannot be mapped because the OS 2200 user ID specified is not
in the user mapping table, the commands return an error indicating that the principal is
not valid. If a group is specified instead of a principal, the commands ignore the –O
option (if supplied) because groups only exist on the OS 2200 QProcessor. Refer to
the IBM WebSphere MQ System Administration manual for more information on the
MQ OAM control commands.
3–10 3843 3744–002

Examples
Set an authority for a remote user ID (the default):
Secure Access to Queues from OS 2200
>setmqaut -m MY.QMGR -t qmgr -p MyWindowsId +connect
Set an authority for an OS 2200 user ID:
>setmqaut -m MY.QMGR -t qmgr -O -p CHARLIE +connect
Set an authority for a group:
>setmqaut -m MY.QMGR -t qmgr -g limitedmq +connect +set
3.4.6. WebSphere MQ OAM Authentication
The WebSphere MQ OAM always stores authorities on a group basis. That is, if one
member of a given group is granted a specific type of access to a given object, all
members of that group inherit access to that object. This is true even if an MQ
administrator grants access to an object specifying a specific user ID, rather than a
group. WebSphere MQ OAM refers to individual users as principals. Since WebSphere
MQ OAM stores authorities on a group basis, users are recommended to grant or
revoke authorities using a specific group specification, rather than specifying an
individual user for clarity. Specifying a user (or principal) is allowed but it affects all
users in that group.
3.4.7. WebSphere MQ OAM and the mqm Group
From the WebSphere MQ perspective, any user that is a member of the mqm group is
a WebSphere MQ super user. The mqm group always has full control of WebSphere
MQ, from both the control commands and API perspective. The mqm group can never
be limited in its access of WebSphere MQ. Therefore, if a user is a member of the
mqm group, the user has full authority over WebSphere MQ as access is granted on a
group basis. The OS 2200 users who are mapped to the OS 2200 QProcessor mqm
group have full authority to run WebSphere MQ control commands in the UNX shell,
view and edit files in the WebSphere MQ file system through the UNX shell, and
access the WebSphere MQ API.
3843 3744–002 3–11

Secure Access to Queues from OS 2200
3.4.8. The "Nobody" User and Group
The "nobody" user and group exists on the OS 2200 QProcessor as a default
no-permissions identity. OS 2200 users not explicitly given a mapping to an OS 2200
QProcessor identity by an administrator default to the nobody user and group. This
means that WebSphere MQ treats OS 2200 users not mapped to an identity on the
OS 2200 QProcessor as the nobody user and group. The nobody group has no access
to WebSphere MQ by default.
Caution
You must never grant the nobody user or group access to queue managers
using the WebSphere MQ OAM set authority control commands
(setmqaut). If you do this, you will implicitly grant authority on the given
queue manager to all OS 2200 users not explicitly mapped to OS 2200
QProcessor identities.
3.4.9. Default Groups on the OS 2200 QProcessor
The default system groups on the OS 2200 QProcessor include the nobody, mqm, and
root groups. The nobody group has no authority to WebSphere MQ. The mqm group
has full authority to WebSphere MQ control commands, files, and API. The root group
has full authority to perform system administration. If the root user has been added to
the mqm group with the UNX rootmod command, the root group and user will also be
able to execute WebSphere MQ control commands.
3.4.10. Adding a Group on the OS 2200 QProcessor
If you want to use OAM to set custom permissions for one or more users, you need
to create a group for these users. After you create the new group, you can add users
to the group. You can also add OS 2200 and remote users to the same group if you
want. Custom permissions on a given queue manager and its objects can then be
given to this group. You can add a group to the OS 2200 QProcessor in either of the
following ways:
If You Use the UNX Shell to Administer WMQ2200
Use the groupadd utility in the UNX shell:
>groupadd
After the group is added on the OS 2200 QProcessor, it can be used by OAM
commands to set or display authorities on a given queue manager. You can display a
list of installed groups on the OS 2200 QProcessor with the grouplist command in the
UNX shell.
You can use the groupmembers command in the UNX shell to list the members of a
specific group. The groupdel command can be used to delete a group on the OS 2200
QProcessor. Note that you cannot delete a group if any users are still members of that
group.
3–12 3843 3744–002

Secure Access to Queues from OS 2200
If You Use OS 2200 QProcessor Administration Console to Administer
WMQ2200
Using the OS 2200 QProcessor Administration Console, you cannot create a new
group in the administration console without creating a new user. To create a new
group, use the Manage User Mappings module in the Management category to add a
new user, using the Add New User Map, select Type New grp in the group
selection box and type a new group. The new group is created when the user is
added. Subsequent users are able to select the new group.
All groups available to the new user can be viewed in the Local group list.
You can also see a list of installed groups in the group selection list in the OS 2200
QProcessor Administration Console. Refer to the QProcessor Administration Console
Help for more information.
3.4.11. The OS 2200 QProcessor User Mappings
The OS 2200 QProcessor maintains mappings of OS 2200 users to OS 2200
QProcessor users and groups. The OS 2200 QProcessor also maintains mappings
from a non-OS 2200 system (remote users) to the OS 2200 QProcessor users and
groups.
Access to the OS 2200 QProcessor is controlled by these mappings. To allow and
manage access to the OS 2200 QProcessor use the OS 2200 QProcessor
Administration Console. To create, edit, or delete a mapping, use the Manage User
Mappings module.
Creating a New User Mapping
You can create a new user mapping using the OS 2200 QProcessor Administration
Console or the mquseradd UNX command. When you add a user, you must specify
the user to be mapped, the type of user (remote or OS 2200), and the group on the
OS 2200 QProcessor you want to use.
If the user ID you are adding is an OS 2200 user ID, the OS 2200 QProcessor user ID to
which the OS 2200 user ID is mapped is generated automatically. If the OS 2200 user
is mapped to the
• Root group, the OS 2200 user is mapped to the root user and group.
• nobody group, the OS 2200 user is mapped to the nobody user and group.
• mqm group, a custom group, or a new group, the OS 2200 user is mapped to
IC- where is the OS 2200 user ID (in uppercase). The IC-
is created because some OS 2200 user IDs do not conform to the OS 2200
QProcessor user ID requirements. For example, they cannot start with a number
while OS 2200 user IDs can.
3843 3744–002 3–13

Secure Access to Queues from OS 2200
If the user ID you are adding is a remote user ID, the remote user ID must be specified
in lowercase. This is because WebSphere MQ OAM always converts foreign user IDs
to lowercase before performing security checks and comparisons to local user IDs
that match the remote user ID. The remote user can be added to any group you want.
For details on how to add an OS 2200 or remote user, see the QProcessor
Administration Console Help or Appendix F, “UNX Shell,” for more information on the
mquseradd command.
Changing a User Mapping
You can change a user mapping or remote user ID using the OS 2200 QProcessor
Administration Console or the mqusermod UNX command. When you change a user
mapping, you select a new group. If you use the mqusermod command in the UNX
shell, you must specify whether you are modifying an OS 2200 or remote user ID. See
Appendix F, "UNX Shell," for more information on the mqusermod command.
If you are changing an OS 2200 user mapping, the OS 2200 QProcessor user ID you
are assigned follows the rules listed in the section above. In some cases, the
underlying OS 2200 QProcessor user ID changes depending on these rules. Note that
it might take up to 60 seconds for the new OS 2200 user mapping change to take
effect in the API. In addition, running applications using the API do not use the new
mapping until they are restarted. The UNX shell reflects the change the next time the
user starts a UNX shell. Existing UNX shells that the OS 2200 user runs need to be
restarted for changes to take effect.
If you are changing a remote user ID, the OS 2200 QProcessor user ID keeps the same
name. Only the group membership changes.
Deleting a User Mapping
You can delete a user mapping or remote user ID using the OS 2200 QProcessor
Administration Console or the mqusermdel UNX command. See Appendix F, "UNX
Shell," for more information on the mqusermod command.
If you are deleting an OS 2200 user mapping, the underlying OS 2200 QProcessor user
ID is deleted from the system and the user mapping is removed from the OS 2200
user mapping table. The UNX shell reflects the change the next time the user starts a
UNX shell. Existing UNX shells that the OS 2200 user runs need to be restarted for
changes to take effect.
For both OS 2200 user IDs and remote user IDs deleted from the OS 2200
QProcessor, the user defaults to nobody group permissions (no permissions).
Caution
Never use other interfaces to change, add, or delete user mappings or
modify the OS 2200 QProcessor users directly. Doing so could cause
WMQ2200 to malfunction or become inoperable.
3–14 3843 3744–002

Displaying the User Mappings and Remote User IDs
Secure Access to Queues from OS 2200
You can display the current user mappings and remote user IDs by using the Manage
User Mappings module of the OS 2200 QProcessor Administration Console. The user
mappings and remote user IDs are listed in the administration console in the
Interconnect User Map module in the Management category. You can also use the
mquserlist UNX command. See Appendix F, "UNX Shell," for more information on the
mquserlist command.
Remote User IDs that Cannot be Changed
Since remote user IDs represent local user IDs on the OS 2200 QProcessor, some of
these user IDs have special significance and cannot be changed. The UNX commands
that allow you to modify or remove remote user IDs (which represent installed user
IDs on the OS 2200 QProcessor) will not allow you to remove or edit users mqm,
nobody, and root. Other system users are locked as well. These user IDs cannot be
deleted or the OS 2200 QProcessor may malfunction. Custom remote user IDs you
add can be deleted or changed at any time.
The –MQS- and MQM Mappings
Two mappings are created when WMQ2200 is installed, the –MQS– and MQM
mappings. The –MQS– user ID is the default WMQ2200 subsystem owner. It is
typically the owner of the MQS$COMMON file in a SecOpt security environment. The
WMQ2200 subsystem owner in a Security Option environment must be mapped to
the root user and group. If you are running in the Security Option environment, and
your MQS$COMMON file is owned by someone other than –MQS–, that OS 2200 user
ID must be mapped in the Usermap file to the root group. The MQM user (if it exists
on OS 2200) always maps to the mqm user and group on the OS 2200 QProcessor.
You are not required to have an OS 2200 MQM user. However, if you do have a MQM
user on OS 2200, it runs as the mqm user and group on the OS 2200 QProcessor.
Note: The –MQS– and MQM mappings are locked for editing. Do not delete or
modify the mappings. Changing these mappings causes WMQ2200 to malfunction.
User Map Changes and OAM
If you change a user mapping (either remote or an OS 2200 user mapping), the OAM
cache might become out of date. While a queue manager is running, it caches
authority information for each user. As each user accesses a given queue manager,
the OAM service requests a list of groups the given user is a member of from the
OS 2200 QProcessor. This list is cached for the duration of the queue managers
running lifetime. If group memberships change for the given user, the OAM cache
becomes out of date. WebSphere MQ does not recognize the new group membership
for the user until its OAM cache has been updated. This can be done through the
runmqsc REFRESH SECURITY TYPE(AUTHSERV) command. You must refresh the OAM
cache on your queue managers after changing a user mapping.
3843 3744–002 3–15

Manage Queue Manager Log Files
User Mappings when OAM is Disabled
When OAM is disabled on a given queue manager, authority checks are not performed
when the MQ API is used to interact with a queue manager. This means all OS 2200
users and remote users through channels have access to the queue manager.
However, the user mappings are still enforced when an OS 2200 user uses the UNX
shell. Although user mappings are not used for authentication when OAM is disabled
on a queue manager, creating user mappings for OS 2200 users who use the API is
still useful. This is because the OS 2200 QProcessor user ID in a given OS 2200 user is
mapped and stored in the MQMD UserIdentifier field when that OS 2200 user puts
messages to the queues. If OAM is disabled and an OS 2200 user without a user
mapping puts a message to a queue, the MQMD UserIdentifier field reports a user of
nobody because this is the default mapping.
TIP/HVTIP Applications User Mapping
TIP/HVTIP applications run as the OS 2200 user ID configured in the OS 2200 TIP
System User ID. If the default TIP system user ID is used (12 ASCII spaces), the
behavior of the WMQ2200 API depends on whether the OAM is enabled for the queue
manager being accessed. In either case, if the TIP System User ID is the default, the
TIP/HVTIP application runs as the nobody user and group on the OS 2200 QProcessor
because there is no OS 2200 user to map to the OS 2200 QProcessor identity. If OAM
is not enabled on the queue manager being accessed, the WMQ2200 API calls will
succeed and any messages put to queues will have a MQMD UserIdentifier of
nobody. If OAM is enabled on the queue manager being accessed, the TIP/HVTIP
server receives a CompCode of MQCC_FAILED (2) with Reason Code
MQRC_NOT_AUTHORIZED (2035), because the nobody group has no access to a
WebSphere MQ queue manager. If TIP/HVTIP applications need to access a queue
manager, you must either create the queue manager with OAM disabled or specify a
valid OS 2200 user ID in the TIP System User ID and map that OS 2200 user ID on the
OS 2200 QProcessor to a group with sufficient authority to access the given queue
manager.
3.5. Manage Queue Manager Log Files
Log files are associated with a queue manager. These log files are essential if you
need to restore a queue manager’s state in case of disk or hardware failure. If linear
logging is used, these files need to be managed and archived occasionally to avoid
using unnecessarily large amounts of disk. The default number of log pages in a log
file is 1024 and the log file size is 4 MB.
The minimum number of pages in a log file is 64, and the maximum is 65,535.
Note: To adjust the number of pages in your log files, use the -lf option on the
crtmqm command to specify the size of the log file in tracks. The crtmqm command
can be entered using the UNX shell (see Appendix F, "UNX Shell," for more
information) or the Manage MQ module of the OS 2200 QProcessor Administration
Console (Refer to the QProcessor Administration Console Help for more
information).
3–16 3843 3744–002

3.5.1. Overview
Manage Queue Manager Log Files
If you are using a linear log, the log files are added continuously as data is logged, and
the amount of space used within your WMQ2200 file system increases with time. If
the rate of data being logged is high, new log files, also known as log extents,
consume space rapidly.
Over time, the older log files for a linear log are no longer required to restart the
queue manager or perform media recovery of any damaged objects. Unisys
recommends that these older log files are archived. Log files can be archived using the
mqsavelog command of the UNX shell or using the Manage MQ Log Policy module
under the Management tab of the OS 2200 QProcessor Administration Console.
Periodically, the queue manager places a pair of messages into an OS 2200
QProcessor error file to indicate which of the log files is required. Error files can be
viewed using the View System Logs module under the Diagnostic tab of the OS 2200
QProcessor Administration Console. There will be an error log for each queue
manager that was created.
• Message AMQ7467 gives the name of the oldest log file needed to restart the
queue manager. This log file and all newer log files must be available during queue
manager restart.
• Message AMQ7468 gives the name of the oldest log file needed to do media
recovery.
3.5.2. If You Use the UNX Shell to Administer WMQ2200
If you are using UNX to administer WMQ2200, use the mqsavelog command which
will query for the queue manager whose log data is to be saved and whether linear
logs must be deleted after they are moved (when –i not specified).
@WMQ$*MQS$EXE.UNX
mqsavelog[-i] qualifier[-s sgsfile]
>Enter WebSphere MQ queue manager name
queuemanager
.
.
.
Where:
-i specifies information only.
qualifier specifies the OS 2200 qualifier to be used for the destination files. Use a
unique qualifier for each queue manager, and use only one qualifier for each queue
manager across multiple mqsavelog executions.
sgsfile specifies the output location for SGSs generated when you use the s option.
The value you provide for sgsfile must be an OS 2200 data file or element name.
queuemanager specifies name of the queue manager.
3843 3744–002 3–17

Backup of Queue Manager Data
See Appendix F, “UNX Shell," for more information on mqsavelog.
To allow you to automate log file archival operations, WMQ2200 displays a message
to the system console whenever new files are candidates for archive. The console
message is in the form:
>WMQ*WebSphere AMQ7467 qmgr
Where qmgr is the name of the queue manager that has one or more new log files
that are candidates for archival.
The execution controller for each running queue manager internally tracks log files and
only prints a message when there are new candidate log files for WMQ2200 which
can generate multiple AMQ7467 messages for a single log file. It places these
messages into the OS 2200 QProcessor error file mentioned above. However, if you
stop your queue manager through endmqm and then restart it through strmqm, you
might receive a console message that is a duplicate of the message you last received
before stopping the queue manager. Therefore, you could receive a console message
when there are no new candidate log files for archive. You can design your automated
archival utilities accordingly, such that they function properly if invoked to process
files when there are none to process.
Note: mqsavelog attempts to maintain an internal history file to keep track of your
archived log extents; however, for maximum recoverability, maintain records of
archived and restored files separate from these utilities.
3.5.3. If You Administer WMQ2200 Using OS 2200 QProcessor
Administration Console
The OS 2200 QProcessor Administration Console allows you to schedule backup of
log files that are available for archival using the Manage MQ Log Policy module. This
module includes options for compression and location of the archive including local,
remote, or OS 2200 disks. The scheduling options allow you to customize when to
automatically scan the queue manager for available files. With this option, the
archiving is done automatically based on the criteria specified. Refer to the
QProcessor Administration Console Help for more information.
3.6. Backup of Queue Manager Data
The OS 2200 QProcessor provides redundant disks with disk mirroring to guard
against disk failure. WMQ2200 system, queue, and log data (/var/mqm) are stored on
these redundant disks. There are various levels of backup and restore available:
• Backup of WebSphere MQ for OS 2200 configuration data include OS 2200
QProcessor Administration Console data.
• Backup of WebSphere MQ queue manager queue data.
• Backup of WebSphere MQ queue manager log data.
3–18 3843 3744–002

WMQ2200 Administrative Tools and Sample Programs
The OS 2200 Administration Console Filesystem Backup module provides a default
backup profile to include WebSphere MQ for OS 2200 configuration data. The
WebSphere MQ queue manager log data can be saved on external disks or locally on
mirrored disks. The queue manager data can be rebuilt from the logs that are saved.
You might want to back up your queue manager data to provide protection against
possible corruption due to hardware failures. WMQ2200 provides a pair of utilities,
mqsave and mqload that allow you to back up and restore all the files associated with
a queue manager. These commands are run from a UNX session and the data is stored
in OS 2200 files. See Appendix F, "UNX Shell," for more information on mqsave and
mqload. You can also use the Manage MQ module in the OS 2200 QProcessor
Administration Console to backup the queue manager data. Using this module, you can
perform a one-time or scheduled backup of the /var/mqm file system or individual
queue managers. Refer to the QProcessor Administration Console Help for more
information.
Note: You can choose not to take queue manager data backups since message data
is often short-lived.
The status of the disk subsystems can be viewed using the System Health module in
the Diagnostic category of the OS 2200 QProcessor Administration Console. Refer to
the QProcessor Administration Console Help for more information.
Refer to Section 8, "Recovery Procedures," for information on restoring WMQ2200
data and logs after system failure.
3.7. WMQ2200 Administrative Tools and Sample
Programs
The file WMQ$*MQSTOOLS contains tools, utilities, and sample programs that you
will find useful when using your WMQ2200 system.
The following addstreams are useful during troubleshooting activities. Refer to Section
7, "Troubleshooting", for more information.
• CAT/ERRORS
• DEACT/BOTH
• DEACT/BM
• DEACT/MQS
• DIAGN/RUN
• DEACT/UNX
• DUMPBANKS/MQS
• DUMPBANKS/UNX
3843 3744–002 3–19

Remote Administration Using WebSphere MQ Explorer
The MQSERIES/CONFIG element is a template for your WMQ2200 configuration file.
Refer to Section 2, "Installation and Configuration," for information on this file and to
modify the WMQ2200 configuration.
3.8. Remote Administration Using WebSphere MQ
Explorer
The WebSphere MQ Explorer utility allows remote administration of WebSphere MQ
queue managers and objects. The WebSphere MQ Explorer utility runs on Windows
and is available on the WebSphere MQ for Windows product from IBM. WMQ2200
can be administered remotely with WebSphere MQ Explorer. Using WebSphere
Explorer you can
• Create, define, or delete objects including queues, channels, processes, and
namelists
• Browse messages on queues
• Start and stop channels
• View channel status
Refer to the IBM WebSphere MQ System Administration manual, for details on the
WebSphere MQ Explorer utility. The WebSphere MQ Explorer utility uses an MQI
client connection to communicate with WebSphere MQ queue managers. Refer to
Section 5, "MQI Client Connection," for more information.
3.8.1. Preparing WMQ2200 for Remote Administration
To administer WMQ2200 remotely with the WebSphere MQ Explorer utility, complete
the following steps:
1. Start the command server for the queue manager you want to administer. Use the
STRMQCSV command to start the command server.
STRMQCSV [queue_manager_name]
2. Start a WebSphere MQ listener process.
RUNMQLSR [-m queue_manager_name] [-p port] [&]
3. Define a server-connection channel called SYSTEM.ADMIN.SVRCONN. The
WebSphere MQ Explorer utility requires a sever-connection channel on all queue
managers being administered.
>runmqsc QMGR
>active:15
>Starting MQSeries Commands.
>DEFINE CHANNEL(SYSTEM.ADMIN.SVRCONN) +
>1: DEFINE CHANNEL(SYSTEM.ADMIN.SVRCONN) +
>CHLTYPE(SVRCONN)
>CHLTYPE(SVRCONN)
>AMQ8014: WebSphere MQ channel created.
3–20 3843 3744–002

Remote Administration Using WebSphere MQ Explorer
Note: The preceding command is a basic channel definition. You can specify
additional parameters in some circumstances. Refer to the IBM document
WebSphere MQ MQSC Command Reference for more information.
3.8.2. Connecting or Disconnecting to WMQ2200 from the
WebSphere MQ Explorer
For information on connecting or disconnecting to WMQ2200 from the WebSphere
MQ Explorer and for information on how to use it, refer to the IBM WebSphere MQ
System Administration Manual.
3.8.3. Restrictions
The following functions in WebSphere MQ Explorer are not supported by WMQ2200:
• The LU 6.2 tab of a channel properties dialog box. WMQ2200 does not support the
LU 6.2 protocol.
• Only the TCP/IP protocol is supported by WMQ2200. When creating or modifying
a channel definition from MQSeries Explorer, do not select any other protocol in
the Transmission Protocol box in the General tab of the channel properties dialog
box.
3843 3744–002 3–21

Remote Administration Using WebSphere MQ Explorer
3–22 3843 3744–002

Section 4
Application Development
4.1. Exits
This section discusses application development, including exits and triggers. You can
write your application program in either COBOL or C language.
Note: Unisys recommends that you define a default queue manager.
Use the following table as a key to navigating this section.
To … See subsection …
Read about exits 4.1
Read about triggers 4.2
Use binary data in the message area 4.3
Compile and link WMQ2200 application programs 4.4
Read about sticking transactions 4.5
See the WMQ$*MQSSAMPLES.README file for information on sample programs.
Refer to Appendix B, "Application Development," for information on recommended
transaction scenarios.
An exit is a point in application processing where you can develop and run your own
code. For WMQ2200 to call your exit code, you must deploy your exit code to the
OS 2200 QProcessor. Refer to Section 2, "Installation and Configuration," for
instructions on how to deploy exit code to the OS 2200 QProcessor.
4.1.1. Data Conversion Exits
WMQ2200 does not change the application data carried in a WebSphere MQ
message. The Unisys default for data format is ISO standard UNICODE; the OS 2200
QProcessor uses the default codeset ISO8859-1 - CCSID(819) - at installation time.
3843 3744–002 4–1

Exits
Any data conversion that is needed can be done using a data conversion exit. (This
does not include network-to-host and related integer conversions, which must be
handled by the applications using the routines described in Appendix A.) A data
conversion exit is a user-written exit that receives control during the processing of an
MQGET call. When writing applications that span multiple platforms you must consider
application data conversion, format names, and user exits. When different platforms
are being used, you might have to convert data sent by one application with an initial
character set and encoding corresponding to its platform to the character set and the
encoding required by the receiving application on the other platform. Data can be
converted at the sending queue manager, or at the receiving queue manager.
The exit is invoked if all of the following are true:
• The MQGMO_CONVERT option is specified on the MQGET call.
• The CodedCharSetId or encoding fields in the MQMD structure associated with
the message on the queue differ from the CodedCharSetId or encoding fields in
the MQMD structure specified on the MQGET call (Refer to the language support
tables in the IBM WebSphere MQ Intercommunication manual).
• The format field in the MQMD structure associated with the message is not
MQFMT_NONE (MQFMT_STRING shows that the message consists entirely of
character data).
Refer to the IBM document WebSphere MQ Application Programming Reference for
information on other conditions. The particular exit to be called is defined in the
format field of the MQMD structure associated with the message; it is called during
MQGET processing when conversion of data is necessary. This field is only
eight-characters long. The location of data conversion exits is defined in the .ini file for
each queue manager (qm.ini) by the ExitsDefaultPath64 setting and defaults to
/var/mqm/exits64.
For data conversion exits, the actual entry point name called at runtime is a
concatenation of the format field in the MQMD structure and the “_r” suffix. This
differs from other exit types whereby the entry point MQStart must be defined as the
entry point of the exit.
4.1.2. Channel Exits
Channel exits get control while processing network messages. Refer to the IBM
document WebSphere MQ Intercommunication for more information on channel
exits.
To specify channel exits for channels, use the runmqsc command on the desired
CHANNEL definition. The exits available for definition are SCYEXIT, MSGEXIT, MREXIT,
SENDEXIT, and RCVEXIT. Since these parameters require a path name similar to the
data conversion exits, the file path where the exit resides is used in the same way as
the ExitsDefaultPath64 in the qm.ini file of the queue manager.
4–2 3843 3744–002

Example
Exits
This example shows the definition for a security exit using the runmqsc command. It
defines where the exit resides on the OS 2200 QProcessor along with the entry point
to call when a request to call an exit is received (SECEXIT). The file name and exit entry
point within the inner parentheses are both case-sensitive.
ALTER CHANNEL(MYCHANNEL) +
CHLTYPE(SDR) +
SCYEXIT(/var/mqm/exits64/myexit(SecurityFunction)')
4.1.3. Creating and Using Exits
Develop Code
Develop code corresponding to the type of exit you are creating. For a description of
the parameters that are passed to the data conversion exit and for detailed usage
notes, refer to the MQDATACONVEXIT call and the MQDXP structure in the IBM
WebSphere MQ Application Programming Reference. For a description of the
parameters that are passed to a channel exit and for detailed usage notes, refer to the
IBM WebSphere MQ Intercommunication manual.
Data Conversion Exits
For data conversion exits, use the crtmqcvx program to generate code fragments to
be used within the exit to aid in the data conversion. Refer to the IBM document
WebSphere System Administration for a detailed description on how to use the
crtmqcvx program. Refer to the IBM WebSphere Application Programming Guide for
information on how to build a data conversion exit.
The crtmqcvx Program
The crtmqcvx program produces code that uses macros defined in the amqsvmha/h
header. These macros assume that the structure used as input is packed (all the bytes
within the data structure are used). If a structure is unpacked, there are transparent
filler bytes within the structure that are generated because all 2-byte short integers
must start on a half word boundary and all 4-byte integers must start on a word
boundary. For example, the declaration of a 1-byte character followed by a declaration
of an integer would produce three filler bytes between the character declaration and
the integer declaration.
Since the macros are defined in a header file, you can easily modify this header so that
the macros skip the unused bytes within the structures if the structures are unpacked.
Calling the network-to-host functions for integer data, described in Appendix A is
currently unsupported.
3843 3744–002 4–3

Triggers
The data conversion exits get control when the CodedCharSetId or Encoding fields in
the MQMD structure of the message on the queue differ from the CodedCharSetId or
Encoding fields in the MQMD structure, specified on an MQGET call. Since the
crtmqcvx program takes input and produces output using a file on the OS 2200
QProcessor, you must copy your input code to the OS 2200 QProcessor before
running the crtmqcvx program. You can use the mqimport utility in UNX to copy your
OS 2200 input file to the /var/mqm file structure on the OS 2200 QProcessor. You can
use mqexport to copy the output source back to the OS 2200 after running the
crtmqcvx program.
Building the Exit
To build the exit code, use the buildexit utility in the UNX shell. Refer to Section 2,
"Installation and Configuration," for more information on building and deploying the
exit.
Call the Exit
Initiate a sequence of events to call the exit. The data conversion exits are called if the
appropriate conditions as defined in the IBM document WebSphere MQ Application
Programming Guide exists for the message. The particular exit that gets control if the
conditions exist is defined in the Format field of the MQMD structure associated with
the message being received through MQGET. For channel exits, once they are
configured for a channel using the runmqsc command, they start being called once the
channel is started using the runmqchl control command or the runmqsc START
CHANNEL command. For data conversion exits, the process calling MQGET calls the
exit. In the event that a channel exit aborts, it might be necessary to use the runmqsc
command to stop and start the channels being used.
4.2. Triggers
A trigger event causes an MQSeries trigger message to be generated by the queue
manager and sent to an initiation queue. Most commonly a trigger event is created by
putting a message to a local queue that has triggering defined for it.
A trigger monitor application monitors the initiation queue and processes messages
on that queue.
There are two types of trigger monitor programs: the default trigger monitor and a
user-written trigger monitor. The default trigger monitor runs on the OS 2200
QProcessor and cannot be modified. The user-written trigger monitor runs on the
OS 2200 as a batch program and can be customized.
Both trigger monitors can trigger (start or schedule) OS 2200 Open DTP servers, batch
programs, or TIP transactions.
The OS 2200 UNX demand processor ps command identifies the default trigger
monitor by the name amqtrgmn. It identifies the user-written trigger monitor by the
name you supply in the batch start stream of the monitor.
4–4 3843 3744–002

Triggers
WMQ2200 provides a sample trigger monitor executable (amqstrg0) and source code
(amqstrg0/c) for the user-written trigger monitor in the wmq$*mqs$samples file. You
can update this code to perform any actions you wish when messages arrive on the
initiation queue. There is an example build stream for the user trigger monitor in
element amqstrg0/make.
The default trigger monitor and the sample user trigger monitor are released to access
Mode A installation of Open DTP (OTM$).
If you require an alternate Open DTP installation for the default trigger monitor, rebuild
WMQ2200 to access the desired installation of Open DTP. If you want the default
trigger monitor to schedule TIP programs, set the MQS$CONFIG.MQSERIES/CONFIG
element configuration tag, McbEntryBdi, to the MCBBNK CBD address for the desired
application group.
If you require an alternate Open DTP installation or application group for the
user-defined trigger monitor, update element amqstrg0/make to rebuild the
user-defined trigger monitor so that it calls the alternate Open DTP installation and
application group.
4.2.1. Configuring a Local Queue for Triggering
The runmqsc definition statements required to configure triggering are the DEFINE
QLOCAL and the DEFINE PROCESS statements.
DEFINE QLOCAL statement is required for both the local queue that causes the queue
manager to trigger an event to the initiation queue when a message arrives and for
the initiation queue where the trigger monitor waits to start programs.
For the local queue that is to be triggered, you must provide the following fields in
your runmqsc definition:
• INITQ (supply the name of the initiation queue)
• keyword TRIGGER (to enable the triggering event)
• PROCESS (to identify which program is to be started by the trigger monitor)
The following are examples of initiation queue and associated local queue definitions
that causes a batch job to start when a message is put to queue Q2.
DEFINE QL(INITQ.2200BATCH)
DEFINE QL(Q2) INITQ(INITQ.2200BATCH) TRIGGER +
PROCESS(2200BATCH) TRIGTYPE(FIRST)
The use of the default trigger monitor or a user-written trigger monitor is determined
by the presence of a PROCESS statement on the DEFINE QLOCAL for the initiation
queue. The following guidelines help you determine which trigger monitor to use.
3843 3744–002 4–5

Triggers
• No PROCESS name on the DEFINE QLOCAL definition of an initiation queue
indicates that you are using a default trigger monitor (runs on the OS 2200
QProcessor and is not modifiable by you).
• The specification of a PROCESS name on the DEFINE QLOCAL definition for an
initiation queue indicates that you are using a user-written trigger monitor that
runs on the OS 2200 as a batch program.
Using the preceding guidelines, you can observe that in the previous example the
initiation queue INITQ.2200BATCH is defined to use the default trigger monitor.
The following is an example of an initiation queue definition that uses a user-written
trigger monitor with a PROCESS field.
DEFINE QL(INITQ.2200) PROCESS(UTRM)
Defining Processes
A PROCESS definition is used to
• Describe the program to be started for a triggered queue, or
• Provide the information to start an OS 2200 batch user trigger monitor.
PROCESS Definition for a Triggered Queue
One PROCESS definition is always required on the DEFINE QLOCAL of the triggered
local queue to identify the OS 2200 program to be started or triggered when a
message arrives. For example, the following triggered local queue definition specifies
that PROCESS (2200TIP) be used to determine which program to start when a
message is input.
DEFINE QL(Q5) DEFPSIST(yes) INITQ(INITQ.2200TIP) +
TRIGGER PROCESS(2200TIP) TIGTYPE(FIRST)
The PROCESS definition for 2200TIP shows which program type and program name is
to be started. The specification of the APPLTYPE field on the PROCESS definition
determines the type of program to be activated. The APPLICID field contains either the
name of the program or a batch start stream if the type is BATCH. For example, the
following PROCESS definition indicates the program type to be triggered is TIP and the
transaction program name (code) is TRGTIP.
DEFINE PROCESS(2200TIP) DESCR('schedule TIP program') +
APPLTYPE(TIP) APPLICID('TRGTIP')
The specification of the APPLTYPE and APPLICID fields on a DEFINE PROCESS
command determines the program to be activated as described in the following table.
1. Set the APPLTYPE field of the PROCESS definition to OLTP, OLTPS, BATCH, or TIP,
depending on how the service is to be activated.
4–6 3843 3744–002

Triggers
2. Set the APPLCID field for the PROCESS definition to a TIP transaction code, an
OLTP service name, or for the case of a batch program, to the location of the start
stream.
3. When using Open DTP, you must configure the service name in the Open
Distributed Transaction Processing TMSCONFIG file. Refer to the Open
Distributed Transaction Processing Administration Guide Volume 1 for
information on how to configure an Open Distributed Transaction Processing
service.
If the APPLTYPE
field is set to …
The trigger monitor …
BATCH Constructs a start image using the APPLICID field from the
PROCESS definition and issues the image to activate the process
(that is, the batch application). The format of the APPLICID field is
APPLICID('qual*file.elt/vers[,run-id]')
where
qual*file.elt/vers specifies the location of the batch application
executable.
setc specifies an optional octal number (not exceeding 4 digits in
length) to be placed in the middle third of the condition word for
the batch application’s run.
run-id optionally overrides the run-id specified in the started
runstream.
Note: qual*file.elt/vers,setc,run-id are equivalent to the first
three parameters on an OS 2200 @START statement.
To set up a single runstream to handle multiple queues, use the
setc and run-id fields of the start image. There is no method of
passing trigger information to this kind of application, but it is
useful for activating one-time events.
OLTP Makes an asynchronous call to the configured service using the
XATMI function tpacall with the TPNOREPLY flag set. Since no
reply is expected, the trigger monitor checks the initiation queue
and makes calls to start additional processes while the first
service is executing.
The APPLICID field contains the name of the OLTP service in
single quotes.
APPLICID('service-name')
Note: The released product builds the default and user trigger
monitors to access the default OTM$ Open DTP installation. If
you want your default trigger monitor to access an alternate
Open DTP installation, you must build an alternate installation
of WMQ2200 for that Open DTP installation. If you want your
user trigger monitor to access an alternate Open DTP
installation, you must update and add the AMQSTRG0/MAKE
add stream in the wmq$*mqs$samples file for that Open DTP
installation.
3843 3744–002 4–7

Triggers
If the APPLTYPE
field is set to …
The trigger monitor …
OLTPS Makes a synchronous call to the configured service using the
XATMI function tpcall with the flag TPNOTIME set. This causes
the trigger monitor to wait for the called XATMI service to
complete its processing before looking at the initiation queue for
additional trigger messages. After making the appropriate call,
the trigger monitor continues checking and processing additional
trigger messages.
The APPLICID field contains the name of the OLTP service in
single quotes.
APPLICID('service-name')
Using the OLTPS setting limits the number of triggered services
that can be active to the number of trigger monitors active;
however, you can also control the number of copies of the
triggered service using the CONCURRENCY configuration
parameter in the *SERVERS section of the TMSCONFIG file within
Open Distributed Transaction Processing.
Refer to the Open Distributed Transaction Processing
Administration Guide Volume 1 for information on how to set
the CONCURRENCY parameter for an Open Distributed
Transaction Processing server. Refer to the Open Distributed
Transaction Processing XATMI Application Interface
Programming Guide for more information on Open Distributed
Transaction Processing application development.
Note: The released product builds the default and user trigger
monitors to access the default OTM$ Open DTP installation. If
you want your default trigger monitor to access an alternate
Open DTP installation, you must build an alternate installation
of WMQ2200 for that Open DTP installation. If you want your
user trigger monitor to access an alternate Open DTP
installation, you must update and add the AMQSTRG0/MAKE
add stream in the wmq$*mqs$samples file for that Open DTP
installation.
TIP Makes a connection to the MCB and passes the MQTMC2 data
structure to the transaction named in APPLICID as input data.
Note: The McbEntryBdi configuration tag in your
MQS$CONFIG.mqseries/config element must be set to the
installed MCBBNK BDI to select the application group for
scheduling transactions by the default trigger monitor. The
form of the configuration tag should be 040nnnn. The MCB
must have UDBASE set to 0600000 or higher. If you are using a
user-written trigger monitor, update and add the
AMQSTRG0/MAKE add stream in the wmq$*mqs$samples file
to access the desired MCB application group.
4–8 3843 3744–002

PROCESS Definition for a User-written Trigger Monitor
Triggers
A user trigger monitor is indicated by a PROCESS field on the initiation queue
definition. The PROCESS definition for the user trigger monitor must specify
APPLTYPE(BATCH) and an APPLICID containing the OS 2200 file name and element of
the start stream for the monitor that you have compiled and linked.
DEFINE QL(INITQ.2200) DEFPSIST(yes) PROCESS(UTRM)
DEFINE PROCESS(UTRM) DESCR('user trm process') +
APPLTYPE(BATCH) APPLICID('MYFILE*WMQTRM.UTRM/RUN,,UTRM')
4.2.2. Creating a User-Defined Trigger Monitor
If the default trigger monitor program included with WMQ2200 does not meet your
requirements, perform the following steps to define your own trigger monitor
application:
1. Within the WMQ$*MQS$SAMPLES file, modify the sample source code element
AMQSTRG0/C to allow your trigger monitor to perform additional processing. A
new requirement for WMQ2200 user trigger monitors is that the MQGET must
have the MQGMO_CONVERT option set. This is because the MQGET is being done
from the OS 2200 to the OS 2200 QProcessor, and conversion needs to be done
across platforms.
2. After making the local modifications to the user trigger monitor program code,
update the build stream in WMQ$*MQS$SAMPLES.AMQSTRG0/MAKE if you want
to use a different application group to schedule TIP transactions or a different
Open DTP installation to start servers. Compile and link this program with this
build stream.
3. After compiling and linking the user-defined trigger monitor program, create a
runstream in a program file element that executes the program.
Example
@RUN UTRM,,
@DELETE,C TRMPR.
@CAT,P TRMPR.
@BRKPT PRINT$/TRMPR
@WMQ$*MQS$SAMPLES.AMQSTRG
@BRKPT PRINT$
@EOF
4. The file and element name for this runstream must be supplied in the APPLICID
field of the PROCESS definition for the user trigger monitor. The format of the
DEFINE PROCESS command for this scenario is as follows:
DEFINE PROCESS(process-name) DESCR(string)
APPLTYPE(BATCH) APPLICID('qual*file.elt/vers[,,run-id]')
3843 3744–002 4–9

Triggers
where:
process-name is the name of the MQSeries PROCESS definition supplied on the
initiation queue’s DEFINE QLOCAL definition.
string is a plain-text comment describing this PROCESS definition.
qual*file.elt/vers specifies the location of the batch trigger monitor executable.
run-id optionally overrides the run-id specified in the started runstream.
Notes:
• qual*file.elt/vers,,run-id are equivalent to the first three parameters on an
OS 2200 @START statement.
• If you wish to re-use a MQS2200 user-written trigger monitor, you must add
the MQGMO_CONVERT option to the MQGET call since the initiation queue
now resides on the Specialty Processor. Recompile and re-link the user
trigger monitor before starting it.
• The WMQ2200 subsystem performs the @START of the user-written trigger
monitor runstream and the WMQ2200 subsystem user ID is mapped to the
root user ID on the OS 2200 QProcessor. Therefore, the root user on the
OS 2200 QProcessor must be a member of the mqm group if the queue
manager that the trigger monitor uses has the OAM component enabled.
You can do this with the rootmod –a command in the UNX shell.
4.2.3. Trigger Monitor Processing
When a message is put on a queue that is configured for triggering, the queue
manager places a trigger message on the initiation queue associated with the queue.
The default or user-defined trigger monitor programs loop in MQGET on the initiation
queue, waiting to receive the trigger messages. Normally, the trigger monitor starts a
program to process the queued message. Refer to the IBM MQSeries Application
Programming Guide for more information on triggering.
The trigger monitor passes the trigger message and the information in it to the
application it starts in an MQSeries MQTMC2 data structure. Refer to the MQSeries
Application Programming Reference for more information on the MQTMC2 format.
Note: If the triggered application is an OS 2200 batch program, the MQTMC2 is not
provided to the batch program. If you want the batch program to have that
information, you might need to enhance a user trigger monitor program to place the
trigger message on an MQSeries queue from which the triggered batch program can
retrieve the trigger information.
The default trigger monitor program relies on the WMQ2200 subsystem to perform
the MCB transaction scheduling functions and the Open DTP TP API calls. You must
set the McbEntryBdi MQS$CONFIG.mqseries/config configuration tag to the installed
MCBBNK BDI for which you wish to schedule transactions.
4–10 3843 3744–002

Triggers
The released WMQ2200 subsystem installation is built to call servers with the default
OTM$ Open DTP. You need to rebuild and install an alternate version of the WMQ2200
product, if you are planning to use default trigger monitors and require an alternate
Open DTP installation.
The user-defined trigger monitor program does not rely on the WMQ2200 subsystem
to perform MCB transaction scheduling functions or the Open DTP TP API calls. The
scheduling of TIP transactions and TP API calls are done by the user trigger monitor
program itself. The released sample trigger monitor is built to schedule transactions
with the MCBBNK BDI 0402277 and to invoke servers in the default OTM$ Open DTP
installation. If you are planning to employ user trigger monitors and you require an
alternate application group or Open DTP installation, you must update and add the
amqstrg0/make element in file wmq$*mqs$samples to make a new executable zoom.
4.2.4. Configuration Examples
The following example shows some definitions using runmqsc commands to
configure trigger services. These examples define local queues, initiation queues, and
processes.
The local queues Q1A to Q1D are connected to the initiation queue INITQ1, which is
using a default trigger monitor. The local queues Q2A to Q2D are connected to the
initiation queue INITQ2, which is using a user-defined trigger monitor identified by
PROCESS (QMON2).
The PROCESS field on the DEFINE QLOCAL command for INITQ2 specifies that a
user-defined trigger monitor will be started.
Define the initiation queues.
DEFINE QLOCAL(INITQ1) DEFPSIST(YES)
DEFINE QLOCAL(INITQ2) DEFPSIST(YES) PROCESS(QMON2)
Define local queues for triggering. Associate them with an initiation queue and the
program to start when a message arrives.
DEFINE QLOCAL(Q1A) DEFPSIST(YES) INITQ(INITQ1) TRIGGER PROCESS(TRIG1)
DEFINE QLOCAL(Q1B) DEFPSIST(YES) INITQ(INITQ1) TRIGGER PROCESS(TRIG2)
DEFINE QLOCAL(Q1C) DEFPSIST(YES) INITQ(INITQ1) TRIGGER PROCESS(TRIG3)
DEFINE QLOCAL(Q1D) DEFPSIST(YES) INITQ(INITQ1) TRIGGER PROCESS(TRIG4)
DEFINE QLOCAL(Q2A) DEFPSIST(YES) INITQ(INITQ2) TRIGGER PROCESS(TRIG1)
DEFINE QLOCAL(Q2B) DEFPSIST(YES) INITQ(INITQ2) TRIGGER PROCESS(TRIG2)
DEFINE QLOCAL(Q2C) DEFPSIST(YES) INITQ(INITQ2) TRIGGER PROCESS(TRIG3)
DEFINE QLOCAL(Q2D) DEFPSIST(YES) INITQ(INITQ2) TRIGGER PROCESS(TRIG4)
Define the programs to be started or triggered.
DEFINE PROCESS(TRIG1) DESCR('Triggered OLTP tpacall service') +
APPLTYPE(OLTP) APPLICID('Service1')
DEFINE PROCESS(TRIG2) DESCR('Triggered OLTP tpcall service') +
APPLTYPE(OLTPS) APPLICID('Service2')
3843 3744–002 4–11

Triggers
DEFINE PROCESS(TRIG3) DESCR('Triggered batch application') +
APPLTYPE(BATCH) APPLICID('my*batchapps.trig3/run')
DEFINE PROCESS(TRIG4) DESCR('Triggered TIP service') +
APPLTYPE(TIP) APPLICID('tipsvc')
Define the user trigger monitor program.
DEFINE PROCESS(QMON2) DESCR('User-defined batch trigger monitor') +
APPLTYPE(BATCH) APPLICID('trigger*trigfile.samptrig/run,,STRGR')
The following runstream, samptrig/run, references the sample user-defined trigger
monitor executable provided in the WMQ$*MQS$SAMPLES file, amqstrg0. The
sample source code requests the initiation queue name and the queue manager name
at execution time. The example queue manager name is QM1.
@RUN STRGR,,PROJID
@DELETE,C TRIGPR.
@CAT,P TRIGPR.
@BRKPT PRINT$/TRIGPR
@TRIGGER*TRIGFILE.AMQSTRG
INITQ2 QM1
@BRKPT PRINT$
@EOF
4.2.5. Starting the Trigger Monitors
Use the OS 2200 UNX demand processor runmqtrm command to start your trigger
monitors. The format is the same for either the default trigger monitor or a
user-written trigger monitor.
runmqtrm -m -q
You can start the default trigger monitor with the following command in the UNX
demand processor:
runmqtrm -m QM1 -q INITQ1
Similarly, you can start the user-defined trigger monitor with the following command
in the UNX demand processor:
runmqtrm -m QM1 -q INITQ2
4.2.6. Terminating a Trigger Monitor
There are two ways to terminate a trigger monitor:
• End the queue manager
• Disable initiation queue get
If you end the queue manager with the UNX demand processor endmqm command, all
trigger monitors active for that queue manager terminate automatically.
4–12 3843 3744–002

Using Binary Data in the Message Area
To terminate a single trigger monitor, disable the get capability of the initiation queue
after starting runmqsc under the UNX demand processor, as follows:
alter qlocal(INITQ1) get(DISABLED)
Note: The WMQ2200 daemon will not shutdown if any default trigger monitors are
triggering OS 2200 programs. This is because they are still attached to and using the
connection that the daemon established between the OS 2200 and the OS 2200
QProcessor. You must stop all active default trigger monitors before stopping the
WMQ2200 daemon.
4.3. Using Binary Data in the Message Area
4.3.1. The OS2200 Architecture
The OS 2200 environment is a 36-bit, one’s-complement, big-endian architecture with
four 9-bit bytes in every 36-bit word. When data is transferred over a TCP/IP network
connection from the OS 2200 environment, the data is reformatted from 36 bits to 32
bits. This reformatting is accomplished by sending the lower 8 bits of every 9-bit byte
and ignoring the ninth bit. When data is received from the network, the OS 2200
system receives a stream of 8-bit bytes. These 8-bit bytes are stored into the 9-bit
bytes and the ninth bit of every byte is ignored.
4.3.2. The OS 2200 QProcessor Architecture
The OS 2200 QProcessor environment that the queue managers run on natively is a
64-bit two’s complement, little endian architecture with eight 8-bit bytes in every
64-bit word.
4.3.3. Data Transmission and Conversion Challenges
When transmitting data between the OS 2200 system and the OS 2200 QProcessor,
there are two challenges that must be overcome. First, as described above, the
OS 2200 system uses 9-bits per byte while the OS 2200 QProcessor uses 8-bits per
byte. This must be accounted for when data is sent or received between the two
platforms. All multi-byte data must be adjusted to account for these architectural
differences so that when the data arrives on the other system the data is represented
correctly. Second, since the OS 2200 is a big-endian byte ordering architecture and the
OS 2200 QProcessor is a little-endian byte ordering architecture, multi-byte data (for
example shorts, integers, and longs) are represented differently on each platform and
must be converted so that they are represented properly on the given system. This
conversion is called byte swapping.
3843 3744–002 4–13

Using Binary Data in the Message Area
4.3.4. WebSphere MQ Encodings
WebSphere MQ uses the terminology “encoding” to refer to the endianness (or byte
ordering) of multi-byte data. WebSphere MQ requires that multi-byte data passed as
parameters on MQ API calls in a server environment always be in the local encoding
(or endianness) of the queue manager. This means that a queue manager running on
little-endian architecture requires parameters passed in MQ API calls to be in
little-endian byte ordering. Since the OS 2200 applications are running on big-endian
architecture, this must be accounted for. The WMQ2200 subsystem compensates for
this by performing the necessary conversion before and after the MQ API calls so that
all parameters are presented to the queue manager in little-endian byte ordering and
are returned to the OS 2200 application in its native big-endian byte ordering. This is
completely transparent to the OS 2200 application and WebSphere MQ queue
managers. Message data on the other hand can be in any byte ordering (and
sometimes is a mix of byte orderings) subject to specific limitations. This means it is
valid for an application to put messages containing big-endian data to a queue
manager on a little-endian byte ordering architecture or vice versa. It is also valid to
put messages with data containing both byte-orderings to a queue manager, subject
to specific rules and limitations. In the case of message data, this might be transparent
to the user application.
4.3.5. Message Formats: Built-In versus User-Defined
Message data can be composed of built-in or user-defined message data or a
combination of both. Built-in message formats are those which are defined by
WebSphere MQ. These include structures defined by WebSphere MQ that can be
included in message data. Examples include the MQRFH (Reference Header), MQMDE
(Message Descriptor Extension), as well as many others. WebSphere MQ is
responsible for conversion of built-in message formats since it knows the structure of
these formats. User-defined formats are defined as message formats that the user
application defines. These formats are unknown to WebSphere MQ and therefore
cannot be converted by WebSphere MQ natively. It is up to the user application or a
user-written exit to convert this data if necessary.
4.3.6. Built-In Message Format Conversion
When user applications put or retrieve messages containing built-in message formats,
WebSphere MQ is responsible for all conversions of data. The WMQ2200 subsystem
and queue manager perform all necessary conversion to transfer messages containing
built-in message formats between architectures successfully. Transferring built-in
message formats in message data in any encoding (or endianness) is fully supported
in both directions. This means you can put or get messages containing big or little
endian built-in format data. This is generally transparent to the OS 2200 user
application. However, see the sections regarding the MQMDE and MQGMO_CONVERT
option for important considerations when developing applications in a WMQ2200
environment.
4–14 3843 3744–002

4.3.7. Special MQMDE Considerations
Using Binary Data in the Message Area
In almost all cases, a queue manager accepts messages containing built-in message
format data in any encoding. However, there are very specific situations where this is
not always true. The use of MQMDE presents just such a case. The MQMDE allows a
user application that uses a V1 MQMD a way to provide extra V2 MQMD data to the
queue manager. To do this, the application must pass the MQMDE data at the
beginning of the message data. If the MQMDE is honored by the queue manager, the
MQMDE data is combined with the V1 MQMD passed on the MQPUT/MQPUT1 call to
generate a V2 MQMD that is included with the message when it is retrieved with an
MQGET later. However, for the MQMDE to be recognized by the queue manager
special requirements must be satisfied. Refer to the IBM WebSphere MQ Application
Programming Reference manual for details on the requirements. The requirement
that is most important to note in a WMQ2200 environment is that the MQMDE
provided in the user message must be in the queue manager’s local encoding. Since
the OS 2200 application is running in a big-endian environment, and the queue
manager is running in a little-endian environment, this requirement is not satisfied by
default. To overcome this, WMQ2200 provides mechanisms, both manual and
automatic, that user applications can use to convert MQMDE in message data into a
format that the queue manager on the OS 2200 QProcessor will honor. First, the
ConvertMQMDE configuration tag is provided in the WMQ2200 subsystem. If enabled,
the subsystem automatically converts MQMDE data in user messages to the queue
manager’s local encoding when messages are put and converts MQMDE data back to
the OS 2200 encoding if present in the user message when retrieved. This allows for
legacy application support. Refer to Section 2, "Installation and Configuration," for more
information on the ConvertMQMDE tag. The second option for user applications to
convert MQMDE in message data to and from the queue manager’s local encoding is
to use macros provided by WMQ2200. These macros are only available for C
application development. The macros are provided in cmqc.h and are named
PREP_MQMDE_FOR_PUT and PREP_MQMDE_AFTER_GET. For more information, see
the cmqc.h file in the MQS$LIB file. In both cases, the following rules must be
followed:
• The MQMDE must be at the beginning of the message buffer
• The MQMD.Format must be MQFMT_MD_EXTENSION
• The message must be long enough to contain an MQMDE structure.
Note that for the queue manager to honor the MQMDE, it must meet all other rules
set forth by WebSphere MQ as documented in the IBM WebSphere MQ Application
Programming Reference manual. If the MQMDE is not honored, the message is still
accepted, but the MQMDE remains in the message data and is not used by the queue
manager. Instead, it is treated as ordinary message data.
3843 3744–002 4–15

Using Binary Data in the Message Area
4.3.8. Special MQGMO_CONVERT Considerations
The MQGMO_CONVERT option used on the MQGET call is used to request that the
queue manager attempt to convert message data to the requested encoding (byte
ordering) and character set before the message is returned. If the message data
contains built-in message formats, WMQ2200 performs conversion transparently.
Certain legacy OS 2200 applications that retrieve messages containing built-in
message formats are most affected by the use or non-use of the MQGMO_CONVERT
option. If the MQGMO_CONVERT option is not used, the message is returned to the
user in the encoding and character set it was originally put in. Legacy OS 2200
applications that primarily retrieve messages that are generated by the queue
manager that do not use the MQGMO_CONVERT option on the MQGET malfunctions
in a WMQ2200 environment. The reason is that the queue manager is now running on
a different architecture encoding than the OS 2200 application. This means that the
queue manager generates little-endian byte ordered messages. If a user application
does not perform an MQGET with the MQGMO_CONVERT option, messages originally
generated by the queue manager is returned in the wrong encoding for the OS 2200.
Applications that might retrieve messages that include built-in message formats,
particularly messages generated by the queue manager, must use the
MQGMO_CONVERT option when performing an MQGET to ensure that the message
data is returned in the native OS 2200 format. In addition, the MQMD.Encoding must
be reset to MQENC_NATIVE before each MQGET call to ensure that the queue
manager is instructed to convert the built-in message data to big-endian format before
returning each message. The applications most likely to encounter this problem are
trigger monitors, dead letter queue monitors, event monitors, and other applications
that primarily retrieve messages generated by queue managers.
4.3.9. Chained Message Headers
WMQ2200 supports messages containing chains of WebSphere MQ headers. This is
known as chained message headers. A chained message is one in which the message
data contains multiple built-in message formats, one after the other contiguously and
ending at some point. For example, a message could contain an MQMDE, followed by
an MQRFH, followed by a MQCFH (PCF) header. Messages with chains can also
contain user-defined message data, but it must be at the end of the message. To
construct a chain of message headers, you must use the MQMD in the MQPUT or
MQPUT1 call to specify the format and encoding of the first header in the message.
Next, you use the Format and Encoding fields of each header in the message to
specify the format and encoding of the next header in the message. It is valid, but
uncommon, to have a mix of big and little endian data in a message chain. The entire
contents of each header must be in the same encoding, but each header can use a
different encoding if required. This is fully supported by WMQ2200 subject to
WebSphere MQ rules as documented in the IBM WebSphere MQ Application
Programming Reference manual.
4–16 3843 3744–002

Compiling and Linking WMQ2200 Application Programs
4.3.10. User-Defined Message Format Conversion
When user applications put or retrieve messages containing user-defined message
formats, WebSphere MQ is not responsible for conversion of the data. This is because
the format is unknown to WebSphere MQ, so the queue manager does not know how
to convert the data. The user application or an exit is responsible for message
conversion. Message data must be converted by user applications before sending and
after receipt to ensure the message data is transferred correctly. It is not necessary
for the message data to be converted to the queue manager’s local encoding. The
message data can be put in the OS 2200 local encoding (big endian). The queue
manager returns user-defined message data in its original encoding when the
message is retrieved. However, the user application must still account for the 8-bit to
9-bit differences so that message data is transferred without corruption. If message
data contains no multi-byte data, no conversion is necessary. However, if multi-byte
data is included in the message, it must be converted before the MQPUT or MQPUT1
and after the MQGET to compensate for the 8 to 9 bit differences. To assist the user
application in compensating for this reformatting, MQS2200 supplies libraries and a C
header file. See Appendix A, "Data Formatting between Multiple Platforms," for more
details.
4.3.11. User Application Development Recommendations
When developing applications for WMQ2200, use the following recommendations to
ensure conversion is handled appropriately:
• Use the MQGMO_CONVERT option on the MQGET call to ensure that the queue
manager converts the message data to the OS 2200 encoding when possible.
• Always reset the MQMD.Encoding field to MQENC_NATIVE before each MQGET
call to ensure messages are returned in the native OS 2200 format when the
MQGMO_CONVERT option is used.
• Try to avoid using multi-byte data in user message data to avoid the complexities of
message conversion. Use byte streams or character data where possible.
4.4. Compiling and Linking WMQ2200 Application
Programs
This section includes examples of compiling, linking, and executing new C and COBOL
programs in the WMQ2200 environment. See the migration section for an explanation
of how to use your current MQS2200 application programs in the WMQ2200
environment.
Note: WMQ2200 does not provide the MQI client libraries. However, WMQ2200
accepts connections from remote MQI clients. Refer to Section 5, "MQI Client
Connections," for more information.
3843 3744–002 4–17

Compiling and Linking WMQ2200 Application Programs
4.4.1. C Programs
Use the following examples to assist you in compiling, linking, and executing C
programs.
Compile Example
@use uc$pf,wmq$*mqs$lib
@uc,s myqual*myfile.myprog,.myprog/om
@eof
Link Example
@link,se ,myqual*myfile.myprog
include myqual*myfile.myprog/om
include wmq$*mqs$lib.mqs$entry
resolve all references using local_defs, sys$lib$*emomrts, lcn
process for extended
output zoom
@eof
Execution Example
Run this program using the following command:
@myqual*myfile.myprog
Building a Batch Open DTP MQI Server Program
The following information shows how to build an Open DTP batch server that
incorporates a messaging service routine.
1. Compile your service routine(s). All MQI application programs require the inclusion
of the MQSeries header file cmqc.h to define the function prototypes and
definitions used by the MQI calls. This header is found in the *mqs$lib file.
@use uc$pf.,otm$*tm$lib.
@use uc$pf1.,wmq$*mqs$lib.
@uc,e my*workfile.putsvc/c,my*workfile.putsvc/o
2. Call the Open DTP MAS processor supplying the make-form parameters. Refer to
the Open DTP Administration Guide, Volume 2 for exact details.
@otm$*tm$util.mas,nc ,my*workfile.makeserver/putsvrbat,putsvrbat,wmq$
*PARAMETERS
*FILES
AP my*workfile
XQT my*workfile
*ROUTINES
0 putsvc - - putsvc/o
@eof
4–18 3843 3744–002

Compiling and Linking WMQ2200 Application Programs
3. Edit the generated MAKESERVER addstream to insert this additional include
directive in the link of the batch server.
include wmq$*mqs$lib.mqs$entry
The updated MAKESERVER link stream is as follows:.
@link,le ,workfile.putsvrbat
include tm$util.server$main/o
include tlib$.ap$name/o
include tlib$.sreptable/o
include local$.tpsvrinit/o
include local$.tpsvrdone/o
include ap$.putsvc/o
include wmq$*mqs$lib.mqs$entry
resolve all references using tm$lib, rts$, lcn
process for extended
delete all definitions except start$
@eof
Add the MAKESERVER addstream to create the batch server.
Building a Batch Open DTP 2PC MQI Client Program
The following procedure shows how to build an Open DTP client application that uses
both the TX API and the MQSeries API (MQI).
1. Compile the client code.
@use uc$pf.,otm$*tm$lib.
@use uc$pf1.,wmq$*mqs$lib.
@uc,e workfile.mqapp/c,workfile.mqapp/o
@masm,e workfile.ap$name/msm-mqapp,.ap$name/mqapp
@eof
2. Link the client application.
@use tm$lib.,otm$*tm$lib.
@use rts$.,sys$lib$*emomrts.
@ .
@link,le , workfile.mqapp
include workfile.mqapp/o
include workfile.ap$name/mqapp
include wmq$*mqs$lib.mqs$entry
resolve all references using tm$lib, rts$, libcodename
delete all definitions except start$
process for extended
@eof
3843 3744–002 4–19

Sticking Transactions
4.4.2. COBOL Programs
Use the following examples to assist you in compiling, linking, and executing COBOL
application programs.
Compile Example
@use cob$pf,wmq$*mqs$lib.
@ucob,s myqual*myfile.myprog,my-om.myprog/o
Link Example
@link,s ,my-exe.myprog
disallow unresolved references
include my-om.myprog/o
include wmq$*mqs$lib.cbl$entry
output zoom
process for extended
resolve all references using lcn
@EOF
Execution Example
The @XQT execution method is required for running your program and the sample
programs on the MQSeries release tape. If @XQT is not done, the input from the
terminal does not work correctly.
Correct
@XQT MY-EXE.MYPROG
Incorrect
@MY-EXE.MYPROG
4.5. Sticking Transactions
Your MQS2200 sticking transaction programs continue to stick without relinking in the
new WMQ2200 environment if you have installed WMQ2200 at the default or same
BDIs as the original MQS2200. However, they process slower because of the interface
transition required to operate in the new environment. It is recommended that you
relink your MQS2200 sticking transaction programs with the new environment to take
advantage of improved processing speed.
With MQS2200, there was a need to include the special object module mqs$entryst in
your sticking transaction link. With WMQ2200 the special object module is no longer
necessary. You include object modules mqs$entry (for C programs) or cbl$entry (for
COBOL programs) in your sticking transaction program links as you would for a
non-sticking TIP/HVTIP, batch, or demand user application.
You still need to have the “I” option set in the STA field of your sticking transaction
valtab to indicate to the OS 2200 that your transaction should be re-used.
4–20 3843 3744–002

Sticking Transactions
The following example demonstrates how to compile and link a UC TIP sticking
transaction program for WMQ2200.
@use uc$pf.,ngo*mqs$lib.
@uc,e stick.tipput/c,.tipput/o
@ .
@use link$pf.,sys$lib$*app$9.
@use mcb$.,mcb9*mcb$.
@ .
@link,s,stick.tipput
include stick.tipput/o
include wmq$*mqs$lib.mqs$entry
resolve all references using mcb$., sys$lib$*emomrts., LCN
set size = 0720000 for urts$tables
process for extended fast load
delete all definitions except start$
@eof
There are no known restrictions or limitations with sticking TIP or HVTIP transactions
in the new WMQ2200 environment. The mqs$entry object module can be linked into
sticking HVTIP subprograms or ICP.
The ability to stick is allowed through the WMQ2200 xa_ interface. The mqs$entry
module can be included in the link for Open Distributed Transaction Processing TIP or
HVTIP programs that use the MQI and are a part of a global, 2PC transaction using
WMQ2200 as a resource manager.
3843 3744–002 4–21

Sticking Transactions
4–22 3843 3744–002

Section 5
MQI Client Connections
This section discusses WMQ2200 support of MQI client connections.
To … See subsection …
Read about client applications 5.1
Prepare WMQ2200 to accept client connections 5.2
Read about scaling considerations and limitations 5.3
Read about restrictions in MQI client support 5.4
5.1. WebSphere MQ Client Applications
A WebSphere MQ client application is an application that is linked to the WebSphere
MQ client libraries. The WebSphere MQ client libraries enable WebSphere MQ client
applications to connect to queue managers on remote machines. While WMQ2200
does not provide the WebSphere MQ client libraries on the OS 2200, it accepts
connections from WebSphere MQ client applications. This enables applications
running on remote machines to connect to WMQ2200 and interact with WMQ2200
queue managers as if they were running on OS 2200. Refer to the IBM document
WebSphere MQ Clients for more information on the WebSphere MQ client interface.
5.2. Preparing WMQ2200 to Accept Client
Connections
To enable WMQ2200 to accept client connections complete the following steps:
1. Define a Server-Connection Channel
WebSphere MQ client applications connect to queue managers through
server-connection channels. You must define a server-connection channel on your
WMQ2200 queue manager for clients to use as follows:
>runmqsc QMGR
>DEFINE CHANNEL(SVRCHANNEL) +
>1: DEFINE CHANNEL(SVRCHANNEL) +
>CHLTYPE(SVRCONN)
>CHLTYPE(SVRCONN)
>AMQ8014: WebSphere MQ channel created.
3843 3744–002 5–1

Scaling Considerations
Note: The command used is a basic channel definition. You might need to
specify additional parameters in some circumstances. Refer to the IBM
document WebSphere MQ MQSC Command Reference for more information.
2. Start a WebSphere MQ Listener Process
To start a WebSphere MQ listener process, enter the following:
runmqlsr [-m queue_manager_name] [-p port] [&]
5.3. Scaling Considerations
Several factors affect the number of concurrent client connections WMQ2200 can
support. This includes but is not limited to the following:
• The presence and value of the MaxActiveChannels attribute in the queue manager
qm.ini file.
• The presence and value of the -b (backlog) option on the listener (RUNMQLSR)
process.
5.3.1. MaxActiveChannels Attribute
The MaxActiveChannels attribute is an attribute that can be added to the queue
manager’s qm.ini configuration file. It defines the maximum number of channels that
can run at a time. Each client connection creates a new active channel. The default is
100, or the value of the MaxChannels attribute if it is defined in the queue manager’s
qm.ini configuration file. Refer to the IBM document WebSphere MQ System
Administration for more information about these attributes and how to change them.
5.3.2. Listener Backlog Option
The WebSphere MQ listener process supports an optional parameter (-b) that defines
the maximum listener backlog. The listener backlog is defined as the number of
queued incoming connections waiting for service at any given time. The default limit is
20. If you expect large number of clients to initiate connections to WMQ2200 at a
time, use this value when starting the listener process. If the maximum backlog limit is
reached, all client connections over this limit will receive a
MQRC_QMGR_NOT_AVAILABLE reason code when they attempt an MQCONN or
MQCONNX to connect to the WMQ2200 queue manager. Refer to the IBM document
WebSphere MQ Intercommunication for more information.
5–2 3843 3744–002

5.4. Restrictions
The following items relating to MQI clients are restricted by WMQ2200:
• Clients can only connect using the TCP/IP communications protocol.
Restrictions
• Client-connection (CLNTCONN) channels are not supported. Additionally, you
cannot export the MQSeries client channel definition table file (AMQCLCHL.TAB)
from MQS2200 for use on another platform. However, you can define
client-connection channels on other queue managers that point to
server-connection (SVRCONN) channels on MQS2200. Your client applications can
then use the AMQCLCHL.TAB file created by the other queue managers to point
to server-connection channels on MQS2200. Refer to the IBM document
MQSeries Clients for more information on MQCHLLIB and MQCHLTAB
environment variables.
• Clients connecting to WMQ2200 must not use versions of MQ structures greater
than the following:
MQMD - MQMD_VERSION_2
MQMDE - MQMDE_VERSION_2
MQPMO - MQPMO_VERSION_2
MQGMO - MQGMO_VERSION_3
MQOD - MQOD_VERSION_3
3843 3744–002 5–3

Restrictions
5–4 3843 3744–002

Section 6
High Availability
This section discusses the High Availability (HA) feature for WMQ2200.
To … See subsection …
Obtain information about the HA feature 6.1
Obtain information on WMQ2200 specific changes with
the HA feature
Maximize performance with queue managers managed by
the HA cluster
6.1. Introduction
The OS 2200 QProcessor provides a clustering capability for high availability known as
HA cluster. This clustering is separate and distinct from queue manager clustering,
which is an internal feature of WebSphere MQ. For more information on the OS 2200
QProcessor HA feature, refer to the ClearPath Specialty Engine for OS 2200
Configuration Guide.
6.2. WMQ2200 Specific Changes to Support HA
The WMQ2200 implementation differs from other WebSphere MQ distributions in
specific ways to support the high availability solution we offer. These include:
• The command server must be running if you wish to have trigger monitors,
brokers, or channel initiators managed by the HA cluster. The command server
starts when the queue manager is started. If the queue manager is managed by
the HA cluster, do not stop the command server manually while the queue
manager is running. If you stop the command server, the cluster restarts the
command server automatically.
• The HA software creates a hidden file named .ha in the directory of the queue
manager when it is added to the cluster. This file is removed when the queue
manager is removed from the cluster or the queue manager is deleted.
WMQ2200 queue managers use this file to determine if they are being managed
by the HA cluster. If the file exists, certain functions are restricted in the UNX shell
on the queue manager, including starting, stopping, and deleting the queue
manager.
3843 3744–002 6–1
6.2
6.3

Recommendations
• The WMQ2200 UNX shell always connects to the node of the HA cluster where
/var/mqm is currently mounted. In an HA environment, the /var/mqm file system is
mounted on only one node at a time. You cannot use UNX on any other node of an
HA cluster.
• The WMQ2200 daemon supports automatic reconnects. If configured, the daemon
attempts to reestablish communications with the OS 2200 QProcessor after the
connection is lost. This automates the reestablishment of the MQ API link after
any type of a failure, including a failover of the queue managers to another node in
the HA cluster.
• WMQ2200 queue managers create a service named WMQ2200.SERVICE when
they are initially created. This service provides a start and stop script that run
when the queue manager is started or ended. This allows users to configure
commands to run after the queue manager starts and ends. These scripts are
used to ensure automatic restarts and terminations of HA managed queue
managers. They are also used to start or stop all required components of the
queue manager. The scripts are empty by default and do not execute any
commands. Note that you cannot start OS 2200 programs or run ECL commands
from these scripts. The commands that are executed must be from the UNX shell.
6.3. Recommendations
When running one or more queue managers managed by the HA cluster, use the
following recommendations to maximize the performance and availability of the queue
managers:
• Always set DaemonRetryInt to a non-zero value in the WMQ2200 configuration
file so that the daemon reestablishes communications with the OS 2200
QProcessor after failures.
• Do not attempt to stop or start the WebSphere MQ queue managers or objects
under those queue managers that are managed by an HA cluster using the UNX
shell. Use the OS 2200 QProcessor Administration Console to manage queue
managers in the cluster.
• Do not modify or delete the queue manager service named WMQ2200.SERVICE.
Modifying or deleting this service might cause the queue manager to malfunction.
It might also affect the performance of the HA cluster if the queue manager is in
the cluster. If you accidentally delete the service, it is recreated on the next queue
manager restart.
• Use the OS 2200 QProcessor Administration Console to configure the start and
stop scripts used by WMQ2200.SERVICE. Do not add commands that do not
return control immediately. For example, if you want to start a listener from the
start script, use ‘&’ to start the listener in the background. If a command does not
return, it might cause the queue manager to malfunction or the endmqm
command to hang.
• Do not modify or delete the .ha file in the directory of the queue manager if it
exists. This file is used by WebSphere MQ to determine if the queue manager is in
the HA cluster. This file is automatically added or removed from the directory of
the queue manager when the queue manager is added or removed from the HA
cluster.
6–2 3843 3744–002

Recommendations
• Do not use the DOWN or SHUTDOWN keyins on the WMQ2200 daemon when the
HA cluster is active. Performing these keyins shuts down the API link between the
OS 2200 and the OS 2200 QProcessor and prevents user applications from
accessing queue managers on the OS 2200 QProcessor. The daemon does not
reestablish communication automatically in these cases because the user initiated
the shutdown of the API link. You must perform a UP keyin or restart the daemon
to reestablish communication with the OS 2200 QProcessor in these cases.
• If you add a user-defined trigger monitor that runs on the OS 2200 to the HA
cluster, do not disconnect the WMQ2200 daemon from the OS 2200 QProcessor
using the DOWN or SHUTDOWN keyins. The user-defined trigger monitor cannot
access queue managers if the API link is terminated. In addition, the HA cluster
cannot start or monitor the user-defined trigger monitor when the API link is
down. Once the API link is reestablished, the user-defined trigger monitor can be
restarted or monitored. Because the user-defined trigger monitor is dependent on
the WMQ2200 daemon and the daemon is not controllable by the HA software,
configure the user-defined trigger monitor so that it does not force a failover of
the cluster. In cases where the user-defined trigger monitor cannot be started or
monitored because the API link is down, a failover does not solve the problem and
must therefore be avoided in most cases. Instead, you can configure user-defined
trigger monitors to stop after exhausting its failure threshold for migration.
• Avoid using both HA managed and unmanaged queue managers on the OS 2200
QProcessor that is part of an HA cluster. If you use an unmanaged queue manager
on the OS 2200 QProcessor that is part of an HA cluster, keep in mind that it may
have the file system unmounted from it during an HA failover and might be
damaged and/or experience data loss. This damage may prevent it from being
restarted. For this reason, if you use an unmanaged queue manager on an HA
enabled OS 2200 QProcessor, it should only be used for non-critical work.
3843 3744–002 6–3

Recommendations
6–4 3843 3744–002

Section 7
Troubleshooting
This section provides troubleshooting information to help you diagnose, report, or
solve problems you might encounter during installation and operation.
Use the following table as a key to navigating this section.
To … See subsection …
Gather system and queue manager status information 7.1
Obtain error information 7.2
Obtain queue manager traces 7.3
Obtain a WMQ2200 core dump 7.4
Use the daemon background run to obtain information and
control WMQ2200
Gather diagnostic information 7.6
Obtain information about real-time run priorities 7.7
Recover an unstable WMQ2200 system 7.8
Refer to the IBM document MQSeries System Administration for more information
on troubleshooting.
7.1. Gather System and Queue Manager Status
Information
As you begin to troubleshoot your WMQ2200 system, you might want to start by
analyzing the queue manager status or system wide status. This can be done in the
following ways:
• Using the UNX Shell
• Using the OS 2200 QProcessor Administration Console
Note: More information on the UNX Shell can be found in Appendix F, "UNX Shell."
More information on the OS 2200 QProcessor Administration Console can be found
in the help for the OS 2200 QProcessor Administration Console.
3843 3744–002 7–1
7.5

Gather System and Queue Manager Status Information
7.1.1. Gather System Status
You can use the UNX Shell to gather information about the system. The following
commands are available:
Command Description
ss Displays system information
diskinfo Displays the names and sizes of all files in the /var/mqm tree
cpuinfo Displays CPU information
mquserlist Lists all OS 2200 users and their associated OS 2200
QProcessor users and groups
meminfo –v Displays memory information
uname Displays local name of the OS 2200 QProcessor
uptime Displays how long the OS 2200 QProcessor has been up
sysinfo Displays system status information
dspmqver Displays the MQS2200 version information
fileinfo –s Displays the names and sizes of all files in the /var/mqm tree
These commands can be put into a UNX runstream or run in a UNX demand session.
If you use the OS 2200 QProcessor Administration Console, you can use the following
modules to determine the system status:
Module Category Description
Running Processes Diagnostics Available for the root user under the
Diagnostic section. This displays
information on CPU, memory, and
disk utilization.
Manage User
Mappings
Management Displays the OS 2200 users and their
OS 2200 QProcessor users and
groups.
System Health Diagnostics Displays the status of disks on the
OS 2200 QProcessor.
Initial Configuration
Wizard
Configuration Displays network and host name
information.
Package Management Management Displays the levels of all WMQ2200
software packages installed on the
OS 2200 QProcessor.
7–2 3843 3744–002

7.1.2. Gather Queue Manager Status
Gather System and Queue Manager Status Information
To detect the status of the active queue managers in WMQ2200 either the UNX Shell
or the OS 2200 QProcessor Administration Console can be used.
You can use the UNX Shell to gather information about the queue managers. The
following commands are available:
Command Description
ps Displays information about active users and processes in
WMQ2200. It displays the uid, the user ID, the parent process,
process ID, the wall time of the process, and the executable
name and its arguments. Particular information on channels,
listeners, agents, queue managers, and users can be extracted.
dspmq Displays the status of all defined queue managers.
dspmqtrn_all Displays status of managed transactions for all queue managers.
These commands can be put into a UNX runstream or run in a UNX demand session.
If you use the OS 2200 QProcessor Administration Console, you can use the following
modules to determine the queue manager status:
Module Category Description
Manage MQ Management Displays the status of all defined queue
managers. Allows the administrator to
edit, start or stop each queue manager if
root is included in the mqm group.
Running Processes Diagnostics Available for the root user under the
Diagnostic category. This displays
information on active users and
processes running on the OS 2200
QProcessor. It also includes CPU,
memory and disk utilization for the
running MQ processes.
3843 3744–002 7–3

Obtaining Error Information
7.1.3. Gather Queue Manager Configuration Information
To view the queue manager configuration files or the configuration for WMQ2200 you
can use the UNX shell or the OS 2200 QProcessor Administration Console.
To use the UNX shell the following commands are available:
Command Description
dumpini Displays mqs.ini for qm.ini file of each queue manager.
savemgr_all Displays runmqsc definitions for all queue managers.
These commands can be used with the mqimport/mqexport commands to update the
contents from a demand session.
If you use the OS 2200 QProcessor Administration Console, you can use the following
modules to determine the queue manager status:
Module Category Description
Manage MQ – Edit
mqs.ini
Manage MQ – Edit
mq.ini
Management Displays and allows editing of the
mqs.ini file.
7.2. Obtaining Error Information
Management Displays and allows editing of mq.ini file
of any queue manager.
You can use the UNX shell or the OS 2200 QProcessor Administration Console to
obtain error information if you are experiencing a problem with WMQ2200 and you
have already checked the queue manager and system status.
The following commands are available if you choose to use the UNX shell.
Command Description
errors Displays system error log files from the
/var/mqm/errors/ directory.
logs Displays information about all or a particular queue
manager’s error log files. This information is extracted
from the queue manager’s errors directory
/var/mqm/qmgrs//errors/.
To view the contents from a breakpoint file, use these commands in a UNX demand
session or in an addstream.
7–4 3843 3744–002

Obtain Queue Manager Traces
The following module helps you determine the queue manager status if you use the
OS 2200 QProcessor Administration Console.
Module Category Description
View System Logs Diagnostics Allows the administrator to view the
system error log files or the log files
for a particular queue manager or the
WMQ2200 SOLAR install log. The logs
can be viewed on-line and then
downloaded to a local PC.
7.3. Obtain Queue Manager Traces
WMQ2200 provides two trace levels.
• MQS traces – reflect events within the WMQ2200 engine itself.
You will need to provide MQS traces to Unisys support personnel when obtaining
their assistance in analyzing and resolving a problem.
• UNX Shell traces – reflect events within the UNX Shell.
Note: Since tracing adversely affects performance, use discretion when enabling
tracing.
7.3.1. MQS Traces
Use the standard WebSphere MQ commands strmqtrc, endmqtrc, and dspmqtrc to
start, end, and format WMQ2200 traces, as shown in the following steps:
1. Start MQS traces:
>@wmq$*mqs$exe.unx
>strmqtrc -m QMGR1 -t all
>exit
2. Execute the application test.
3. Stop MQS traces:
>@wmq$*mqs$exe.unx
>endmqtrc -a
>exit
4. Generate a listing of error information as described in 7.2.
5. Locate the .trc files generated in directory /var/mqm/trace.
6. Format the .trc files. Do this in breakpoint for each file:
>@wmq$*mqs$exe.unx
>dspmqtrc /var/mqm/trace/AMQ nn.TRC
>exit
3843 3744–002 7–5

Obtain Queue Manager Traces
where nn is the numeric identifier for a specific .trc file. This numeric identifier
corresponds to the process identifier assigned to the process by OS 2200
QProcessor.
To recover disk space on your OS 2200 QProcessor, occasionally you must delete
AMQnn.TRC files that are no longer needed.
7.3.2. Using OS 2200 QProcessor Administration Console to
Gather Trace Information
You can gather trace information using the OS 2200 QProcessor Administration
Console Collect MQ Traces module which is located in the Diagnostic category. This
module allows the administrator to create a trace archive, download it to the local PC
and send the result to Unisys support personnel. Traces for all queue managers are
included.
7.3.3. UNX Shell Traces
You must turn traces on for debugging if there is a problem in UNX shell.
Use the UNX trace command to generate UNX shell traces.
Format
trace anything
Parameters
anything turns on the tracing at verbose level for your UNX shell session. So, a trace
command followed by anything will turn on the traces for UNX shell. You can add any
input after the trace command.
Also, a trace command with no input turns off verbose tracing. In this case, UNX shell
will run as IC_INFO tracing.
Example of Turning ON Traces
Or
>trace 1
>trace ON
Example of Turning OFF Traces
>trace
7–6 3843 3744–002

7.4. Core Dump
Core Dump
If a serious problem occurs, you might be requested by Unisys support personnel to
obtain additional information for use in problem resolution using the UNX shell core
command.
Format
core
This command forces a Programmers Advanced Debugging System (PADS) dump into
a file. The name of the file is displayed in a message both on the user’s screen and on
the operator’s console.
Example
This example shows the file naming convention used.
>@WMQ$*MQS$EXE.UNX
>Unx - 6R1 - 2009 Mar 27 Fri 11:22:43
>core
>WebSphere MQ dump taken to MQS$COREDUMP*032709112257
7.5. The WMQ2200 Daemon Background Run
The WMQ2200 daemon background run now
• Integrates the keyins of the MQADMIN interface
• Allows console operators and users at demand terminals having console keyin
privileges to send administrative commands to the WMQ2200 system.
Daemon is a background process that fields keyin requests, takes action on those
requests, and responds to the requestor. The daemon background run is useful for
troubleshooting as it allows the administrator to obtain information and control
operations of the WMQ2200 system.
7.5.1. Starting Daemon Keyin
Before starting Daemon Keyin, make sure the user ID starting it has security privileges
to allow it to use the Executive request (ER) KEYIN$. To start daemon, you can refer to
the following example:
Example
>@WMQ$*MQS$EXE.STARTUP
>Daemon started successfully.
>Daemon connected to QProcessor successfully!
>API is ready for use.
The daemon utility begins to run in the background. The batch user ID is WMQ by
default.
3843 3744–002 7–7

The WMQ2200 Daemon Background Run
Note: The programs will not be able to connect to the OS 2200 QProcessor if the
daemon run is not started.
7.5.2. Background Process Output File
WMQ2200 provides output for the Daemon background run by using the MQSRUN
element.
The MQSRUN element, found in WMQ$*MQS$RUN.MQSRUN, is used by WMQ2200
to start the Daemon background run. The Daemon output provides diagnostic
information and might help to determine the cause of the problem. The Daemon
background run generates output into WMQ$*DAEMON$OUT. Each Daemon
background run creates a new cycle of WMQ$*DAEMON$OUT file.
7.5.3. Using Daemon Keyin
Daemon Keyin is used to send administrative commands from the system console or
from a demand terminal that has console keyin privileges. All input is converted to
uppercase, so if you want to use daemon to administer your WMQ2200 system use
only uppercase.
Format
@@CONS keyin-id command[,option] [parameters]
Parameters
keyin-id is the keyin prefix configured for the WMQ2200 administrative background
run, DaemonKeyId. Default is WMQ, but you can configure WMQ2200 to use a
different keyin prefix. Refer to Section 2, "Installation and Configuration," for more
information.
command is one of the following commands:
APISTATUS Prints WMQ2200 subsystem status and API connection
information.
CORE Generates a WMQ2200 subsystem core dump for debugging.
DOWN Disconnects the WMQ2200 subsystem from the OS 2200
QProcessor.
FORCE STOP Same as SHUTDOWN except that it also terminates the connect to
the OS 2200 QProcessor even if there are connected MQ activities.
HELP Displays valid keyins or provides help with a specific keyin if
specified.
ICLOG Adjusts the Interconnect log/trace level. This is useful in diagnosing
connection issues with the OS 2200 QProcessor.
MQLOG Adjusts the WMQ2200 subsystem log/trace level.
OHIGH Changes the maximum number of activities allowed to use the
WMQ2200 API at any given time.
OLOW Changes the minimum number of servicing applications.
7–8 3843 3744–002

SHUTDOWN Shuts down the WMQ2200 daemon background run.
STATS Used to turn on and off statistics on current API usage.
UP Enables API for use.
option specifies an option on the command.
Diagnostic Gathering
parameters are optional parameters available for some commands, as noted in
Appendix F.
See Appendix E, "WMQ2200 Daemon Administrative Utility," for more information on
the commands to use with the Daemon background run.
7.6. Diagnostic Gathering
The diagnostic gathering utility (DIAG/RUN) improves the reliability and supportability
of WMQ2200 on customer production systems. It contains a set of automated
procedures that collect all necessary diagnostic and logging information from various
WMQ2200 sources to minimize the occurrence of incomplete diagnostics and
associated cost of delays. When reporting a problem through UCF or CONTACT, use
this procedure to help you gather diagnostic information.
The Gather Usysreport module located in the Diagnostic category of the OS 2200
QProcessor Administration Console helps you gather all system information,
download it to your PC and send it to Unisys support personnel. This tool takes a
snapshot of the current system and contains key files needed to diagnose a problem.
These diagnostics help the engineers determine the source of the problem effectively
and decrease the need for requesting more information on UCFs or CONTACTs.
7.6.1. Check UNX Shell Processor Availability
The UNX Shell processor must be available in order to execute the diagnostic
correlation procedure. To verify its availability, enter the following:
>@wmq$*mqs$exe.unx
where WMQ$ is the qualifier of your MQS$EXE file.
The UNX shell processor will respond with output similar to the following:
> Unx - 6R1 - 2010 May 27 Fri 11:22:43
>
If the output is not similar, or it appears that your UNX Shell processor is hung, you
will not be able to use the diagnostics gathering utility. You must manually obtain as
much relevant information as possible.
3843 3744–002 7–9

Diagnostic Gathering
Manually capture and submit the relevant diagnostic information using OS 2200
QProcessor Administration Console Usysreport Diagnostics module.
• Console log information
• EXEC online dump (dump)
7.6.2. Diagnostic Gathering Utility (DIAGN/RUN)
This procedure queries the user for the MQS$EXE file qualifier, date, and time before
and after the error occurred in order to display the console log information. The
DIAGN/RUN breakpoints the CAT/ERRORS output and number of other items into the
output file DIAGNOS. Refer to the CAT/ERRORS section for more information.
The following information is captured by DIAGN/RUN:
• Daemon print file output
• Console log Information
• OS 2200 DDP logs and traces
• Daemon apistatus output
• Subsystem bank information
• Owner of the subsystem files
• Installation information for the following products: IC2200, COMAPI, DDP-LTR,
MQS2200, and WMQ2200
• Content of the configuration file
• Content of mqsrun file
The names of core dump files will be listed in the output file as
MQS$COREDUMP-name.
This alerts the user to the existence of these files so they can be included in the
materials to be sent.
Diagnostic Gathering Usage
To execute the Diagnostic Gathering Utility, view the
WMQ$*MQSTOOLS.CAT/ERRORS runstream to verify that its output is not
breakpointed to a file. If it has breakpoint statements in its runstream, remove them.
Execute the Diagnostic Gathering runstream as follows:
1. Type the following:
>@add wmq$*mqstools.diagn/run
The following prompt is displayed:
>Enter the qualifier of your MQS$EXE file
7–10 3843 3744–002

2. Answer with the FileSystem configuration value (WMQ$, most likely).
The following prompt is displayed:
Diagnostic Gathering
>Enter a start time, preferably an hour before the problem occurred,
in format yymmdd/hhmmss >
3. Type the date and time values approximately an hour before you encountered the
problem. Enter the date in the format yymmdd/hhmmss (two digits each for year,
month, day, hour, minute, and second).
The following prompt is displayed:
>Enter an end time, preferably an hour after the problem occurred, in
format yymmdd/hhmmss >
4. Type a date and time approximately an hour after you encountered the problem
using the format yymmdd/hhmmss.
Note: You can ignore ICADMIN information in the screen DIAGN/RUN was
executed.
When the run completes, verify the output in file DIAGNOS. Scan the output for any
warnings or errors.
7.6.3. Gathering Usysreport Diagnostics
To gather Usysreport perform the following procedure:
1. Log in to the OS 2200 QProcessor Administration Console.
2. Click the Diagnostics link on the top.
3. Click the Usysreport Diagnostics link.
4. Click Run Usysreport.
5. When the Usysreport is generated, look at the Archived Usysreport Files and click
the Download link to save the zip file onto your PC.
7.6.4. List of Files to RSS to Engineering
Provide the following files to engineering:
• The DIAGNOS file containing diagnostic information.
• The diagnostic files associated with any relevant core dump files. Core dump files
that have names with the convention grunidyymmdd*msecs., where grunid is the
generated run-id of the batch run (that is, WMQ, WMQA, and so forth), yymmdd is
the date on which the file name was generated, and msecs is the time past
midnight, in milliseconds, that the file name was generated.
3843 3744–002 7–11

Diagnostic Gathering
• Any core dump files reported in the DIAGNOS file.
• Output of Usysreport.
7.6.5. Running the CAT/ERRORS Addstream Manually
You can use this addstream template, found in WMQ$*WMQTOOLS.CAT/ERRORS, as
a starting point for an addstream. It gathers error and diagnostic information from the
WMQ2200 file system and places it in your output stream. This addstream uses the
UNX commands to gather WMQ2200 information and also some system information.
@WMQ$*MQS$EXE.UNX
echo
#
# Generate a core dump
#
core
#
date
#
# Display the WMQ2200 version information.
#
dspmqver
#
# Display the status of all defined queue managers.
#
dspmq
#
#
# Display system error log files from the /var/mqm/errors/ directory.
#
errors
#
# Display each queue manager's error log files, found in each queue
# manager's errors directory (/var/mqm/qmgrs//errors/).
#
logs
#
# Display active processes
ps
#
# Display share memory information
ss
#
# Display disk information
#
diskinfo
#
# Display the names and sizes of all files in the /var/mqm tree.
#
fileinfo -s
#
7–12 3843 3744–002

Diagnostic Gathering
# Display mqs.ini file and each queue manager's qm.ini file.
#
dumpini -a
#
# Display CPU information
#
cpuinfo
#
# List all 2200 userids with their associated groups
#
mquserlist
#
# Display memory information
#
meminfo -v
#
# Display system information
#
uname
#
# Display how long the system has been up
#
uptime
#
# Displays system status information
#
sysinfo
#
# Display runmqsc definitions for all queue managers
#
saveqmgr_all
#
# Display status of managed transactions for all queue managers
#
dspmqtrn_all
#
exit
You can run the addstream in breakpoint mode to obtain the following information:
• PADS diagnostic memory dump (through the UNX Shell core command)
• WMQ2200 version information
• The status of all defined queue managers
• The contents of various error and log files within OS 2200 QProcessor. This also
includes the error log for each queue manager (through the UNX shell errors and
logs commands)
• Active processes (through the UNX ps command)
• The system status
• Shared memory information
3843 3744–002 7–13

Real-Time Run Priorities
• Names and sizes of all files in the /var/mqm tree
• The top-level internal configuration file for your OS 2200 QProcessor (mqs.ini) and
configuration file for each of your queue managers (qm.ini)
• Amount of CPU available
• List of OS 2200 user IDs with their associated groups for OS 2200 QProcessor
• System information
• How long the system has been up
• System status information
• Runmqsc definitions for all queue managers
• Status of managed transactions for all queue managers
Refer to the IBM documents MQSeries System Administration and MQSeries
Application Programming Reference for details on error codes.
7.7. Real-Time Run Priorities
OS 2200 system hangs caused by user applications that access the MQI could be the
result of incorrect run priorities set between the user application programs and the
OS 2200 QProcessor. Hangs can occur when program run priorities are set incorrectly
on systems with only one or two processors running at a lowered SCP (software
controlled performance) value along with user applications that have multiple,
real-time looping activities.
The guideline to follow regarding user applications that call the MQI is to be sure not
to run the application at a higher real-time priority than the OS 2200 QProcessor.
Think of WMQ2200 as a service provider. If you use the MQI in application programs
executing at a real-time priority greater than the service provider, the service provider
(WMQ2200) might not be able to perform the work requested by the application. The
application might preempt the WMQ2200 work.
You set the real-time level for WMQ2200 batch runs with the RealTimeLevel
parameter in element mqseries/config in file wmq$*mqs$config.
The Exec System Software Administration Reference Manual points out some
impacts of running on a controlled performance machine. A system with controlled
performance less than 100 percent performs differently from a system without the
control, even though it provides the required MIPS. The number of processors on a
system running at less than 100 percent can have different performance
characteristics. For example, a system with two processors, running at 50 percent,
with a looping real-time task consumes one processor. The system appears to
operate as a system with one processor.
7–14 3843 3744–002

Recover an Unstable WMQ2200 System
7.8. Recover an Unstable WMQ2200 System
There are two methods to recover from an unstable WMQ2200 system. If you find
that the WMQ2200 system has become corrupted or unstable, you can attempt one
or both of the methods described in section 7.8.1 and 7.8.2. Unisys advises that you
use extreme caution when taking any actions in this section. Before performing any of
the steps in this section, you must ensure that your WMQ2200 system is quiescent
(that is, no applications are attempting to perform work). Also ensure that you have
saved any information needed for problem reporting. Refer to Section 8, "Recovery
Procedures," if you are in a recovery situation.
7.8.1. Deactivating WMQ2200 Subsystems
The WMQ2200 installation provides the following utility addstreams to allow you to
deactivate your WMQ2200 subsystems:
• WMQ$*MQSTOOLS.DEACT/MQS deactivates the MQS subsystem, which
contains the WebSphere MQ engine.
• WMQ$*MQSTOOLS.DEACT/UNX deactivates the UNX subsystem.
7.8.2. Reinitializing the OS 2200 QProcessor System
You can run init command from UNX shell (WMQ$*MQS$EXE.UNX), if you find that the
OS 2200 QProcessor system has become corrupted or unusable. You must be
mapped as root on the OS 2200 QProcessor to perform an init.
You can use the mqstatus command in the UNX shell to verify if all MQ activity has
been stopped before running the init.
Example
@WMQ$*MQS$EXE.UNX
>mqstatus
>There are no MQ activities. It is safe to shut down.
Note: You must shut down all MQ processes before you can perform the init
command. If the init detects MQ activity, it will print a list and abort.
Use the following procedure to perform an init:
@WMQ$*MQS$EXE.UNX
>init
>*****************WARNING!!!*******************
>* This command will initialize your /var/mqm *
>* file system. ALL queue manager data will *
>* will be DESTROYED! *
>**********************************************
>Are you sure you want to proceed (y,n)?
Answer ‘y’ to the query.
3843 3744–002 7–15

Recover an Unstable WMQ2200 System
You will then be prompted one more time to confirm:
>To confirm you really wish to initialize /var/mqm
>enter 'y' again. Entering 'y' will DESTROY all
>queue manager data, logs, errors, and files.
>Proceed (y,n)?
Answer ‘y’ again and the init will attempt to start.
If the init is successful, you will see the following message:
>Init started...Please wait.
>Init completed.
After you have reinitialized your OS 2200 QProcessor you can restore saved queue
manager information using the MQLOAD utility. Refer to Section 3,"Administration,"
and Appendix F, "UNX Shell," for more information.
You can also restore archived log files using the MQLOADLOG utility. Refer to
Section 3,"Administration," and Appendix F, "UNX Shell," for more information.
7–16 3843 3744–002

Section 8
Message Recovery Procedures
This section discusses message recovery procedures for various error events in the
WMQ2200 environment. In case of a failure, try to collect as much diagnostic
information as you can at the time of the failure and before reestablishing operations.
Refer to Section 7, "Troubleshooting", for a description of the diagnostics to collect.
The WMQ2200 product relies upon and continues to provide the standard WebSphere
MQ recovery capabilities.
To … See subsection …
Obtain information about various recovery capabilities 8.1
Obtain information on manually resolving incomplete
global transactions
8.1. WebSphere MQ Recovery Capabilities
WebSphere MQ incorporates logging, check pointing, and recovery mechanisms to
restore persistent messages. Recovery logs are written to ensure three types of
recovery:
1. Restart recovery, when you stop WebSphere MQ in a planned way.
2. Crash recovery, when a failure stops WebSphere MQ.
3. Media recovery, to restore damaged objects.
All recoveries require the use of WebSphere MQ log files. The log files keep records
of queue manager changes and of queue updates for use by the restart process, and
enable you to restore data after a hardware or software failure.
WebSphere MQ recovery takes place when the queue manager is restarted. Internal
recovery restores the queue manager to the state it was in when the queue manager
stopped. Any non-2PC, in-progress transactions are rolled back, removing any updates
that were in progress from the queues. Recovery restores all persistent messages;
non-persistent messages might be lost.
Circular logging provides restart or crash recovery to the end of the current log file.
Linear logging additionally provides media recovery and recovery to an earlier state.
3843 3744–002 8–1
8.2

WebSphere MQ Recovery Capabilities
8.1.1. Differences with MQS2200
In MQS2200, OS 2200 integrated recovery of TIP System Services files was available
as a separate and distinct layer of recoverability in addition to the recovery and
restoration procedures provided by MQSeries. OS 2200 integrated recovery of
System Services files is not an option in the new WMQ2200 environment. The
OS 2200 System Services files no longer exist. All queue manager objects and queue
data reside on the OS 2200 QProcessor.
8.1.2. Media Recovery
You can back up your queue manager data periodically to an OS 2200 file to provide
some protection against possible corruption due to hardware or software failures.
Keep in mind that this periodic back up is not meant to recover recent messages. Use
the WMQ2200 mqsave and mqload utilities to re-create your queue manager data
from the saved information. These utilities save and restore queue manager objects as
well as the queue manager log files whether circular or linear.
Refer to Section 3, "Administration," for details on how to use these utilities.
An alternative method of media recovery is to use the WebSphere MQ rcdmqimg
command to write an image of an object, or group of objects, to the log files on the
OS 2200 QProcessor. The rcdmqimg command can only be used with linear logging. If
your queue manager is damaged, you can then use the rcrmqobj command to
re-create the queue manager from the images contained in the log files.
Recreate Linear Log Queue Manager from Log Files
The recoverqmgr utility is used to restore a linear log queue manager to another
OS 2200 QProcessor or the same OS 2200 QProcessor after a reimage. The utility
recreates a queue manager that uses linear logging since these queue managers are
the only ones recoverable through log files. The recoverqmgr utility uses the log files
of the queue manager, a backed up copy of its qm.ini file, and a special recovery script
to recreate the queue manager. After the queue manager is recreated, the backed up
logs are used to start the queue manager to recover the objects of the queue
manager. In this way, the queue manager can be recovered to its last state.
After each successful strmqm, WMQ2200 copies the qm.ini to the log directory of the
queue manager. It also creates a special script named regencrtmqm.sh under the log
directory of the queue manager. This script contains the necessary crtmqm command
to recreate the queue manager.
The recoverqmgr utility takes the following inputs in the command line:
• The name of the queue manager being restored, which is required.
• The log path of the queue manager if it is not in the default location of
/var/mqm/log/ can be specified, which is optional. The “-l” option
followed by the log path need to be used. The path you give must be the full path
to the log directory.
8–2 3843 3744–002

The recoverqmgr utility performs the following tasks:
WebSphere MQ Recovery Capabilities
1. Backs up the log files of the queue manager in a compressed format to
/var/mqm/log/.tar.gz.
2. Deletes the old log tree of the queue manager.
3. Executes the regencrtmqm.sh script, which creates the queue manager.
4. Deletes the new log files that are empty.
5. Extracts the log files of the original queue manager from the compressed backup,
back to its original location.
6. Copies the qm.ini from backup to the qmgrs directory of the queue manager,
which restores previous settings and updates the log directory to point to the old
log directory location.
7. Starts the queue manager to force a rebuild of the objects of the queue manager
from the original log files.
8. Queries the user if they want to delete backup copy of the log directory of the
queue manager. The user must to answer ‘y’ to delete the archived log files, or ‘n’
to retain the archived log files.
If there are more queue managers that you want to restore, the recoverqmgr utility
must be executed for each queue manager. After the queue manager has finished its
first start from the log files, its objects will be recovered and restored. You can then
perform a normal startup of your queue manager components and applications.
Example
The following example illustrates a queue manager (qm1) recovery:
@wmq$*mqs$exe.unx
>recoverqmgr qm1
Backing up log files of the queue manager to '/var/mqm/log/qm1.tar.gz'.
Running 'regencrtmqm.sh' script to create the queue manager.
WebSphere MQ queue manager created.
Creating or replacing default objects for qm1.
Default objects statistics : 40 created. 0 replaced. 0 failed.
Completing setup.
Setup completed.
Restoring log files of the queue manager from '/var/mqm/log/qm1.tar.gz'.
WebSphere MQ queue manager 'qm1' starting.
194 log records accessed on queue manager 'qm1' during the log replay phase.
Log replay for queue manager 'qm1' complete.
Transaction manager state recovered for queue manager 'qm1'.
WebSphere MQ queue manager 'qm1' started.
3843 3744–002 8–3

WebSphere MQ Recovery Capabilities
Log files of the queue manager are backed up to '/var/mqm/log/qm1.tar.gz'.
Do you want to delete queue manager 'qm1' backup log files, y/n?
>y
The backup log files of the queue manager are deleted.
8.1.3. Point-in-time Message Recovery
You can use the mqsave, mqload and mqsavelog, mqloadlog utilities to revert the
WebSphere MQ environment to the time of the save. You can also use backups
created in the OS 2200 QProcessor Administration Console to revert the entire
/var/mqm file system or a specific queue manager back to a point-in-time.
You can use mqsave and mqload with either circular or linear log file systems. These
utilities save and restore the entire queue manager environment to the point of the
last mqsave, and can be used in a damaged queue manager situation. These utilities
are run when the queue manager is ended.
Use mqsavelog and mqloadlog only with a linear log file system. mqsavelog removes
stale log files from the system that are no longer needed for queue manager message
recovery. You must remove the stale log files on a regular basis with a linear log file
queue manager to free up disk space. You can then use mqloadlog to restore the
queue manager to a previous point of processing. These utilities assume the queue
manager itself is operational and not damaged. You can run the mqsavelog and
mqloadlog utilities with the queue manager running or ended.
Using backups created with the OS 2200 QProcessor Administration Console, you can
restore your entire MQ file structure or a specific queue manager back to a
point-in-time. The restored queue managers are stopped to use the restore feature.
The Administration Console stops the queue managers in question before the restore
if necessary and can restart the queue managers after the restoration is completed.
You can perform a one-time backup of queue managers or schedule backups to run
on a regular or periodic basis.
Note: Whenever a backup is performed, the affected queue managers are shut
down and are unavailable for the duration of the backup.
Regardless of the method you use for recovery or restoration, note that a
point-in-time restoration restores the queue manager data back to the time when the
backup was performed. This means messages that were stored on the queue
manager at the time of the backup are restored. The applications and environment
must be able to properly handle messages that may be restored and consumed after
the original backup. If message duplication is an issue in your environment, you might
want to consider backing up the queue manager object definitions, object authorities,
and queue manager configuration scripts as an alternative to point-in-time backups of
queue managers.
8–4 3843 3744–002

8.1.4. OS 2200 Database Synchronization
WebSphere MQ Recovery Capabilities
Coordinating recovery of both the WebSphere MQ data and an OS 2200 database to
the same point in time involves manual procedures to synchronize the WebSphere
MQ saves and loads with the OS 2200 database IRU dumps and reloads. It is best to
halt all database and message queuing activity when capturing this data.
Processing messages and database work within global transactions is the best way to
ensure WebSphere MQ data and the OS 2200 database synchronization for restart and
crash recoveries.
8.1.5. Open DTP Subsystem Abort and Deactivation
If the Open DTP subsystem deactivates while processing global transactions that
involve WMQ2200 as a resource manager, reload tmsconfig, rerun the RMINSTALL
addstream that registers WMQ2200 as a resource manager, and then restart the Open
DTP background run TMSC. This resolves any broken in-flight transactions.
8.1.6. OS 2200 Application Group Abort
The WMQ2200 subsystem will have no knowledge of an application group abort and
must remain running through application group recovery.
8.1.7. OS 2200 Daemon Abort
Save the wmq$*daemon$out file for error reporting. Restart the OS 2200 daemon:
@wmq$*mqs$exe.startup
8.1.8. OS 2200 System Stop
After a system stop, perform the following steps:
1. Recover the application groups.
2. Restart the WMQ2200 daemon.
3. Reload the Open DTP tmsconfig and run rminstall (if using Open DTP 2PC with
MQI).
4. Restart Open DTP background run, TMSC.
Step 1 restores the OS 2200 databases to an operable state.
Step 2 reestablishes connectivity to the OS 2200 QProcessor for message access.
Step 3 allows Open DTP to resolve broken in-flight transactions.
3843 3744–002 8–5

WebSphere MQ Recovery Capabilities
8.1.9. OS 2200 QProcessor Stop
The OS 2200 daemon reports that the connection is broken when the OS 2200
QProcessor stops.
WMQ*WARNING: IC connection has unexpectedly terminated!
WMQ*MQ applications will not be able to access queue
WMQ*managers until the IC connection is restored.
WMQ*Use the UP keyin to restore the connection
WMQ*after the problem is resolved.
WMQ*Check logs for diagnostics.
After the OS 2200 QProcessor system is recovered, perform the following steps to
recover and restart message processing:
1. Restart the queue managers.
2. Restart the Interconnect Service program.
3. Enter keyin @@cons wmq to the OS 2200 daemon.
Step 1 performs WebSphere MQ recovery.
For step 2, use the OS 2200 QProcessor Administration Console. Click Configuration
in the menu bar, and then click the Interconnect Configuration icon to see and act
upon the Interconnect Service status.
Step 3 causes the OS 2200 background daemon run to reestablish the message
queuing connection to the OS 2200 QProcessor.
8.1.10. OS 2200 QProcessor Disk Failure
Your OS 2200 QProcessor comes with three disks, any of which can fail. Failed disks
can be detected by viewing the System Health module in the Diagnostic category of
the OS 2200 QProcessor Administration Console. The module shows which disk might
have failed and provides a mechanism to rebuild the replacement disk.
Two of the disks are mirrored. The mirrored disks contain the OS 2200 QProcessor
operating system, system software, and the WebSphere MQ /var/mqm/log directory.
If one of the mirrored disks fails, replace the bad disk as soon as possible. The system
will continue to run. Once the replacement disk is in place, the OS 2200 QProcessor
automatically starts to resynchronize the disks. This should not affect the running
applications.
The unmirrored disk contains the contents of the WebSphere MQ /var/mqm directory,
which holds the queue manager objects and message data. If this disk fails, replace it
with a new disk and perform the following steps to recover and return to message
processing:
1. Set an environment variable: export UNISYS_IGNORE_LOG_PATH_LOCK=1. This
allows you to use the –ld option on crtmqm so that you can specify a new log
path.
8–6 3843 3744–002

Manually Resolving Incomplete Global Transactions
2. Re-create your queue manager with a new log file path using the –ld option on
your crtmqm command.
3. In an OS 2200 UNX shell, copy the saved qm.ini file over the re-created queue
manager qm.ini file.
4. Enter the strmqm command.
Restart channels and trigger monitors to return to message processing.
For step 2, make sure all other crtmqm parameters are the same, as when you first
created the queue manager. The –ld option on the crtmqm command allows you to
specify an alternate path for the location of the log files of the queue manager. This is
done to avoid destroying the original queue manager log files.
Step 3 points the queue manager to the original log files of the queue manager. This
allows the newly created queue manager to recover from the original log files. In an
OS 2200 UNX shell session, enter the following command to copy the original qm.ini
file over the newly created qm.ini file.
cp /var/mqm/backup_data/ini_backups//qm.ini
/var/mqm/qmgrs//qm.ini
Replace with the name of the real queue manager name.
Step 4 causes the queue manager to recover messages.
8.1.11. WMQ2200 Subsystem Abort and Deactivation
Restart the OS 2200 daemon using the following command:
@wmq$*mqs$exe.startup
8.2. Manually Resolving Incomplete Global
Transactions
You will experience messages residing on queues that cannot be removed or cleared
if they are part of an incomplete global transaction. In cases where the global
transactions involving WMQ2200 as a resource manager cannot be completed or
resolved by Open Distributed Transaction Processing, use the dspmqtrn and rsvmqtrn
commands to display and manually resolve the transaction within WMQ2200.
Committing and Rolling Back Messages
To decide whether to commit or roll back a message, use the Open Distributed
Transaction Processing TMADMIN processor to display the current status of broken
transactions:
@otm$*tm$run.tmadmin
r a
3843 3744–002 8–7

Manually Resolving Incomplete Global Transactions
If there is a log entry showing a transaction state of recovery commit for the XID
number, this entry is from the root node and shows that all branches have returned a
ready for the prepare request. You must see log entries with a state of recovery
ready for the subordinate branches involved in the global transaction. This means that
all branches have logged a ready state and all resource managers involved in the
transaction can commit their work. You can decide to either commit or rollback the
work in this case. You can commit the WMQ2200 message as long as you can also
commit the other branches to keep the databases synchronized; otherwise, rollback
the message.
Conversely, if no log entry exists showing a transaction state of commit for the XID
number, but recovery ready log entries exist, or a recovery rollback state exists for
the XID number, roll back the WMQ2200 message.
When you restart TMSC, the commit log entry for the root node (if it exists) and the
log entries for the subordinate or branch nodes that have been manually committed
are removed or rolled back from the Open Distributed Transaction Processing
recovery log file.
Example
The following is a sample display from the TMADMIN processor that shows two
branch nodes in the recovery ready state and the root node in the recovery commit
state. The first log entry is for the WMQ2200 branch, and the message must be
manually committed. When you restart TMSC, the root node and second branch (a
Universal Database Control branch in this case) is committed by the recovery server
and all log entries for this transaction are removed.
Command: -r a
XID: 950011945 6 53125798 11043 1
7 3
STEP_ID: 000000000000 000000000000
AG_ID: 0 STATE: RECOVERY READY FILE INDEX: 0
XID: 950011945 6 53125798 11043 1
6 0
STEP_ID: 000000000000 000000000000
AG_ID: 0 STATE: RECOVERY COMMIT FILE INDEX: 1
XID: 950011945 6 53125798 11043 1
5 4
STEP_ID: 440333147606 000732070000
AG_ID: 8 STATE: RECOVERY READY FILE INDEX: 2
EOF
8–8 3843 3744–002

dspmqtrn command
Manually Resolving Incomplete Global Transactions
Use the dspmqtrn command to display the status of externally managed transactions
for a queue manager.
Formats
dspmqtrn -e -m q-mgr-name
dspmqtrn -m q-mgr-name -e
dspmqtrn
dspmqtrn -e (displays transactions for the default queue manager)
Options and Parameters
-e requests details of externally coordinated in-doubt transactions.
-m q-mgr-name specifies the name of the queue manager whose transactions are to
be displayed.
Note: The -i option is not available with WMQ2200.
Outcome
A message is displayed either describing a transaction or informing you that no
prepared transactions exist. The message is similar to the following:
AMQ7056: Transaction number 0,7.
XID: formatID 2, gtrid_length 20, bqual_length 8
gtrid [7E0C603406000000B440F701D037000001000000]
gtridTM2200: 878709886 6 32981172 14288 1
bqual [0700000003000000]
bqualTM2200: 7 3
The gtrid and bqual are displayed in two forms. One is the WebSphere MQ format and
the other is the Open DTP format. This is done to allow you to match the XID in the
message with the XID shown by the Open DTP TMADMIN processor. The Open DTP
forms for gtrid and bqual have the suffix TM2200 in this display.
An important piece of information to note for manually resolving the branch with the
rsvmqtrn command is the transaction number 0,7.
rsvmqtrn command
Use the rsvmqtrn command to either commit or roll back externally coordinated
in-doubt or incomplete transactions.
Format to commit
rsvmqtrn -m q-mgr-name -c n,n
Format to roll back
rsvmqtrn -m q-mgr-name -b n,n
3843 3744–002 8–9

Manually Resolving Incomplete Global Transactions
Options and Parameters
-m q-mgr-name specifies the name of the queue manager.
-c specifies commit.
-b specifies roll back.
n,n specifies the transaction number as displayed in the dspmqtrn message (in the
preceding example, the transaction number is 0,7).
Note: The -a and -r options are not available with WMQ2200.
8–10 3843 3744–002

Appendix A
Data Formatting Between Multiple
Platforms
This appendix contains details on the libraries and C header files that are supplied with
WMQ2200 to assist the user application in reformatting data between multiple
platforms.
To … See subsection …
Obtain information about the hton/o library routines A.1
Obtain information about the htondb/o library routines A.2
Obtain information about the hton-ucob/o library routines A.3
Obtain information about the htondb-ucob/o library
routines
Obtain information about the h9ton8/o library routines A.5
A.1. Library hton/o
The library hton/o is compatible with the C language and includes the following
routines a user application can call. Include hton/o in your user application.
A.1.1. Host-to-Network Functions
htonl
This section contains descriptions for the host-to-network functions for C programs.
These functions assist in passing integer values within the message area. Include the
hton.h header file to use these functions in your application.
Prototype
Unsigned long htonl (unsigned long hostlong)
Description
Converts a 36-bit unsigned integer in 9-bit bytes to a 32-bit unsigned integer in
8-bit bytes. htonl() ignores the 4 leftmost bits of the value in hostlong. For
example, an input value of 4294967296 truncates to zero, and 68719476735
truncates to 4294967295.
3843 3744–002 A–1
A.4

Library hton/o
shtonl
htons
Arguments
hostlong is an input argument containing a 36-bit unsigned integer in the range
zero to 4294967295.
Return Value
htonl() returns a 36-bit integer in which the 8 rightmost bits of each byte form a
32-bit unsigned integer in network format.
Prototype
Signed long shtonl (signed long hostlong)
Description
Converts a 36-bit signed one's complement integer in 9-bit bytes to a 32-bit
signed two's complement integer in 8-bit bytes. If the value in hostlong is less
than -2147483648, shtonl() returns -2147483648. If the value in hostlong is greater
than 2147483647, shtonl() returns 2147483647.
Arguments
hostlong is an input argument containing a 36-bit signed integer in the range
-2147483648 to 2147483647.
Return Value
shtonl() returns a 36-bit integer in which the 8 rightmost bits of each byte form a
32-bit signed integer in network format.
Prototype
Unsigned short htons (unsigned short hostshort)
Description
Converts an 18-bit unsigned integer in 9-bit bytes to a 16-bit unsigned integer in
8-bit bytes. It ignores the 2 leftmost bits of the value in hostshort. For example, an
input value of 65536 truncates to zero, and 262143 truncates to 65535.
Arguments
hostshort is an input argument containing an 18-bit unsigned integer in the range
zero to 65535.
Return Value
htons() returns an 18-bit integer in which the 8 rightmost bits of each byte form a
16-bit unsigned integer in network format.
A–2 3843 3744–002

shtons
Prototype
Signed short shtons (signed short hostshort)
Description
Library hton/o
Converts an 18-bit signed one's complement integer in 9-bit bytes to a 16-bit
signed two's complement integer in 8-bit bytes. If the value in hostshort is less
than -32768, shtons() returns -32768. If the value in hostshort is greater than
32767, shtons() returns 32767.
Arguments
hostshort is an input argument containing an 18-bit signed integer in the range
-32768 to 32767.
Return Value
shtons() returns an 18-bit integer in which the 8 rightmost bits of each byte form a
16-bit signed integer in network format.
A.1.2. Network-to-Host Functions
ntohl
This section contains descriptions for the network-to-host functions for C programs.
These functions assist in passing integer values within the message area. Include the
hton.h header file to use these functions in your application.
Prototype
Unsigned long ntohl (unsigned long networklong)
Description
Converts a 32-bit unsigned integer in 8-bit bytes to a 36-bit integer in 9-bit bytes.
Arguments
networklong is an input argument containing a 36-bit integer in which the 8
rightmost bits of each byte form a 32-bit unsigned integer in network format.
Return Value
ntohl() returns a 36-bit unsigned integer.
3843 3744–002 A–3

Library hton/o
sntohl
ntohs
sntohs
Prototype
Signed long sntohl (signed long networklong)
Description
Converts a 32-bit signed two’s complement integer in 8-bit bytes to a 36-bit
signed one’s complement integer in 9-bit bytes.
Arguments
networklong is an input argument containing a 36-bit integer in which the 8
rightmost bits of each byte form a 32-bit signed integer in network format.
Return Value
sntohl() returns a 36-bit signed integer.
Prototype
Unsigned short ntohs (unsigned short networkshort)
Description
Converts a 16-bit unsigned integer in 8-bit bytes to an 18-bit unsigned integer in
9-bit bytes.
Arguments
networkshort is an input argument containing an 18-bit integer in which the 8
rightmost bits of each byte form a 16-bit unsigned integer in network format.
Return Value
ntohs() returns an 18-bit unsigned integer.
Prototype
Signed short sntohs (signed short networkshort)
Description
Converts a 16-bit signed two's complement integer in 8-bit bytes to an 18-bit
signed one's complement integer in 9-bit bytes.
Arguments
networkshort is an input argument containing an 18-bit integer in which the 8
rightmost bits of each byte form a 16-bit signed integer in network format.
A–4 3843 3744–002

Return Value
sntohs() returns an 18-bit signed integer.
A.2. Library htondb/o
Library htondb/o
The library htondb/o is compatible with the C language and includes the same routines
as the hton/o library. Use this library when debugging your application. It verifies that
bits are not lost when converting host data to network data for the routines htonl(),
htons(), shtonl(), and shtons(). If the system detects a loss, it displays a warning
message on stdout of the application that is calling the function. Your application
continues to execute; however, data is lost on the receiving end of the connection.
A.3. Library hton-ucob/o
The library hton-ucob/o is compatible with the COBOL language and contains the
routines described in the following subsections.
A.3.1. Host-to-Network Functions
HTONL
SHTONL
This section contains descriptions for the host-to-network functions for COBOL
programs. These functions assist in passing integer values within the message area.
Description
Converts a 36-bit unsigned integer in 9-bit bytes to a 32-bit unsigned integer in 8-bit
bytes. HTONL ignores the 4 leftmost bits of the input value. For example, an input
value of 4294967296 truncates to zero, and 68719476735 truncates to 4294967295.
Syntax
CALL 'HTONL' USING host-36bit-binary network-long.
Argument In/Out Comments
host-36bit-binary Input 36-bit unsigned fixed-point binary integer in
the range zero to 4294967295
network-long Output 36-bit integer in which the 8 rightmost bits of
each byte form a 32-bit unsigned integer in
network format
Description
Converts a 36-bit signed one's complement integer in 9-bit bytes to a 32-bit signed
two's complement integer in 8-bit bytes. If the input value is less than -2147483648,
SHTONL returns -2147483648. If the input value is greater than 2147483647, SHTONL
returns 2147483647.
3843 3744–002 A–5

Library hton-ucob/o
HTONS
SHTONS
Syntax
CALL 'SHTONL' USING host-36bit-binary network-long.
Argument In/Out Comments
host-36bit-binary Input 36-bit signed fixed-point binary integer in the
range -2147483648 to 2147483647
network-long Output 36-bit integer in which the 8 rightmost bits of
each byte form a 32-bit signed integer in
network format
Description
Converts an 18-bit unsigned integer in 9-bit bytes to a 16-bit unsigned integer in 8-bit
bytes. HTONS ignores the 2 leftmost bits of the input value. For example, an input
value of 65536 truncates to zero, and 262143 truncates to 65535.
Syntax
CALL 'HTONS' USING host-18bit-binary network-short.
Argument In/Out Comments
host-18bit-binary Input 18-bit unsigned fixed-point binary integer in
the range zero to 65535
network-short Output 18-bit integer in which the 8 rightmost bits of
each byte form a 16-bit unsigned integer in
network format
Description
Converts an 18-bit signed one's complement integer in 9-bit bytes to a 16-bit signed
two's complement integer in 8-bit bytes. If the input value is less than -32768,
SHTONS returns -32768. If the input value is greater than 32767, SHTONS returns
32767.
Syntax
CALL 'SHTONS' USING host-18bit-binary network-short.
Argument In/Out Comments
host-18bit-binary Input 18-bit signed fixed-point binary integer in the
range -32768 to 32767
network-short Output 18-bit integer in which the 8 rightmost bits of
each byte form a 16-bit signed integer in
network format
A–6 3843 3744–002

A.3.2. Network-to-Host Functions
NTOHL
SNTOHL
Library hton-ucob/o
This section contains descriptions for the network-to-host functions for COBOL
programs. These functions assist in passing integer values within the message area.
Description
Converts a 32-bit unsigned integer in 8-bit bytes to a 36-bit integer in 9-bit bytes.
Syntax
CALL 'NTOHL' USING network-long host-36bit-binary.
Argument In/Out Comments
network-long Input 36-bit integer in which the 8 rightmost bits of
each byte form a 32-bit unsigned integer in
network format
host-36bit-binary Output 36-bit unsigned fixed-point binary integer
Description
Converts a 32-bit signed two’s complement integer in 8-bit bytes to a 36-bit signed
one's complement integer in 9-bit bytes.
Syntax
CALL 'SNTOHL' USING network-long host-36bit-binary.
Argument In/Out Comments
network-long Input 36-bit integer in which the 8 rightmost bits of
each byte form a 32-bit signed integer in
network format
host-36bit-binary Output 36-bit signed fixed-point binary integer
3843 3744–002 A–7

Library htondb-ucob/o
NTOHS
SNTOHS
Description
Converts a 16-bit unsigned integer in 8-bit bytes to an 18-bit unsigned integer in 9-bit
bytes.
Syntax
CALL 'NTOHS' USING network-short host-18bit-binary.
Argument In/Out Comments
network-short Input 18-bit integer in which the 8 rightmost bits of
each byte form a 16-bit unsigned integer in
network format
host-18bit-binary Output 18-bit unsigned fixed-point binary integer
Description
Converts a 16-bit signed two's complement integer in 8-bit bytes to an 18-bit signed
one’s complement integer in 9-bit bytes.
Syntax
CALL 'SNTOHS' USING network-short host-18bit-binary.
Argument In/Out Comments
network-short Input 18-bit integer in which the 8 rightmost bits of
each byte form a 16-bit signed integer in
network format
host-18bit-binary Output 18-bit signed fixed-point binary integer
A.4. Library htondb-ucob/o
The library htondb-ucob/o is compatible with the COBOL language and includes the
same routines as the hton-ucob/o library. Use this library when debugging your
application. It verifies that bits are not lost when converting host data to network data
for the routines HTONL, HTONS, SHTONL, and SHTONS. If the system detects a loss,
it displays a warning message on stdout of the application that is calling the function.
Your application continues to execute; however, data is lost on the receiving end of
the connection.
A–8 3843 3744–002

A.5. Library h9ton8/o
Library h9ton8/o
The library h9ton8/o contains routines that allow user applications to successfully
transmit binary data from one OS 2200 platform to another OS 2200 platform across
an MQSeries network, possibly through intermediate non-OS 2200 stages.
The library h9ton8/o is compatible with C and COBOL languages and includes the
following routines a user application can call. Include hton/h in your user application or.
A.5.1. Host-to-Network Function
h9ton8
This function assists in passing binary data within the message area. Include the hton.h
header file to use this function in your C application.
C Prototype
Signed long h9ton8 (void *input, signed long size, void *output)
COBOL Prototype
CALL "H9TON8" USING INPUT, SIZE, OUTPUT, BY REFERENCE STATUS.
(Both SIZE and STATUS must be defined as PIC S9(9) COMP-5.)
Description
Converts a 36-bits-per-word input buffer into an output buffer suitable for
transmission across the network interface. This routine converts each 9-bit byte of
the input buffer to an 8-bit byte by stripping the sign bit (the high order bit) and
then moving the remaining 8 bits to the output buffer. It then packs the sign bits
and places them at the end of the output buffer.
Arguments
input is a pointer to a buffer containing host data to be converted. This buffer
must begin on a word boundary.
size is the size of the input buffer in 9-bit bytes.
output is a pointer to a buffer that contains the reformatted data. This buffer must
be 20 percent larger than the input buffer to contain the additional packed sign
bits. This buffer must begin on a word boundary.
Return Value
h9ton8 returns a 36-bit integer that contains the size in bytes of the reformatted
output buffer or an error value.
3843 3744–002 A–9

Library h9ton8/o
Error Values
-1 wrong number of arguments
-2 input buffer access failed or input buffer not on word boundary
-3 output buffer access failed or output buffer not on word boundary
A.5.2. Network-to-Host Function
n8toh9
This function assists in passing binary data within the message area. Include the hton.h
header file to use this function in your C application.
C Prototype
Signed long n8toh9 (void *input, signed long size, void *output)
COBOL Prototype
CALL “N8TOH9” USING INPUT, SIZE, OUTPUT, BY REFERENCE STATUS.
(Both SIZE and STATUS must be defined as PIC S9(9) COMP-5.)
Description
Converts an input buffer created by h9ton8() back into the original data format and
moves it to the output buffer. This routine recombines each byte of the input
buffer with its stripped sign bit (the high-order bit), and then moves it to the
output buffer.
Arguments
input is a pointer to a buffer containing h9ton8() data to be converted. This buffer
must begin on a word boundary.
size is the size of the input buffer in bytes.
output is a pointer to a buffer that contains the reformatted data. This buffer must
begin on a word boundary.
Return Value
n8toh9 returns a 36-bit integer that contains the size in bytes of the reformatted
output buffer or an error value.
Error Values
-1 wrong number of arguments
-2 input buffer access failed or input buffer not on word boundary
-3 output buffer access failed or output buffer not on word boundary
-4 invalid buffer type (not created by h9ton8 function)
-5 invalid buffer size
A–10 3843 3744–002

Appendix B
Sample TX/WMQ2200 API Scenarios
and Recommendations
This appendix shows the suggested sequence of Open Distributed Transaction
Processing TX verbs and WMQ2200 application interface verbs. Remember that for
any put or get call to WMQ2200 to be a recoverable part of an Open Distributed
Transaction Processing global transaction, you must use the MQSeries Syncpoint
option on the request.
Unisys recommends that the tx_ calls bracket the rest of the calls. In other words,
your client should perform the tx_open and tx_begin calls first, then perform service
calls, and then perform the tx_commit/tx_rollback and tx_close calls. The generalized
sequence of calls for a client application would then be
tx_open
tx_begin
. . .
XATMI call (for example, tpcall or tpacall) or MQI calls (for example,
MQCONN, MQOPEN, MQPUT/MQGET, MQCLOSE, MQDISC)
XATMI call (for example, tpcall or tpacall) or MQI calls (for example,
MQCONN, MQOPEN, MQPUT/MQGET, MQCLOSE, MQDISC)
XATMI call (for example, tpcall or tpacall) or MQI calls (for example,
MQCONN, MQOPEN, MQPUT/MQGET, MQCLOSE, MQDISC)
. . .
tx_commit/tx_rollback
tx_close
The XATMI and MQI calls can occur in any order, depending on your business
application logic needs. Unisys recommends this generalized sequence because it
corresponds most closely to a standard transaction processing multi-tier architecture
and is the cleanest approach.
3843 3744–002 B–1

Sample TX/WMQ2200 API Scenarios and Recommendations
Transaction Manager (TM) Guidelines
Important MQSeries XA rules regarding use of Open Distributed Transaction
Processing with WMQ2200 for TX/MQS API sequences include
• The xa_info structure passed on any xa_open call by the TM includes the name of
a non-default queue manager. If xa_info is left blank, MQSeries invokes the default
queue manager.
• Only one queue manager at a time can participate in a transaction coordinated by
an external TM.
• Applications calling an external TM can connect only to the queue manager
participating in the transaction.
• The queue manager that is participating in a transaction must be started before
the transaction starts.
B–2 3843 3744–002

Appendix C
Editing WMQ2200 QProcessor Files
Occasionally you might need to modify a text file that provides configuration
information to WMQ2200. These files are physically located on the OS 2200
QProcessor, so direct editing of a file is not allowed. This appendix describes how to
use the TED line editor for editing a file.
TED is a line editor that contains functionality similar to that of line oriented editors
such as the @ED processor in the OS 2200 environment. Care must be taken to edit
only text files because displaying a binary file can cause strange behavior with some
terminal emulators.
To get out of insert mode and back to command mode use @EOF. The @EOF sends
CTRL-D to the OS 2200 QProcessor.
Note: You can only edit files in your current working directory. For example, if you
want to update mqs.ini, you cannot use ted /var/mqm/mqs.ini, instead use cd
/var/mqm/ followed by ted mqs.ini.
Format
ted [-p] [-s] file
Options
-s Suppress diagnostics.
-p Specifies a command prompt.
file Is the file to be read.
Example 1
Change LogSecondaryFiles from 2 to 6 in qm.ini
>@wmq$*mqs$exe.unx
>cd /var/mqm/qmgrs/logqm
>ted qm.ini
-1100
>,s/LogSecondaryFiles=2/LogSecondaryFiles=6/g
>@eof
-?
>wq
-1100
3843 3744–002 C–1

In the above example, LogSecondaryFiles is changed from 2 to 6.
Example 2
Create a new file using TED and append content
>ted
>a
>new file has been created.
>@eof
>wq file1.txt
-27
Editing WMQ2200 QProcessor Files
The above example creates a new file called file1.txt with the content “new file has
been created.”
Example 3
TED Options
Insert text into file1.txt that was created in example 2.
>ted file1.txt
>i
testing "I" command for ted.
@eof
wq
The following lists some of the TED options:
-s Suppress diagnostics.
-p Specifies a command prompt. The p option can be used to
toggle on and off.
file Indicates the name of the file to be processed.
C–2 3843 3744–002

Editing WMQ2200 QProcessor Files
TED Commands
The following table lists some of the TED commands.
Table C–1. TED Commands
Command Description
(.) a Appends text to the file as an input mode.
(.,.) c Changes lines in the file as an input mode.
(.,.) d Deletes addressed lines from file.
(.) i Inserts text into the file before the current line as an input
mode.
(.,.) m (.) Moves lines in the file.
q Quits TED editor.
($) r file Reads file information. The default file name is used if a file
name is not specified.
(.,.)s/old/new/g Globally replaces old with new. If ‘g’ is not specified, only
the first occurrence will be replaced.
u Undo the last performed command.
w file Writes the content to the file.
wq file Writes the content to the file and then quits the TED editor.
W file Appends the content to the end of the file.
($)= Displays the line number of the file.
3843 3744–002 C–3

Editing WMQ2200 QProcessor Files
C–4 3843 3744–002

Appendix D
Restrictions and Known Limitations
The following are the concepts and objects that are part of the WebSphere MQ family
of products but are not supported or are restricted in WMQ2200 6R1:
• Using WMQ2200 as a dynamic resource manager (RM).
• FASTPATH for user-written applications.
• MQBEGIN MQI call for global units of work; Open Distributed Transaction
Processing is required for resource manager coordination.
• MQCMIT and MQBACK MQI calls used with global units of work (with MQBEGIN),
with MQS2200 functioning as the coordinating transaction manager.
• -i option of the dspmqtrn command.
• -a and -r options of the rsvmqtrn command.
• WMQ does not support the MQI MQZEP command (for adding a component entry
point for pluggable naming and authorization services).
• MQCNO Version 1 is supported for the MQCONNX MQI call. The MQCNO options
flags MQCNO_HANDLE_SHARE_BLOCK, MQCNO_HANDLE_SHARE_NO_BLOCK,
and MQCNO_FASTPATH_BINDING are accepted but ignored.
• A distribution list cannot be larger than 500 items.
• The maximum message size supported is 100 megabytes.
• Exit code must be deployed on the OS 2200 QProcessor. Exit code running on the
OS 2200 is not supported. If data conversion exits are currently being used to
convert multi-byte data, the conversions must be done in the user application on
the OS 2200 before sending or after receiving the message.
• The OS 2200 auditing of MQ data is not currently supported. This implies no IRU
dumps and restoration of the container files.
• WebSphere MQ structures MQRMH (bulk message header), MQAIR
(authentication header for the MQI client), MQCSP (authentication header), and
MQSCO (SSL configuration structure), MQCIH (CICS header) and MQWIH (work
info header) are not supported in OS 2200 user applications.
• Simple Object Access Protocol (SOAP) is not supported.
3843 3744–002 D–1

Restrictions and Known Limitations
• The WebSphere MQ client library is not available on the OS 2200.
• C++ applications are not supported on the OS 2200.
• TCP/IP is the only supported communications protocol for channels. The LU6.2
protocol is not supported.
• The WMQ2200 product has not been validated for message recovery in an XTC
environment on a remote or alternate host.
• Restricted mode queue managers (application groups) are not supported.
D–2 3843 3744–002

Appendix E
WMQ2200 Daemon Administrative
Utility
E.1. The Daemon Administrative Utility
The daemon administrative utility allows console operators and users at demand
terminals having console keyin privileges to send administrative commands to the
WMQ2200 system. Daemon is a background process that fields keyin requests, takes
action on those requests, and responds to the requestor. It also creates API
connection between the OS 2200 and the OS 2200 QProcessor.
E.1.1. Starting the Daemon Utility
Before starting daemon keyin, make sure the user ID starting it has security privileges
to allow it to use the Executive request (ER) KEYIN$. To start the daemon utility, refer
to the following example:
Example
>@WMQ$MQS$EXE.STARTUP
>Daemon started successfully.
>Daemon connected to QProcessor successfully!
>API is ready for use.
The daemon utility begins to run in the background. The batch user ID is WMQ by
default.
Note: The programs will not be able to connect to the OS 2200 QProcessor if the
daemon run is not started.
E.1.2. Using the Daemon Keyin
The daemon keyin is used to send administrative commands from the system console
or from a demand terminal that has console keyin privileges. All input is converted to
uppercase. If you want to use daemon to administer your WMQ2200 system, use only
uppercase.
Format
@@CONS keyin-id command[,option] [parameters]
3843 3744–002 E–1

WMQ2200 Daemon Administrative Utility
Parameters
keyin-id is the keyin prefix configured for the WMQ2200 administrative background
run, DaemonKeyId. The default is WMQ, but you can configure WMQ2200 to use a
different keyin prefix. Refer to Section 2, "Installation and Configuration," for more
information.
command is one of the following commands:
APISTATUS Prints WMQ2200 subsystem status and API connection
information.
CORE Generates a WMQ2200 subsystem core dump for debugging.
DOWN Disconnects the WMQ2200 subsystem from the OS 2200
QProcessor.
FORCE STOP Same as SHUTDOWN, except that it also terminates the connect
to the OS 2200 QProcessor even if there are connected MQ
activities.
HELP Displays valid keyins or provides help with a specific keyin if
specified.
ICLOG Adjusts the Interconnect log/trace level.
MQLOG Adjusts the WMQ2200 subsystem log/trace level.
OHIGH Changes the maximum number of activities allowed to use the
WMQ2200 API at any given time.
OLOW Changes the minimum number of servicing applications.
SHUTDOWN Shuts down the WMQ2200 daemon background run.
START* Starts one queue manager or all created queue managers.
STATS Used to turn on and off statistics on current API usage.
STATUS* Shows active and inactive queue managers, or displays more
detailed information.
TERM* Terminates one queue manager or all queue managers.
UP Enables API for use.
VERSION* Displays the current version of the software.
Note: * indicates a command previously supported through the MQAdmin
Administration Utility.
option specifies an option on the command. For details, see the following information
blocks.
parameters are optional parameters available for some commands, as noted below.
E–2 3843 3744–002

APISTATUS
CORE
WMQ2200 Daemon Administrative Utility
The command displays information about the current WMQ2200 subsystem and API
background daemon status.
Format
@@CONS keyin-id APISTATUS
Example
>@@CONS WMQ APISTATUS
This responds with output similar to the following:
STATUS:
-------------------------------
Connection Status: Connected
Configuration:
QProcessor IP/Hostname: 192.63.222.48
QProcessor Port: 22719
RealTime Level: 0
API trace: Enabled
API log level (OS2200): MQ_VERBOSE
IC log level (OS2200): IC_VERBOSE
IC log level (QProc): IC_VERBOSE
Offloads In Use: 1
Low Offload Count: 100
High Offload Count: 100
Max Offload Count: 1000
Statistics: Disabled
Automatic Reconnect: Yes
Currently Retrying: No
Reconnect Interval: 4
IC Version: 18
Build Level: 1922
The command generates a diagnostic dump of the WMQ2200 subsystem.
Format
@@CONS keyin-id CORE
Example
>@@CONS WMQ CORE
This responds with output similar to the following:
User requested MQ core request completed.
3843 3744–002 E–3

WMQ2200 Daemon Administrative Utility
DOWN
This terminates the connection with the OS 2200 QProcessor and disables the API link
in the OS 2200 QProcessor. The UNX shell processor is not affected by the DOWN
keyin and continues to function. Only the OS 2200 user application connectivity with
the WebSphere MQ API is affected. This is an administrative way to stop all
WebSphere MQ API activity between OS 2200 and the OS 2200 QProcessor.
Format
@@CONS keyin-id DOWN
Example
FORCE STOP
>@@CONS WMQ DOWN
This responds with output similar to the following:
Attempting to down IC - please wait.
This may take a minute if there are MQ activities.
IC disconnected from QProcessor.
Automatic reconnects are now disabled.
Or the following message appears if the IC is down already:
IC already disconnected.
This command is same as the SHUTDOWN keyin, except it shuts down the daemon
and terminates the connection to the OS 2200 QProcessor even if there are
connected MQ activities (like trigger monitors) using the connection to communicate
with the OS 2200 system.
Format
@@CONS keyin-id FORCE STOP
Example
>@@CONS WMQ FORCE STOP
This responds with output similar to the following:
> WMQ$ daemon terminating.
> Daemon may take a minute to end.
> WMQ$ daemon terminated.
E–4 3843 3744–002

HELP
ICLOG
WMQ2200 Daemon Administrative Utility
This command lists valid keyin commands that the daemon accepts or displays usage
for a specific command if requested.
Format
@@CONS keyin-id HELP [command]
Examples
The following example displays a list of the available commands:
>@@CONS WMQ HELP
The following example displays help information about APISTATUS command:
>@@CONS WMQ HELP APISTATUS
This command alters the level of verbosity in logging or tracing in the Interconnect
library code and possibly the WMQ2200 offload code running on the OS 2200
QProcessor, depending on what ICLOG level you change.
If you change only the OS 2200 ICLOG level, it affects the Interconnect library code
and the WMQ2200 offload code running on the OS 2200 QProcessor. If you change
the OS 2200 QProcessor ICLOG level, it affects the Interconnect library code and
possibly the WMQ2200 offload code running on the OS 2200 QProcessor. You can
also change both the OS 2200 Interconnect library, OS 2200 QProcessor Interconnect
library, and MQ service offload program log levels at the same time.
Format
MQS ICLOG [component]
Valid levels are:
LOG ONLY
AUDIT
DEBUG
VERBOSE
The levels () are listed in order of least to most verbose. The LOG ONLY level
only generates logs to the DDP log file. All other levels generate traces in increasing
verbosity to the DDP trace file. The LOG ONLY level must be used normally, unless
you need to use trace to debug a problem.
3843 3744–002 E–5

WMQ2200 Daemon Administrative Utility
MQLOG
Valid optional components are:
• BOTH – Default, log level for the OS2200, Linux IC and offload log level are
changed.
• 2200 – Only OS2200 IC log level is changed.
• LINUX – Only the Linux IC log level and offload program log level is changed
Examples
The following message appears if you specify a valid log level and no component:
>@@CONS WMQ ICLOG VERBOSE
Log level changed to IC_VERBOSE.
The following message appears if you specify a valid log level and a component:
>@@CONS WMQ ICLOG 2200 DEBUG
Log level changed to IC_DEBUG.
This command alters the MQLOG level, the level of verbosity in logging or tracing for
WMQ2200 only.
Format
@@CONS keyin-id MQLOG
Valid levels are:
LOG ONLY
AUDIT
DEBUG
VERBOSE
The levels () are listed in order of least to most verbose. The LOG ONLY level
only generates logs to the DDP log file. All other levels generate traces in increasing
verbosity to the DDP trace file. The LOG ONLY level must be used normally, unless
you need to use trace to debug a problem.
Example
>@@CONS WMQ MQLOG LOG ONLY
Log level changed to MQ_LOG_ONLY
E–6 3843 3744–002

OHIGH
OLOW
WMQ2200 Daemon Administrative Utility
This command alters the high offload count in the Interconnect. This number cannot
be larger than the offload max value which can be displayed with the APISTATUS
command. This controls the number of OS2200 activities that can use the API link to
the OS 2200 QProcessor at the same time.
Format
@@CONS keyin-id OHIGH
Example
>@@CONS WMQ OHIGH 200
Changed offload high count to 200
This command alters the low offload count in the Interconnect. This defines the
lowest number of offloads to keep running on the OS 2200 QProcessor to service
OS 2200 activities. If the number is too low, new service processes on the OS 2200
QProcessor need to be started dynamically to handle the extra load.
Format
@@CONS keyin-id OLOW
Example
SHUTDOWN
>@@CONS WMQ OLOW 80
Changed offload low count to 80
This command terminates the DAEMON background process itself.
Format
@@CONS keyin-id SHUTDOWN
Example
>@@CONS WMQ SHUTDOWN
This responds with output similar to the following:
> WMQ$ daemon terminating.
> Daemon may take a minute to end.
> WMQ$ daemon terminated.
3843 3744–002 E–7

WMQ2200 Daemon Administrative Utility
START
STATS
This command starts one queue manager or starts every queue manager that has
been created within your WMQ2200 system.
Note: The MQAuthority parameter determines whether OAM is enabled for a
queue manager when it was created. Refer to Section 2, "Installation and
Configuration," for more information.
Formats
@@CONS keyin-id START queuemanager
@@CONS keyin-id START ALL
Parameter
queuemanager is the name of a specific queue manager you want to start.
Examples
The following example starts the queue manager named QM1.
>@@CONS WMQ START QM1
The following example starts all queue managers that were created using the crtmqm
command, but which are not currently started.
>@@CONS WMQ START ALL
This command displays the current API statistics, if enabled. Statistics can be gathered
in WMQ2200 to track the level of activity.
Format
@@CONS keyin-id STATS
Example
>@@CONS WMQ STATS
The following message appears if statistics are currently disabled:
Statistics are disabled.
E–8 3843 3744–002

STATS ON
This command turns on WMQ2200 API usage statistics.
Format
@@CONS keyin-id STATS ON
Example
STATS OFF
>@@CONS WMQ STATS ON
Statistics enabled.
This command turns off WMQ2200 API usage statistics.
Format
@@CONS keyin-id STATS OFF
Example
STATS RESET
STATUS
>@@CONS WMQ STATS OFF
Statistics disabled.
WMQ2200 Daemon Administrative Utility
This command resets all WMQ2200 API usage statistics counters to zero.
Format
@@CONS keyin-id STATS RESET
Example
>@@CONS WMQ STATS RESET
Statistics cleared.
This command retrieves information about your queue managers within your
WMQ2200 system.
Formats
@@CONS keyin-id STATUS
@@CONS keyin-id STATUS queuemanager CHANNEL(genericchannelname)
[parameters]
@@CONS keyin-id STATUS queuemanager CHSTATUS(genericchannelname)
[parameters]
3843 3744–002 E–9

WMQ2200 Daemon Administrative Utility
@@CONS keyin-id STATUS queuemanager PROCESS(genericprocessname)
[parameters]
@@CONS keyin-id STATUS queuemanager QMGR [parameters]
@@CONS keyin-id STATUS queuemanager QUEUE(genericqname) [parameters]
Parameters
queue manager is the name of a specific queue manager for which you want to get
information.
generic channel name is the name of the channel for which definition or status
information is to be displayed.
generic process name is the name of the process definition to be displayed.
generic q name is the name of the queue definition to be displayed.
Note: The designators generic channel name, generic process name, and generic q
name can also be used to designate multiple channels, processes, or queues,
respectively. Refer to the standard MQSeries documentation for information on the
various MQSC DISPLAY commands.
parameters are optional parameters available for some of the STATUS command
formats. See “Parameters” at the beginning of this section for an explanation of the
parameters.
The following simple format displays the status of each queue manager currently
created in your WMQ2200 system:
>@@CONS keyin-id STATUS
This responds with output similar to the following:
Queue manager status information
--------------------------------
Running:QM1
Running:QM2
Ended immediately:QM3
The complex forms of the WMQ2200 STATUS command correspond directly to
various standard MQSeries command interface (MQSC) DISPLAY commands. For
example,
>@@CONS keyin-id STATUS queuemanager QUEUE(genericqname) [parameters]
is functionally equivalent to
>DISPLAY QUEUE(genericqname) [parameters]
E–10 3843 3744–002

Examples
WMQ2200 Daemon Administrative Utility
The following examples list the STATUS command, then the equivalent DISPLAY
command, followed by an example of the output.
>@@CONS WMQ STATUS QM3 QMGR (display queue manager attributes
for QM3)
>runmqsc QM3
>display qmgr
AMQ8408: Display Queue Manager details.
QMNAME(QM3) ACCTCONO(DISABLED)
ACCTINT(1800) ACCTMQI(OFF)
ACCTQ(OFF) ACTIVREC(MSG)
ALTDATE(2009-03-31) ALTTIME(16.38.45)
AUTHOREV(DISABLED) CCSID(1208)
CHAD(DISABLED) CHADEV(DISABLED)
CHADEXIT( ) CHLEV(DISABLED)
CLWLDATA( ) CLWLEXIT( )
CLWLLEN(100) CLWLMRUC(999999999)
CLWLUSEQ(LOCAL) CMDLEVEL(600)
COMMANDQ(SYSTEM.ADMIN.COMMAND.QUEUE) CRDATE(2009-03-31)
CRTIME(16.38.45) DEADQ( )
DEFXMITQ( ) DESCR( )
DISTL(YES) INHIBTEV(DISABLED)
IPADDRV(IPV4) LOCALEV(DISABLED)
LOGGEREV(DISABLED) MAXHANDS(256)
MAXMSGL(4194304) MAXPRTY(9)
MAXUMSGS(10000) MONACLS(QMGR)
MONCHL(OFF) MONQ(OFF)
PERFMEV(DISABLED) PLATFORM(UNIX)
QMID(QM3_2009-03-31_16.38.45) REMOTEEV(DISABLED)
REPOS( ) REPOSNL( )
ROUTEREC(MSG) SCHINIT(QMGR)
SCMDSERV(QMGR) SSLCRLNL( )
SSLCRYP( ) SSLEV(DISABLED)
SSLFIPS(NO)
SSLKEYR(/var/mqm/qmgrs/QM3/ssl/key)
SSLRKEYC(0) STATACLS(QMGR)
STATCHL(OFF) STATINT(1800)
STATMQI(OFF) STATQ(OFF)
STRSTPEV(ENABLED) SYNCPT
TRIGINT(999999999)
>@@CONS WMQ STATUS QM1 QUEUE(QUEUE1) TRIGGER,TRIGDPTH (display
whether
triggers are
active,
>runmqsc QM1 and the trigger
>display queue(QUEUE1) trigger,trigdpth depth, for
queue QUEUE1 in
queue manager
QM1)
3843 3744–002 E–11

WMQ2200 Daemon Administrative Utility
AMQ8409: Display Queue details.
QUEUE(QUEUE1) NOTRIGGER
TRIGDPTH(1)
>@@CONS WMQ STATUS QM2 QUEUE(*) TYPE(QLOCAL) CURDEPTH (display the
Current depth
for all local
>runmqsc QM2 queues in queue
>display queue(*) type(qlocal) curdepth manager QM2)
AMQ8409: Display Queue details.
QUEUE(SYSTEM.ADMIN.CHANNEL.EVENT) CURDEPTH(0)
AMQ8409: Display Queue details.
QUEUE(SYSTEM.ADMIN.COMMAND.QUEUE) CURDEPTH(0)
AMQ8409: Display Queue details.
QUEUE(SYSTEM.ADMIN.PERFM.EVENT) CURDEPTH(0)
AMQ8409: Display Queue details.
QUEUE(SYSTEM.ADMIN.QMGR.EVENT) CURDEPTH(1)
AMQ8409: Display Queue details.
QUEUE(SYSTEM.CHANNEL.INITQ) CURDEPTH(0)
AMQ8409: Display Queue details.
QUEUE(SYSTEM.CHANNEL.SYNCQ) CURDEPTH(0)
AMQ8409: Display Queue details.
QUEUE(SYSTEM.CICS.INITIATION.QUEUE) CURDEPTH(0)
AMQ8409: Display Queue details.
QUEUE(SYSTEM.CLUSTER.COMMAND.QUEUE) CURDEPTH(0)
AMQ8409: Display Queue details.
QUEUE(SYSTEM.CLUSTER.REPOSITORY.QUEUE)
CURDEPTH(1)
AMQ8409: Display Queue details.
QUEUE(SYSTEM.CLUSTER.TRANSMIT.QUEUE) CURDEPTH(0)
AMQ8409: Display Queue details.
QUEUE(SYSTEM.DEAD.LETTER.QUEUE) CURDEPTH(0)
AMQ8409: Display Queue details.
QUEUE(SYSTEM.DEFAULT.INITIATION.QUEUE)
CURDEPTH(0)
AMQ8409: Display Queue details.
QUEUE(SYSTEM.DEFAULT.LOCAL.QUEUE) CURDEPTH(0)
For further information on using the complex forms of the STATUS command, refer to
the standard MQSeries documentation for the MQSC commands DISPLAY CHANNEL,
DISPLAY CHSTATUS, DISPLAY PROCESS, DISPLAY QMGR, and DISPLAY QUEUE.
E–12 3843 3744–002

TERM
UP
This command terminates one or all queue managers.
Formats
@@CONS keyin-id TERM[,option] queue-manager
@@CONS keyin-id TERM[,option] ALL
Parameters
WMQ2200 Daemon Administrative Utility
option is a single letter denoting the type of termination to perform on the queue
manager or queue managers. It corresponds to the -c, -i, and -p options on the control
command endmqm and is available through the UNX interface:
C Controlled (or quiesced) shutdown (default)
I Immediate shutdown
P Preemptive shutdown
queue-manager is the name of a specific queue manager you want to terminate.
Examples
The following example terminates a single, named queue manager with immediate
shutdown.
>@@CONS WMQ TERM,I QM1
The following example terminates all started queue managers with a controlled
shutdown.
>@@CONS WMQ TERM ALL
This command reconnects the API daemon to the OS 2200 QProcessor after the
connection has been terminated with a DOWN keyin or was lost because of an error.
Format
@@CONS keyin-id UP
Example
>@@CONS WMQ UP
The output depends on whether the connection to OS 2200 QProcessor is already
active or not and whether the attempt to connect succeeds.
3843 3744–002 E–13

WMQ2200 Daemon Administrative Utility
VERSION
This command displays information about the version of WMQ2200 you are using.
Format
@@CONS keyin-id VERSION
Example
>@@CONS WMQ VERSION
This responds with output similar to the following:
Websphere MQ Version: 6.0.2.8
Unisys release: 6R1
Internal level: 1682
Linux Host: ustr-stampede
OS2200 Host: RS18
E–14 3843 3744–002

Appendix F
UNX Shell
F.1. Using the UNX Shell
The UNX shell is an OS 2200 program that allows OS 2200 users to administer and
manage WMQ2200. It includes
• Linux commands to traverse the file system and query system information
• WebSphere MQ administrative commands to administer and manage WebSphere
MQ and various utilities.
UNX shell commands can be run in a demand session or included in batch runstreams.
The format of the UNX program is as follows:
*MQS$EXE.UNX
Where QUAL is the qualifier used for WMQ2200 files. The default is WMQ$.
Throughout this book, the WMQ$ qualifier is used on all examples.
The OS 2200 user ID that runs the UNX shell must be mapped to an OS 2200
QProcessor user and group. This can be done using the OS 2200 QProcessor
Administration Console Manage User Mappings module as described in section 3.
Depending on the OS 2200 QProcessor group association, some UNX commands
might not be available. In order to access the complete set of UNX commands, ensure
the OS 2200 user ID is mapped to the OS 2200 QProcessor local mqm group.
F.2. Using the Asterisk in the UNX Shell
When using an asterisk in the UNX shell, you must surround it with quotes or use a
backslash (\) escape sequence when it is an option given to a WebSphere MQ control
command. However, when you use the asterisk as a wildcard character to UNX
commands that interact with files, such as the ‘cat’ command, you cannot use the
quotes or escape sequence.
Examples
cat /var/mqm/errors/*.LOG
rcdmqimg -m qm2 -t all "*"
rcdmqimg -m qm2 -t all \*
3843 3744–002 F–1

Special Character Handling
F.3. Special Character Handling
The characters ‘&’ (ampersand) and ‘!’ (exclamation point) have a special meaning in
the UNX demand processor. Because of this, when either is part of a directory or file
name, you must use a backslash (\) escape sequence when attempting to use them as
parameters or options to a command. The following demonstrates how to access
directories and files that contain these characters in their names or paths.
Examples
cd /var/mqm/qmgrs/PERIOD\!QMGR
cat /var/mqm/qmgrs/PERIOD\!QMGR/errors/AMQERR01.LOG
cd /var/mqm/qmgrs/SLASH\&QMGR
cat /var/mqm/qmgrs/SLASH\&QMGR/errors/AMQERR01.LOG
F.4. Terminating Input to the runmqdlq Control
Command
The runmqdlq control command starts the dead-letter queue (DLQ) handler, a utility
that you can run to monitor and handle messages on a dead-letter queue. In
WebSphere MQ for Linux, if the DLQ handler is used without redirecting stdin from a
file, the DLQ handler reads input from the keyboard, but does not start to process the
named queue until it receives an end_of_file (Ctrl+D) character. However, in the
OS 2200 environment, the Ctrl+D character is unavailable. Instead, use @eof on a line
by itself.
F.5. Using the Paging Function in the UNX
Processor
The UNX demand processor includes a paging function that allows you to view
documents and certain program output on a page by page basis. The tool allows you
to move backward and forward through the output you are viewing. The command is
an implementation of the less command on UNIX and Linux variants.
Commands that Use the Paging Functionality
You can use the paging function to view file contents by using less command:
>@WMQ$*MQS$EXE.UNX
>less /var/mqm/mqs.ini
The paging function is also used when you use the –p option on the following UNX
commands:
F–2 3843 3744–002

Using the Paging Function in the UNX Processor
Command Description
ps Displays a process listing
dumpini Dumps the contents of the WebSphere MQ configuration files
cat Displays a file
logs Displays WebSphere MQ queue manager error logs
errors Displays WebSphere MQ global error logs and FFST files
The paging function can also be used to display any command output on a
page-by-page basis by using the pipe operator to redirect the output into the less
utility:
>@WMQ$*MQS$EXE.UNX
>fileinfo | less
Using the Paging Functionality
When you use the paging functionality, you must terminate the paging program when
you are finished to return to the UNX shell prompt. When you are at the UNX shell
prompt, you will see your process ID (PID) in the prompt:
1003>
When you are in the paging function, you will see only a colon in the prompt:
:>
If you are on the last page of the output, you will see the following prompt:
(END)>
You must exit the paging function before you can continue using UNX shell and
WebSphere MQ control commands.
The following table lists common pager commands and their description:
Table F–1. Common Pager Commands
Command Description
b Back one page
f Forward one page
q Terminate the paging
function and return to the
shell
3843 3744–002 F–3

UNX Commands
F.6. UNX Commands
The UNX shell supports three command categories:
• Linux type shell commands
• WMQ2200 utilities
• MQ Series Commands
F.6.1. Linux Type Shell Commands
The following table shows the Linux type shell commands that are allowed to be
entered through the UNX shell. For more detailed information on these commands,
use the UNX shell and the ? command.
?
The following table lists Linux type shell commands and their description:
Table F–2. Linux Type Shell Commands
Command Description
cat Displays the contents of a file.
cd Changes the directory.
chmod Changes the files Linux privileges for either owner, group or
other.
chown Changes owner of a file.
cp Copies files.
del Deletes files.
dir Displays file directory.
date Returns the time and date of the OS 2200 QProcessor.
echo Prints what the user has requested to be echoed.
exit Exits the UNX shell.
help
Allows the user to view a list of commands and get specific
help on an individual command.
hostname Displays the host name of the OS 2200 QProcessor.
ls Lists all files in the current directory.
md Makes a new directory.
mkdir Makes a new directory.
F–4 3843 3744–002

PS
Table F–2. Linux Type Shell Commands
Command Description
UNX Commands
more This command is used with paging a long output, for instance
from a cat command. It allows the display to be read a page at a
time.
ps Displays process information.
pwd Displays current directory.
rename Allows the renaming of files.
rm Permanently removes a file.
rmdir Permanently removes a directory.
set Allows you to set or unset an environment variable.
sleep Suspends operations of a UNX shell script.
time Prints system time.
trace Traces this session of the UNX shell.
whoami Displays the OS 2200 user ID.
whoamilx Displays the Linux user ID.
To obtain supplemental information about the active users and processes in
WMQ2200, use the ps command.
By default, ps displays information about all processes associated with WMQ2200. It
displays the user ID (RUSER), the parent process ID (PPID), the process ID (PID), the
process state of the process (STAT), the wall time of the process (ELAPSED), and the
executable name with its arguments (COMMAND).
Formats
ps
ps [options]
ps --mq=opts
ps –help
Note: Some options might not work together.
Parameters
Various options and formats are available. For full documentation, use the help ps
command in the UNX shell to display the online ps manual. Use the ps –help command
to display a summary help page.
3843 3744–002 F–5

UNX Commands
You can use the --mq option to select WebSphere MQ processes matching a given
selection criteria. The following table lists parameters and their description.
Parameter Description
a Agents
c Channels
l Listeners
q Queue managers
You can specify any or all of a, c, l, and q in the form:
ps –mq=al
Special Option Description
--help Print usage page
--all Print all processes on the OS 2200 QProcessor
--hidden Display unassigned offloads
Example
@WMQ$*MQS$EXE.UNX
>ps –mq=q
>RUSER PPID PID TID STAT ELAPSED COMMAND
>mqm 1 15758 15758 Ssl 00:06 amqzxma0 -m MY.QMGR
The following is a list of process state codes that might be displayed in the ST (status)
field:
D Uninterruptible sleep (usually IO)
R Running or runable (on run queue)
S Interruptible sleep (waiting for an event to complete)
T Stopped, either by a job control signal or because it is being
traced
X Dead (must never be seen)
Z Defunct ("zombie") process, terminated but not reaped by its
parent
< High-priority
N Low-priority
L Has pages locked into memory (for real-time and custom IO)
s Is a session leader
I Is a multi-threaded
+ Is in the foreground process group
F–6 3843 3744–002

F.6.2. MQ Series Commands
The following table lists MQ Series commands and their description:
Table F–3. MQ Series Commands
Command Description
amqhasmx Logger for a queue manager
amqiclen Checks no IPC resources is present
amqldmpa Dumps match space
amqoamd Creates authorization definitions for queue manager
objects
amqpcsea PCF command processor
amqrcmla Channel MQSC and PCF command processor
amqrmppa Channel process pooling job
amqrrmfa Repository manager for clusters
amqsstop Requests queue manager to break all connections for
the process ID
amqzdmaa Deferred message handler
amqzfuma Object authority manager (OAM)
amqzlaa0 Agents for a queue manager
amqzllp0 Checkpoint processor for a queue manager
amqzlsa0 Agents for a queue manager
amqzlwa0 WorkLoad Management server
UNX Commands
amqzmgr0 Process controller used to start up and manage listeners
and services
amqzmuc0 Critical process manager
amqzmur0 Restartable process manager
amqzslf0 Stop-all-channels process
amqzxma0 Execution controller for a queue manager
clrmqbrk Removes knowledge of queue manager
crtmqcvx Creates fragment of data conversion code
crtmqm Creates a queue manager
dltmqbrk Deletes the broker
dltmqm Deletes a queue manager
dmpmqaut Dumps the current authorizations
dmpmqlog Dumps formatted version of WebSphere MQ system log
3843 3744–002 F–7

UNX Commands
Table F–3. MQ Series Commands
Command Description
dspmq Displays queue manager status
dspmqaut Displays current authorizations
dspmqbrk Displays broker status
dspmqcsv Displays the command server status
dspmqfls displays WebSphere MQ files
dspmqtrc Displays formatted trace output
dspmqtrn Displays WebSphere MQ transactions
dspmqver Displays WebSphere MQ version and build information.
endmqbrk Stops a broker
endmqcsv Ends the command server
endmqlsr Ends all listener processes for a queue manager
endmqm Ends a queue manager
endmqtrc Ends WebSphere MQ trace
ffstsummary Displays FFST summary
migmqbrk Migrates a WebSphere MQ Publish/Subscribe broker
mqrc Displays reason code name
mqver Displays WebSphere MQ product version number
rcdmqimg Records media image for a queue manager
rcrmqobj Recreates object for a queue manager
rsvmqtrn Resolves WebSphere MQ transactions
runmqbrk Broker control job
runmqchi Channel initiator
runmqchl Starts for each sender channel
runmqdlq Dead letter queue handler
runmqlsr Threaded TCP/IP listener
runmqsc MQ Command interface
runmqtrm Trigger monitor
setmqaut Sets or resets authority
strmqbrk Starts a broker
strmqcsv Starts a command server
strmqm Starts a queue manager
strmqtrc Starts WebSphere MQ trace
F–8 3843 3744–002

F.6.3. UNX Utilities
The following table lists the utilities that are available from the UNX shell.
Table F–4. UNX Utilities
Utility Description
buildexit Allows the coding of WMQ exit routines in OS 2200
editors. The utility will compile and install the exit
routines in the correct directory on the OS 2200
QProcessor.
core Takes a WMQ2200 core dump.
cpuinfo Returns OS 2200 QProcessor cpu information.
diskinfo Returns OS 2200 QProcessor disk information.
dspmqtrn_all Runs dspmqtrn on all queue processors.
dumpini Prints qm.ini for all queue managers.
errors Returns the contents of the /var/mqm/errors directory.
fileinfo Returns the /var/mqm file information.
fixwebminlog This adds all queue mangers logs to the View Logs
module in the Administration Console. This is used only
if the view of the logs are accidently deleted.
groupadd Adds groups to the OS 2200 QProcessor.
groupdel Deletes groups from the OS 2200 QProcessor.
grouplist Lists groups on the OS 2200 QProcessor.
groupmembers Lists all members of the OS 2200 QProcessor groups.
identity Prints the users identify information.
init Initializes the /var/mqm file system.
init-migrate Repairs the MQ file system in a non-destructive manner.
listcores Returns a list of all WMQ2200 and Interconnect core
files.
logs Returns the contents of a particular queue manager log
or all queue manager logs.
meminfo Prints OS 2200 QProcessor memory information.
mqexport Copies a file from the OS 2200 QProcessor to the
OS 2200.
mqimport Copies a file from the OS 2200 to the OS 2200
QProcessor.
mqload Restores previous backed up queue manager data.
mqloadlog Restores previous achieved linear log files.
mqsave Backs up given queue manager data to the OS 2200 file.
UNX Commands
3843 3744–002 F–9

UNX Utility Command Reference
Table F–4. UNX Utilities
Utility Description
mqsavelog Archives linear log queue manager data.
mquseradd Adds mapping to the OS 2200 QProcessor for OS 2200
users.
mquserdel Removes OS 2200 QProcessor user mapping.
mquserlist Lists all OS 2200 QProcessor user mappings.
mqusermod Modify the local group for an OS 2200 QProcessor user
mapping.
rootmod Adds or removes the root user from the MQM group.
saveqmgr Displays a queue manager’s object definitions.
saveqmgr_all Runs the saveqmgr command for all queue managers.
ss Displays information on IPC system facilities.
sysinfo Prints OS 2200 QProcessor system status information.
ted Allows editing of files with the TED editor.
uname Prints OS 2200 QProcessor system summary
information.
uptime Returns how long the OS 2200 QProcessor has been up.
usysreport Generates an OS 2200 QProcessor Usysreport.
whoami Displays the OS 2200 user information on the current
UNX user.
whoamilx Displays the OS 2200 QProcessor user and group for the
current UNX user.
F.7. UNX Utility Command Reference
buildexit
The following can be used as a reference for the UNX utility commands.
This command takes an exit route from the OS 2200, builds it using gcc and installs it
on Linux into /var/mqm/exits64.
Format
buildexit [OPTION]... [FILE]
F–10 3843 3744–002

core
cpuinfo
Parameter
UNX Utility Command Reference
-o Output exit name. This is the name of the exit routine. It will be
installed in /var/mqm/exits64 directory. This option is required.
-l Additional libraries needed for the gcc compile.
-v Verbose option for debugging.
FILE must be in the OS 2200 format. Either an SDF file or fully qualified element
name is accepted (2200qual*filename.elt).
This command creates a PADS formated diagnostic memory dump. The core
command forces a Programmers Advanced Debugging System (PADS) dump into a
file. The name of the file is displayed in a message both to the user's screen and to the
operator's console.
Format
core
Parameter
None
This command returns the OS 2200 QProcessor cpu information.
Format
cpuinfo
Parameter
None
Example
@WMQ$*MQS$EXE.UNX
>cpuinfo
>processor : 1
>vendor_id : GenuineIntel
>cpu family : 15
>model : 6
>model name : Genuine Intel(R) CPU 3.40GHz
>stepping : 8
>cpu MHz : 3400.016
>cache size : 16384 KB
>fpu : yes
>fpu_exception : yes
>cpuid level : 6
>wp : yes
3843 3744–002 F–11

UNX Utility Command Reference
diskinfo
>flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss sysc all nx lm
constant_tsc pni cx16 lahf_lm
>bogomips : 6819.55
>clflush size : 64
>cache_alignment : 128
>address sizes : 36 bits physical, 48 bits virtual
>power management:
This command in the UNX shell prints the disk usage information. You can use this
command to determine the remaining space in the WebSphere MQ partitions
/var/mqm and /var/mqm/log.
Format
diskinfo
Parameter
None
Example
dspmqtrn_all
@WMQ$*MQS$EXE.UNX
>diskinfo
>
>Filesystem Size Used Avail Use% Mounted on
>/dev/sdc2 149G 2.9G 139G 3% /var/mqm
>/dev/sdb3 149G 2.9G 139G 3% /var/mqm/log
This command runs dspmqtrn against all installed queue managers, displaying the
status of managed transactions for each queue manager to the screen. This program
is useful for gathering diagnostics.
Format
dspmqtrn_all
Parameter
None
F–12 3843 3744–002

dumpini
errors
fileinfo
UNX Utility Command Reference
This command prints qm.ini for all the queue managers and mqs.ini when a option is
used. You can also use this command to display a specific queue manager's qm.ini file.
Format
dumpini [-a] [-g] [-p] [-h] [gmgr-name]
Parameter
-a Prints all qm.ini and mqs.ini files
-g Prints mqs.ini file only
-p Prints the output one page at a time
-h Prints a help screen
This command returns the contents of the /var/mqm/errors directory. These files may
be paged for interactive viewing, otherwise run UNX in a breakpoint and save the
contents.
Format
errors –p
Parameter
-p prints the output one page at a time
This command prints the file usage information. Specifically, it prints all of the files in
the /var/mqm tree.
Format
fileinfo [–s]
Parameter
fixwebminlog
-s includes the size of each file of the /var/mqm tree
This command adds all queue managers to the view logs module in the OS 2200
QProcessor Administration Console. This is normally done on a queue manager basis
during a crtmqm create queue manager) command. However, there may be times all
need to be restored, for example after a user restores the default log entries in the
Administration Console. You must be mapped to root to perform this command.
Format
fixwebminlog
3843 3744–002 F–13

UNX Utility Command Reference
groupadd
groupdel
grouplist
Parameter
None
This command creates a new group entry using the name specified on the command
line. The group name must begin with an alphabetic character and the rest of the
string should be from the POSIX portable character class. A group must be added
before OS 2200 user IDs or remote user IDs are added. ([A-Za-z_][A-Za-z0-9_-.]*). You
must be mapped to root to perform this command.
Format
groupadd groupname
Parameter
groupname is the name of a valid group.
This command removes a group entry from the local system files. A primary group of
any existing user is not removeable. You must be mapped to root to perform this
command.
Format
groupdel groupname
Parameter
groupname is the name of a valid group.
This command prints a list of groups installed on the OS 2200 QProcessor. The format
is group:gid:members. By default system groups are hidden. You must be mapped to
root to perform this command.
Format
grouplist [-a]
Parameter
-a lists all groups including the system groups.
F–14 3843 3744–002

groupmembers
identity
init
UNX Utility Command Reference
This command prints a list of the members of the specified group. The group should
be specified by name, not by gid. Note that the root user is not listed in the
groupmembers output even if root is a member of the given group. The root user is a
member of the root group and possibly the mqm group.
Format
groupmembers groupname
Parameter
groupname is the name of a valid group to list the members.
Example
@WMQ$*MQS$EXE.UNX
>groupmembers mqm
gn
mqm
This command prints the current UNX users identity information including the OS2200
user ID, Linux user ID, and effective Linux group ID.
Format
identity
Parameter
None
Example
@WMQ$*MQS$EXE.UNX
>identity
OS2200 userid: gm
Linux identity: mqm
Effective group: mqm
This command initializes the /var/mqm file system. This command destroys all MQ
data, MQ queues, logs, errors, trace files, and configuration will be destroyed after
this command is executed. This command must be run by an OS 2200 user mapped as
root.
Format
init
3843 3744–002 F–15

UNX Utility Command Reference
Parameter
None
Init-migrate
listcores
This command repairs the MQ file system in a non-destructive manner. It is used to
repair the MQ file system if it has been damaged or deleted. It does not destroy
existing queue manager data. If you wish to reinitialize your file system, use the init
command instead.
This command is used when you know or believe all or part of the file system is
deleted, damaged, or permissions are changed. This will repair the MQ file system and
correct permissions changes. This command cannot recover queue manager or log
data that has been corrupted or destroyed. However, it can repair and replace the
/var/mqm tree that was installed when WMQ2200 was originally installed. This
command can only be run when MQ is not running and must be run by an OS 2200
user mapped as root.
Format
Init-migrate
Parameter
None
This command lists all core files generated by MQ or the Interconnect on the OS 2200
QProcessor.
Format
listcores
Parameter
None
F–16 3843 3744–002

logs
meminfo
UNX Utility Command Reference
This command returns the contents of the errors directory for all or a particular queue
manager. These files maybe paged for interactive viewing, otherwise run UNX in a
breakpoint and save the contents.
Format
logs
Parameter
None
This command dumps OS 2200 QProcessor memory information.
Format
meminfo [-v]
Parameter
-v Displays detailed memory information.
Example
@WMQ$*MQS$EXE.UNX
>meminfo
>total used free shared buffers cached
>Mem: 2012 743 1269 0 169 402
>-/+ buffers/cache: 171 1841
>Swap: 2055 0 2055
>Total: 4067 743 3324
Where
Total - Displays the total usable memory information (RAM)
Used - Amount of used memory
Free - Amount of unused memory
Shared - Total shared memory information
Buffers - Amount of memory used for file buffers
Cached - Amount of memory used as cache memory
Swap - Total amount of physical swap memory
3843 3744–002 F–17

UNX Utility Command Reference
mqexport
mqimport
mqload
The mqexport allows an OS 2200 user to get the contents of an ASCII file from the
OS 2200 QProcessor as an OS 2200 data file.
Format
mqexport source_file qual*file.
Parameters
The source_file is a required parameter that specifies the OS 2200 QProcessor file
from which the information is transferred.
qual*file. is a required parameter (which must end in a period) that specifies the
OS 2200 file into which the information is to be transferred. The qual*file. can
specify an existing catalogued or temporary program file. The qual*file. must
already exist. If the qualifier has a ‘$’ sign, make sure you have a “\” (backslash)
before issuing the $ sign. For example, if the qual*file. you want to use is
wmq$*out., then you will need to issue wmq\$*out.
This command allows an OS 2200 user to copy an ASCII from the OS 2200 to the
OS 2200 QProcessor.
Format
mqimport 2200-source-file destination-file
Parameters
The 2200-source-file is a required parameter (which must end in a period) that
specifies the OS 2200 file into which the information is to be transferred, it must
already exist. If the qualifier has a ‘$’ sign, make sure you have a “\” (backslash)
before issuing the $ sign.
The destination_file is a required parameter that specifies the OS 2200 QProcessor
file to which the information is transferred.
This command is used to restore the data for your queue manager to a saved point.
The mqload command is interactive and will prompt for the queue manager name. The
queue manager you specify does not need to exist, but must be inactive if it exists;
that is, it must not be currently running.
The mqload copies all of the relevant information for your queue manager from the
OS 2200 file qualifier*filename to the OS 2200 QProcessor system, effectively
overwriting the current queue manager data.
F–18 3843 3744–002

Format
mqloadlog
mqload qualifier*filename.
UNX Utility Command Reference
Note: The qmgr-name is prompted for when the command is run.
Parameters
qmgr-name is the name of the queue manager to restore.
qualifier*filename specifies the OS 2200 file from which you want to load all the
information for a queue manager. This file must exist on your system and must be
populated by a prior mqsave call. If the qualifier has a ‘$’ sign, make sure you have a
“\” (backslash) before issuing the $ sign.
Example
@WMQ$*MQS$EXE.UNX
>mqload wmq*qmbackup.
>Enter WebSphere MQ queue manager name
>QM1
>
>MQLOAD: Finished restoring data for queue manager 'QM1'
This command restores older, previously archived log files. mqloadlog copies
information from OS 2200 files saved by mqsavelog into a log file. This is a
nondestructive copy; OS 2200 files are not deleted or erased by this operation. The
mqloadlog is interactive and prompts for queue manager name and the range of logs
files needed.
Format
MQLOADLOG qualifier
Parameters
qualifier is the OS 2200 qualifier that was used with the mqsavelog. This is where
the previously archived log files were written.
Example
This example restores log files needed for media recovery.
@WMQ$*MQS$EXE.UNX
>mqloadlog abc
>Enter WebSphere MQ queue manager name.
>qm1
>Range of log files needed for media recovery: 0 through 3.
>Proceed with MQLoadLog on this range? (Y or N)
>y
>
>Target file is '/var/mqm/log/qm1/active/S0000000.LOG'
3843 3744–002 F–19

UNX Utility Command Reference
mqsave
>
>Copy ABC*S0000000. to file /var/mqm/log/qm1/active/S0000000.LOG
>mqloadlog: Transferred 270336 bytes to file/
var/mqm/log/qm1/active/S0000000.LOG
>
>Target file is '/var/mqm/log/qm1/active/S0000001.LOG'
>Copy ABC*S0000001. to file /var/mqm/log/qm1/active/S0000001.LOG
>mqloadlog: Transferred 270336 bytes to file
/var/mqm/log/qm1/active/S0000001.LOG
>
>Target file is '/var/mqm/log/qm1/active/S0000002.LOG'
>Copy ABC*S0000002. to file /var/mqm/log/qm1/active/S0000002.LOG
>mqloadlog: Transferred 270336 bytes to file
/var/mqm/log/qm1/active/S0000002.LOG
>
>Target file is '/var/mqm/log/qm1/active/S0000003.LOG'
>Copy ABC*S0000003. to file /var/mqm/log/qm1/active/S0000003.LOG
>mqloadlog: Transferred 270336 bytes to file /
var/mqm/log/qm1/active/S0000003.LOG
>
>END mqloadlog: 4 files copied for queue manager qm1.
This command is used to back up the data for a queue manager. The mqsave
command is interactive and will prompt for the queue manager name. The queue
manager you specify does not need to exist, but must be inactive if it exists; that is, it
must not be currently running.
The mqsave copies all of the relevant information for your queue manager to the file
you specify as qualifier*filename. You must ensure that the resulting file is stored in a
secure manner.
Format
mqsave qualifier*filename.
Parameters
qualifier*filename specifies the OS 2200 file into which you want to save all the
information for a queue manager. This output file must be a tape or mass storage
file that already exists on your system and must be large enough to hold
all the information for your queue manager. If the qualifier has a ‘$’ sign, make sure
you have a “\” (backslash) before issuing the $ sign.
Note: A queue manager created using ?crtmqm qmname? with all default values
and without being used needs approximately 3100 tracks of space. If you create
your queue manager such that it needs more space (for example, if you specify
more or larger log files), or if you have been using your queue manager to
process large amounts of data, you can create your target OS 2200 with a greater
maximum size.
F–20 3843 3744–002

mqsavelog
Example
@WMQ$*MQS$EXE.UNX
>mqsave wmq*qmbackup.
>Enter WebSphere MQ queue manager name
>QM1
>
>MQSAVE: Transferred 38621 bytes to file wmq*qmbackup.
UNX Utility Command Reference
This command removes excess log files for linear log queue managers. The name of
the queue manager and a qualifier needs to be entered. The qualifier is to be used for
the destination files. This is an interactive command that queries for the name of the
queue manager.
Format
mqsavelog [-i] [-d] qualifier [-s sgsfile]
Parameters
-i Displays which log files are candidate for archive.
-s Generates a set of SGSs to facilitate automation of the mqsavelog.
-d Deletes unneeded bz2 compressed log files.
sgsfile specifies the output location for SGSs generated when you use the s option.
The value you provide for sgsfile must be an OS 2200 data file or element name.
Examples
1. Requesting Information Only (i Option)
Use the i option for information only; mqsavelog displays information about which
files are candidates for archive. It is also helpful for determining which files you
must create prior to running mqsavelog to do the actual file transfers. The
information from the following example shows that you need to create four files,
named ABC*S0000000LOG. through ABC*S0000003LOG., and the size of the log
files you see is uncompressed.
This example uses the i option for information only.
@WMQ$*MQS$EXE.UNX
>mqsavelog-i abc
>Enter WebSphere MQ queue manager name.
>qm1
>
>S0000000.LOG requires target file ABC*S0000000LOG.
> Size in bytes: 473088. Size in tracks: 66
>
>S0000001.LOG requires target file ABC*S0000001LOG.
> Size in bytes: 473088. Size in tracks: 66
>
3843 3744–002 F–21

UNX Utility Command Reference
>S0000002.LOG requires target file ABC*S0000002LOG.
> Size in bytes: 473088. Size in tracks: 66
>
>S0000003.LOG requires target file ABC*S0000003LOG.
> Size in bytes: 473088. Size in tracks: 66
>
>MQSaveLog can export 4 files for queue manager qm1.
>
>END MQSaveLog: 4 files found for queue manager qm1.
2. Requesting Information in SGS Format (s Option)
Use the s option and the sgsfile parameter to generate a set of SGSs to facilitate
automation of the mqsavelog utility.
When the s option and sgsfile are given, mqsavelog produces a set of SGSs in this
form:
LOG SEQ,seqnum-1 TRACKS,tracks FILE,qual*Sseqnum-1LOG.
LOG SEQ,seqnum-2 TRACKS,tracks FILE,qual*Sseqnum-2LOG.
...
MQSAVELOG COUNT,num
where:
seqnum-n are the log sequence numbers for the LOG SGSs.
tracks is the size in tracks, required for the given OS 2200 target file. The size of
the log files is uncompressed.
qual is the qualifier for the target OS 2200 files for log file transfer, as specified on
the mqsavelog call line.
num is the number of LOG SGSs in the log file.
For example:
@WMQ$*MQS$EXE.UNX
>mqsavelog -s ABC tpf$.sgs
>Enter WebSphere MQ queue manager name.
>qm1
>
>mqsavelog: Transferred 200 bytes to file tpf$.sgs
>
>END mqsaveLog: 4 files found for queue manager qm1.
LOG SEQ,0000000 TRACKS,66 FILE,ABC*S0000000LOG.
LOG SEQ,0000001 TRACKS,66 FILE,ABC*S0000001LOG.
LOG SEQ,0000002 TRACKS,66 FILE,ABC*S0000002LOG.
LOG SEQ,0000003 TRACKS,66 FILE,ABC*S0000003LOG.
MQSAVELOG COUNT,4
F–22 3843 3744–002

UNX Utility Command Reference
Typically, you call mqsavelog first with the s option and sgsfile to generate SGSs,
and then call a skeleton you have written to process the SGSs and create the
necessary OS 2200 target files. You can then call mqsavelog again with no options
to transfer the file information (see “Moving the Data (No Options)”).
3. Moving the Data (No Options)
When you have created the necessary target files, you can call mqsavelog again
with no options to move the data. Note that the log files are stored in bz2
compressed format. If you need to extract the data you must use a bz2
compression utility.
Note: If you answer "y" to the "Do you want to delete linear log files /n,"
question, mqsavelog deletes older log file information from your OS 2200
QProcessor. Therefore, ensure that your target save files are secure and
archived. WMQ2200 might need them in the event of a media recovery
situation.
Continuing with the previous example, this example moves the information.
>@cat,p abc*s0000000log.,///66
>I:002333 CAT complete.
>@cat,p abc*s0000001log.,///66
>I:002333 CAT complete.
>@cat,p abc*s0000002log.,///66
>I:002333 CAT complete.
>@cat,p abc*s0000003log.,///66
>I:002333 CAT complete.
@WMQ$*MQS$EXE.UNX
>mqsavelog abc
>Enter WebSphere MQ queue manager name.
>qm1
> Do you want to delete linear log files /n?
>y
>
>Processing candidate file S0000000.LOG
>Size in bytes: 6380. Size in tracks: 1
>mqsavelog: Transferred 270336 bytes to file ABC*S0000000LOG.
>Deleted log file /var/mqm/log/qm1/active/S0000000.LOG
>
>Processing candidate file S0000001.LOG
>Size in bytes: 6380. Size in tracks: 1
>mqsavelog: Transferred 270336 bytes to file ABC*S0000001LOG.
>Deleted log file /var/mqm/log/qm1/active/S0000001.LOG
>
>Processing candidate file S0000002.LOG
>Size in bytes: 6380. Size in tracks: 1
>mqsavelog: Transferred 270336 bytes to file ABC*S0000002LOG.
>Deleted log file /var/mqm/log/qm1/active/S0000002.LOG
>
>Processing candidate file S0000003.LOG
>Size in bytes: 6380. Size in tracks: 1
3843 3744–002 F–23

UNX Utility Command Reference
mquseradd
>mqsavelog: Transferred 270336 bytes to file ABC*S0000003LOG.
>Deleted log file /var/mqm/log/qm1/active/S0000003.LOG
>
>mqsaveLog moved 4 files for queue manager qm1.
>
>END mqsaveLog: 4 files found for queue manager qm1.
4. Delete Compressed Log Files (d Option)
Use the d option to delete the unnecessary bz2 compressed log files. These are
the log files that have been archived to the OS 2200 system without deleting from
the OS 2200 QProcessor.
If you answered ‘n’ to the following question, you might have bz2 compressed log
files:
>Do you want to delete linear log files /n?
For example,
@WMQ$*MQS$EXE.UNX
>mqsavelog -d ABC
>Enter WebSphere MQ queue manager name.
>qm1
This command adds either a remote user ID to the OS 2200 QProcessor or an OS 2200
user IDto the Interconnect USERMAP file for access rights to MQ queues. Each
remote or OS 2200 user must be associated with an OS 2200 QProcessor group
name. The group must already exist. This command can only be entered by a user
mapped to root.
Format
mquseradd –O -g groupid OS2200userid
mquseradd –R –g groupid RemoteUserid
Parameters
-O specifies that you are adding an OS 2200 user ID.
-R specifies that you are adding a remote user ID.
groupid is the OS 2200 QProcessor group to add the user to. The group must
already exist. Groups such as mqm, root, or another custom group can be chosen.
OS2200userid is the OS 2200 user ID that you want to add. The OS 2200 user ID
can be added in any case.
F–24 3843 3744–002

mquserdel
UNX Utility Command Reference
RemoteUserid is the remote user ID that you want to add. This user ID should be
added in all lowercase because MQ converts all incoming user IDs on channels (that
is client connections) to lowercase for security checks.
Example
To add OS 2200 user WMQ to the OS 2200 QProcessor usermap table as a member
of the mqm group, execute the following command:
@WMQ$*MQS$EXE.UNX
>mquseradd –O -g mqm WMQ
To add a remote user (for example a Windows userid) JOHNQSMITH to the
QProcessor as a member of the limitedmq custom group (which must be
created previously with groupadd), execute the following command:
@WMQ$*MQS$EXE.UNX
>mquseradd –R –g limitedmq johnqsmith
This command removes either a remote user ID from the OS 2200 QProcessor or an
OS 2200 user IDfrom the OS 2200 QProcessor. If you remove an OS 2200 user ID, all
WMQ2200 applications running with this OS 2200-user ID will now run with nobody
OS 2200 QProcessor access rights. This command can only be entered by a user
mapped to root.
Format
mquserdel -O OS2200userid
mquserdel –R RemoteUserid
Parameters
-O specifies that you are removing an OS 2200 user ID.
-R specifies that you are removing a remote user ID.
OS2200userid is the OS 2200 user ID that you want to remove. The OS 2200 user
ID can be specified in any case.
RemoteUserid is the remote user ID that you want to remove. This user ID must be
specified in the same case that it was added (which typically should be all
lowercase).
Example
To remove the OS 2200 user WMARY from the OS 2200 QProcessor, execute the
following command:
@WMQ$*MQS$EXE.UNX
>mquserdel –O WMARY
3843 3744–002 F–25

UNX Utility Command Reference
mquserlist
To remove remote user (for example a Windows userid) JOHNQSMITH from
the QProcessor, execute the following command:
@WMQ$*MQS$EXE.UNX
>mquserdel –R johnqsmith
This command lists OS 2200 users and their associated OS 2200 QProcessor groups
for access rights to MQ queues.
Format
mquserlist –O
Mquserlist -R
Parameters
-O specifies that you want to list OS 2200 user mappings.
-R specifies that you want to list remote user IDs.
-s specifies that you wish to list all system user IDs on the OS 2200 QProcessor.
This parameter can only be used with the –R option.
Example
To list all associated OS 2200 QProcessor users and groups, execute the following
command:
@WMQ$*MQS$EXE.UNX
>mquserlist –O
>-MQS-:root:root
>MQM:mqm:mqm
To list all remote user IDs installed on the OS 2200 QProcessor, execute the
following command:
@WMQ$*MQS$EXE.UNX
>mquserlist –R
>root
>mqm
>NTuser
To list all remote user IDs installed on the OS 2200 QProcessor as well as the
system user IDs, execute the following command:
@WMQ$*MQS$EXE.UNX
>mquserlist –R -s
>root
F–26 3843 3744–002

ootmod
saveqmgr
>mqm
>NTuser
>nobody
>mail
>man
UNX Utility Command Reference
This command adds or removes the root user from the mqm group. Adding the root
user to the mqm group allows root authorized users to perform all MQ administrative
functions as well. You must be mapped to root to perform this command.
Format
rootmod [-a] [-r] [-h]
Parameters
-a Put root into mqm group
-r Remove root from mqm group
-h Print the help summary
Changes take effect after exiting and re-entering the shell.
This command saves a queue manager's object definitions. To display the options for
this command, use the –h option.
Format
saveqmgr -h
Parameters
saveqmgr_all
-h displays other uses and options
This command saves object definitions from all queue managers. To display the
options for this command, use the –h option.
Format
saveqmgr_all -h
Parameters
-h displays other uses and options
3843 3744–002 F–27

UNX Utility Command Reference
ss
ss Display
This command in UNX shell provides information about system resource use.
Format
ss [-a] [-opt1] [-opt2] [id]
Parameters
The ss command entered with no options displays general system resource use.
-a displays a summary of each of the IPC memory types: shared memory segments,
message queues, and semaphores. It produces the same display as command
ss -m -q -s. If the -a option is used with any combination of the opt1 type options,
the opt1 options are ignored. The –a option can be used with the opt2 options -c,
-p, or -t. This displays the specified opt2 view for all IPC memory types.
opt1 specifies the type of IPC memory to be displayed:
-m IPC shared memory segments
-q IPC message queues
-s IPC semaphores
Following is an explanation of the information provided by the UNX processor ss
command for displaying system statistics and internal Inter-Process Communication
(IPC) memory usage. The IPC mechanism supports three types of inter-process
communication, which you can monitor with the ss command:
• Shared memory allows processes to share parts of their virtual address space.
• Message queues allow processes to send formatted data streams to arbitrary
processes.
• Semaphores allow processes to synchronize execution.
In the following example, the semaphore arrays are displayed.
Example
------- Semaphore Arrays --------
-key semid owner perms nsems
-0x4d02b830 0 root 600 8
-0x02222ee5 4816897 mqm 666 1
-0x02222eec 5046274 mqm 660 1
-0x02222ef4 5079043 mqm 660 1
-0x02202fe6 5111812 mqm 666 2
-0x02222f24 5505029 mqm 600 2
-0x02222f25 5537798 mqm 600 128
-0x02222f2a 5570567 mqm 666 2
-0x02222f2c 5603336 mqm 666 128
F–28 3843 3744–002

UNX Utility Command Reference
-0x02222f33 5636105 mqm 600 2
-0x02222f34 5668874 mqm 600 128
-0x02222f41 5701643 mqm 600 128
-0x02222f43 5734412 mqm 600 128
-0x02222f97 7372813 mqm 660 1
-0x02222fd6 7634962 mqm 600 2
-0x02222fd7 7667731 mqm 600 128
-0x0222303a 6422550 mqm 660 1
-
------- Message Queues --------
-key msqid owner perms used-bytes messages
where:
ss -m Display
key is the unique identifier used to find semaphores.
semid is the unique semaphore set identifier.
owner is the user that currently owns the semaphore set (not necessarily the
creator).
perms is the operation permissions.
nsems is the number of semaphore structures in this semaphore set.
Example
Table F–5. Shared Memory Segments
Key Shmid Owner Perms Bytes Nattch
0x00000000 21397504 nobody 600 649256 2
0x00000000 21430273 root 600 1056 2
0x82222ee5 15106050 mqm 666 1000 9
0x00000000 15400963 mqm 600 889832 101
0x00000000 15433732 root 600 114216000 101
where:
key is the unique UNX identifier used to find the shared memory segment.
shmid is the unique shared memory identifier.
owner is the user that currently owns the segment (not necessarily the creator).
perms is the operation permissions.
3843 3744–002 F–29

UNX Utility Command Reference
ss -q Display
bytes is the size of the memory segment.
nattch is the number of processes attached for access to the segment.
Operation permissions are defined to be
• 0400 – Read by owner
• 0200 – Alter by owner
• 040 – Read by group
• 020 – Alter by group
• 04 – Read by anybody
• 02 – Alter by anybody
Example
Table F–6. IPC Message Queues
Key Msqid Owner Perms Used-bytes Messages
0x00000000 0 mqm 622 0 0
where:
key is the unique UNX identifier used to find the IPC message queue.
msqid is the unique IPC message queue identifier.
owner is the user that currently owns the IPC message queue (not necessarily the
creator).
perms is the operation permissions.
used-bytes is the current number of bytes used on the queue out of a maximum
of 262,143 bytes.
messages is the number of messages on the queue out of a maximum of 2,000
messages.
Operation permissions are defined to be
• 0400 – Read by owner
• 0200 – Alter by owner
• 040 – Read by group
• 020 – Alter by group
F–30 3843 3744–002

ss -s Display
• 04 – Read by anybody
• 02 – Alter by anybody
Example
Table F–7. Semaphore Arrays
UNX Utility Command Reference
Key Semid Owner Perms nsems
0x4d02b830 0 root 600 8
0x02222ee5 4816897 mqm 666 1
0x02222eec 5046274 mqm 660 1
0x02222ef4 5079043 mqm 660 1
0x02202fe6 5111812 mqm 666 2
0x02222f24 5505029 mqm 600 2
0x02222f25 5537798 mqm 600 128
0x02222f2a 5570567 mqm 666 2
0x02222f2c 5603336 mqm 666 128
0x02222f33 5636105 mqm 600 2
0x02222f34 5668874 mqm 600 128
0x02222f41 5701643 mqm 600 128
0x02222f43 5734412 mqm 600 128
0x02222f97 7372813 mqm 660 1
0x02222fd6 7634962 mqm 600 2
0x02222fd7 7667731 mqm 600 128
0x0222303a 6422550 mqm 660 1
where:
key is the unique UNX identifier used to find the semaphore.
semid is the unique semaphore set identifier.
owner is the user that currently owns the semaphore set (not necessarily the
creator).
perms is the operation permissions.
nsems is the number of semaphore structures in this semaphore set.
3843 3744–002 F–31

UNX Utility Command Reference
Operation permissions are defined to be
• 0400 – Read by owner
• 0200 – Alter by owner
• 040 – Read by group
• 020 – Alter by group
• 04 – Read by anybody
• 02 – Alter by anybody
Additional Option Examples
The following ss commands are also available:
• ss -m –t
Displays the attach, detach, and changed times for memory segments.
• ss -m –c
Dumps ipc_perm structure owner and creator information.
• ss -m –p
Displays memory segment creator PID and last operation PID.
• ss -m -i shmid
Displays a summary of the previous options for the supplied shmid.
The last operation pid for a semaphore set in the ss -m -p display is currently not
tracked, and reports 0.
• ss -q -t
Displays last IPC message queue send, receive, and change times.
• ss -q -c
Dumps ipc_perm structure owner and creator information.
• ss -q -p
Displays IPC message queue last send PID and last receive PID.
• ss -q -i msqid
Displays a summary of the previous options for the supplied msqid.
• ss -s -t
Displays the last operation and creation time for semaphore sets.
F–32 3843 3744–002

sysinfo
ted
• ss -s -c
Dumps ipc_perm structure owner and creator information.
• ss -s -i semid
UNX Utility Command Reference
Dumps the contents of the sem structure for each member of the semaphore set
identified by semid, in addition to a summary of the previous options.
Note: Only a user ID mapped to root can perform the ss -s –i semid option.
The last operation time for a semaphore set in the ss -s -t display is currently not
tracked and reports "Not set." The headings displayed for a sem structure in the ss -s -i
semid command are defined as follows:
semnum is the number of the semaphore structure within the set.
value is the semaphore value (semval).
ncount is the number of processes awaiting semval > sem_op.
zcount is the number of processes awaiting semval = 0.
Combinations of the opt1 type options can be used with one of the opt2 view options
to generate mixed displays. For example, the command ss -m -s -t displays the last
operation time and creation time for both memory segments and semaphore sets.
This command prints system information of the OS 2200 QProcessor.
Format
sysinfo
Parameters
None
ted is a line-oriented text editor. It is used to create, display, modify and otherwise
manipulate text files.
To get out of insert mode and back to command mode, use @EOF.
Note: You can only edit files in your current working directory. See Appendix C,
"Editing WMQ2200 QProcessor files," for more information about the ted editor.
Format
ted [-p] [-s] [file]
3843 3744–002 F–33

UNX Utility Command Reference
uname
uptime
Parameters
-s Suppress diagnostics
-p Specifies a command prompt.
file Is the file to be read.
This command prints the OS 2200 QProcessor system information.
Format
usysreport
uname
Parameters
None
This command prints how long the OS 2200 QProcessor has been up.
Format
uptime
Parameters
None
This command generates a system report from the OS 2200 QProcessor. It includes all
pertinent system files and state of the OS 2200 QProcessor.
Format
Usysreport qualifier*filename.
Parameters
qualifier*filename specifies the OS 2200 file into which you want to save the
usysreport output file to. This output file must be an OS 2200 data file that already
exists on your system and must be large enough to hold all the information
generated by a usysreport. The file or tape device should be at least 1463 tracks
(about 10 megabytes). If the qualifier has a ‘$’ sign, make sure you have a \
(backslash) before issuing the $ sign.
F–34 3843 3744–002

whoami
whoamilx
UNX Utility Command Reference
This command returns the OS 2200 user ID information for this UNX user.
Format
whoami
Parameters
None
This command returns the OS 2200 QProcessor user ID and group information for this
UNX user.
Format
whoamilx
Parameters
None
3843 3744–002 F–35

UNX Utility Command Reference
F–36 3843 3744–002

Appendix G
OS 2200 QProcessor Administrative
Console
G.1. About the OS 2200 QProcessor Administration
Console
The OS 2200 QProcessor Administration Console is a browser based administration
tool to configure, manage and diagnose hardware and software issues with the
OS 2200 QProcessor. It provides the following capabilities for the WMQ2200 user:
• System Health to track and configure the disk subsystem.
• Manage User Mappings to configure and manage OS 2200 and other remote user
mappings to OS 2200 QProcessor users and groups.
• Manage MQ Log Policy to configure and manage the archival of MQ log files.
• Manage MQ to allow users to:
− View and edit the MQ configuration files
− View and edit queue manager start and stop scripts
− Start and stop queue managers
− Start or schedule a backup of the /var/mqm file system
− Start or schedule a backup of a specific queue manager
• Collect MQ Trace and Dumps to collect files and download the contents.
• View System Logs to view or download system error logs including queue
manager logs, system logs, and installation logs among others.
• Filesystem Backup to backup and restore any data stored on the OS 2200
QProcessor.
• Manage External Disks to configure and manage optional external disk
subsystems.
• Manage HA to configure and monitor queue managers and their objects under HA
cluster control.
3843 3744–002 G–1

Accessing the Administration Console
G.2. Accessing the Administration Console
Access to the Administration Console is through a web browser. The address
depends on how the OS 2200 QProcessor is configured. By default, the Administration
Console can only be accessed from the Operations Server by using the following
address:
https://172.28.102.11:10000
Refer to the ClearPath Specialty Engine for OS 2200 Configuration Guide or contact
your system administrator for more information.
G–2 3843 3744–002

Index
A
access control records (ACRs), 1-19
access, subsystem, 1-19
ACR (See access control records)
addstreams, 7-12 (See also runstreams)
deactivating WMQ2200 subsystem, 7-15
troubleshooting, 3-19
administration
backup, 3-18
information about WMQ2200 version,
displaying, E-14
mqload utility, 3-18, F-18
mqsave utility, 3-18
mqsavelog utility, 3-17
remote, 3-20
restore, 3-18
starting queue manager, 3-3
terminating demand applications, 3-4
terminating queue manager, E-13
tools, 3-19
troubleshooting, 7-1
user ID requirements, 1-20
WebSphere MQ for OS 2200, 3-1
AffinitizeWaitTime parameter, 2-25
alternate WMQ2200 installations using
COMUS, 2-49
APISTATUS command, WMQ2200, E-3
applications
C, 4-1
COBOL, 4-1
compiling and linking, 4-17
creating, 4-1
exits, 4-1
message area, 4-13
terminate queue managers, 3-4
trigger, 4-4
user-developed as trigger monitor, 4-9
APPLICID field, 4-6
APPLTYPE field, 4-6
archive, determining file candidates for, F-21
auditing, WMQ2200, 2-1
authentication information objects, 1-7
authentication, user-provided node, 1-15
authority events, 1-9
3843 3744–002 Index–1
B
back out (Syncpoint coordination), 1-14
back up
WebSphere MQ Queue Manager
(QM), 1-15
background processes
print files, 7-8
starting, 7-8
BackgroundWait parameter, 2-25
basic mode interface (BMI), 1-17, 1-18
basic receiver (RCVR) channel
definition, 2-35
basic sender (SDR) channel
definition, 2-35
batch
application executable location, 4-7
program, 4-4
BATCH setting, APPLTYPE, 4-7
BatchRunLoc parameter, 2-25
binary data, using in message area, 4-13
BMI, See basic mode interface.
build process
products, 2-50
build steps, 2-51
alternate installation of WMQ2200, 2-51
build, Open Distributed Transaction
Processing batch server, 4-18
build, Open Distributed Transaction
Processing client application, 4-19
buildexit tool, 2-44
buildexit, UNX shell command, F-10
Business Information Server, access to
WMQ2200 MQI, 1-17, 1-18
C
C applications
compiling and linking, 4-18
creating, 4-1

Index
CAT/ERRORS addstream, running
manually, 7-12
chained message
definition, 4-16
headers, 4-16
challenges
data conversion, 4-13
data transmission, 4-13
change
user mappings, 3-14
change object events, 1-11
channel
definition, 1-7
exits, 4-2, 4-4
message, 1-7
Message Queuing Interface (MQI), 1-7
channel and bridge events, 1-10
channel events, 1-10
client applications, WebSphere MQ, 5-1
client connections, 5-1
COBOL applications
creating, 4-1
sample programs, 4-20
co-install, 2-2, 2-3
COMAPI (See Communications Application
Program Interface)
command, 1-8
command combination examples, B-1
command events, 1-12
commit
message, 8-7
Syncpoint coordination, 1-14
communcation path between queue
managers, 2-34
communications
listener setup, 2-34
port setup, 2-34
setup, 2-33
Communications Application Program
Interface (COMAPI), 1-1
components
Message Queuing Interface (MQI), 1-14
WebSphere MQ, 1-13
WebSphere MQ Queue Manager
(QM), 1-14
CONCURRENCY configuration
parameter, 4-8
configurable values
AffinitizeWaitTime, 2-25
BackgroundWait, 2-25
BatchRunLoc, 2-25
ConvertMQMDE, 2-25
summary, 2-23
configuration
advanced, 2-44
examples, 4-11
file, 2-22
parameters(See also configurable
values, 2-22
test, 2-20
values, 2-23
verification, 2-20
WMQ2200, 2-22
configuration events, 1-11
change object, 1-11
create object, 1-11
delete object, 1-11
refresh object, 1-12
configuration values
DaemonKeyId, 2-27
DaemonRetryInt, 2-27
detail, 2-25
FileSystem, 2-28
HighOffLoadCount, 2-28
ICLogLevel, 2-29
LinuxIP, 2-29
LinuxPort, 2-29
LogMQAuthorityErrors, 2-29
LowOffLoadCount, 2-30
MaxOffLoads, 2-30
McbEntryBdi, 2-30
MonitorInterval, 2-30
MQAuthority, 2-30
MQLocalLanguage, 2-32
MQLogLevel, 2-32
PrintConnectionDownWarning, 2-32
RealTimeLevel, 2-33
TermWaitTime, 2-33
configure triggering
DEFINE PROCESS, 4-5
DEFINE QLOCAL, 4-5
CONNAME parameter, 2-35
connecting two queue managers, 2-35
considerations, MQGMO_CONVERT, 4-16
continuation line,UNX shell processor, 1-21
control commands
dspmqaut, 3-10
setmqaut, 3-10
conversion exits,data, 4-1, 4-3
ConvertMQMDE parameter, 2-25
CORE command, WMQ2200, E-3
core dumps, 7-7
core,UNX shell command, F-11
cpuinfo, UNX shell command, F-11
create object events, 1-11
creating exit code, 2-44
Index–2 3843 3744–002

crtmqcvx program, 4-3
customization
WMQ2200, 2-22, 3-7
D
daemon keyin
parameters, 7-8, E-1
daemon, background process, E-1
DaemonKeyId parameter, 2-27
DaemonRetryInt parameter, 2-27
data
assurance (Syncpoint), 1-14
container files (See container files)
conversion exits, 4-1, 4-3
format, 4-1
formatting between multiple
platforms, A-1
structure MQTMC2, 4-10
DEACT, 7-15
dead-letter queue (DLQ) handler, F-2
definition
PROCESS, 4-6
DefPersistence attribute, 1-17
delete object events, 1-11
deploying exit code, 2-44
diagnostics
gathering utility, 7-9, 7-10
WebSphere MQ Queue Manager
(QM), 1-15
diagnostics gathering utility
(DIAGN/RUN), 7-10
diskinfo, UNX shell command, F-12
display
user mappings, 3-15
distribution lists, WebSphere MQ Queue
Manager (QM), 1-15
DOWN command, WMQ2200, E-4
dspmqtrn command, 8-9
dspmqtrn_all, UNX shell command, F-12
dump, Programmers Advanced Debugging
System (PADS), F-11
dumpini, UNX shell command, F-13
dumps
core, 7-7
dynamic (See dynamic dumps)
static (See static dumps)
Index
3843 3744–002 Index–3
E
editor
OS 2200, 3-7
OS 2200 QProcessor Administration
Console, 3-7
TED command, 3-7
elements (See also files)
MQSRUN, troubleshooting, 7-8
Encoding, 4-14
error information
obtaining, 7-4
errors, UNX shell command, F-13
events
instrumentation, 1-9
queue manager, 1-9
tracing, 7-5
trigger, 4-4
examples
application programs,compiling and
linking, 4-17
COBOL programs, 4-20
in WMQ$*MQSTOOLS, 3-19
install and test configuration, 2-20
MQS2200 API scenarios, B-1
trigger programs, 4-11
TX verbs, B-1
verb sequences, B-1
execution, diagnostics gathering utility, 7-10
exits
available for definition, 4-2
building, 4-4
calling, 4-4
channel, 4-2
creating and using, 4-3
data conversion, 4-1, 4-4
definition, 4-1
user-written, 4-1
WebSphere MQ Queue Manager
(QM), 1-15
Explorer, WebSphere MQ, 3-20
external transaction manager, 2-48
F
FCSS (See file control superstructure)
file (See also files)
control superstructure (FCSS) resource
manager, 1-16
OS 2200 QProcessor, reinitializing, 7-15
fileinfo, UNX shell command, F-13

Index
files (See also elements and file)
container (See container files)
determining candidates for archive, F-21
index (See index files)
populated during installation, 2-18
FileSystem parameter, 2-28
fixwebminlog, UNX shell command, F-13
fundamental security environment, 1-19
G
gathering utility, diagnostics, 7-9, 7-10
generate multiple alternate WMQ2200
installations, 2-49
generate multiple WMQ2200
installations, 2-56
global transactions
resolving incomplete, 8-7
Greenwich Mean Time (See Coordinated
Universal Time)
groupadd, UNX shell command, F-14
groupdel, UNX shell command, F-14
grouplist, UNX shell command, F-14
groupmembers, UNX shell command, F-15
H
h9ton8 function (h9ton8/o), A-9
h9ton8/o library, A-9
hardware requirements, 1-18
HELP command, WMQ2200, E-5
High Availability, 6-1
performance, 6-2
recommendations, 6-2
WMQ2200 specific changes, 6-1
HighOffLoadCount parameter, 2-28
host-to-network functions, h9ton8/o,
h9ton8, A-9
host-to-network functions, hton/o
htonl, A-1
htons, A-2
shtonl, A-2
shtons, A-3
host-to-network functions, hton-ucob/o
HTONL, A-5
HTONS, A-6
SHTONL, A-5
SHTONS, A-6
hton/o library, A-1
htondb/o library, A-5
htondb-ucob/o library, A-8
htonl function (hton/o), A-1
HTONL function (hton-ucob/o), A-5
htons function (hton/o), A-2
HTONS function (hton-ucob/o), A-6
hton-ucob/o library, A-5
Index–4 3843 3744–002
I
IBM documentation for MQSeries, 1-2
ICLOG command, WMQ2200, E-5
ICLogLevel parameter, 2-29
identity, UNX shell command, F-15
information
build, 2-51
core dumps, 7-7
IBM product, 1-2
MQS2200 version, displaying, E-14
only, requesting on files, F-21
status of externally managed
transactions, 8-9
troubleshooting, 7-1
inhibit events, 1-9
init, UNX shell command, F-15
initiation queue, 4-4
input, terminating to runmqdlq, F-2
installation
alternate build, 2-55
verification, 2-20
WMQ2200, 2-16
installation and migration considerations, 2-2
instrumentation events, 1-9
channel and bridge, 1-10
command, 1-12
configuration, 1-11
logger, 1-12
performance, 1-11
queue manager, 1-9
WebSphere MQ Queue Manager
(QM), 1-15
integration, Open Distributed Transaction
Processing, 1-16
Interconnect (IC2200), 1-18
interfaces, WebSphere MQ, 1-13
Inter-Process Communication (IPC)
monitoring, F-28
IPC (See Inter-Process Communication)

L
libraries
h9ton8/o, A-9
hton/o, A-1
htondb/o, A-5
htondb-ucob/o, A-8
hton-ucob/o, A-5
limitations, WMQ2200, D-1
linear logging, 3-17
Linux type shell commands, F-4
LinuxIP parameter, 2-29
LinuxPort parameter, 2-29
listcores, UNX shell command, F-16
listener setup, 2-34
listeners, 1-8
backlog, 5-2
start, 2-34
stop, 2-35
lists, distribution, 1-15
local events, 1-9
location of start runstream, 2-25
log files, 3-16
logger events, 1-12
logging, 1-14
linear, 3-17
LogMQAuthorityErrors parameter, 2-29
logs, UNX shell command, F-17
LowOffLoadCount parameter, 2-30
M
managers (See queue managers or
resource managers)
MaxActiveChannels attribute, 5-2
MaxOffLoads parameter, 2-30
MCA (See Message Channel Agents)
MCB (See Message Control Bank)
MCBBDI value, 4-8
McbEntryBdi parameter, 2-30
media,release, 2-1
meminfo, UNX shell command, F-17
memory
usage, monitoring, F-28
message
area, using binary data, 4-13
commit, 8-7, 8-9
definition, 1-5
formats, 4-14
multiple on same queue, 1-15
queuing (See also queues)
Index
queuing, concepts and terminology, 1-4
queuing, integrity, 1-17
recovery, 8-1
resolving manually, 8-7
roll back, 8-7, 8-9
status, 8-9
trigger, 4-4
message channel, 2-33
Message Channel Agents (MCA), 2-34
Message Control Bank (MCB)
APPLTYPE setting (TIP), 4-8
resource manager, 1-16
message data
built-in, 4-14
user-defined, 4-14
message formats
built-in, 4-14
user-defined, 4-14
message queues, F-28
Message Queuing Interface (MQI), 1-14
message queuing, definition, 1-4
migration, 2-2
monitor (See trigger monitoring)
MonitorInterval parameter, 2-30
MQ performance considerations, 2-15
MQAuthority parameter, 2-30, 3-3
mqexport, UNX shell command, F-18
MQGMO_CONVERT, overview, 4-16
MQI (See Message Queuing Interface)
MQI client connections, 5-1
mqimport, UNX shell command, F-18
mqload, UNX shell command, F-18
mqloadlog, UNX shell command, F-19
MQLocalLanguage parameter, 2-32
MQLOG command, WMQ2200, E-6
MQLogLevel parameter, 2-32
MQM mappings, 3-15
MQMDE (Message Descriptor
Extension), 4-14
MQRFH (Reference Header), 4-14
-MQS- mappings, 3-15
MQS traces, 7-5
MQS2200 (See product)
mqsave, UNX shell command, F-20
mqsavelog, UNX shell command, F-21
MQSeries
commands, F-4
concepts, 1-4
for ClearPath OS 2200 (See product)
IBM documentation, 1-2
MQSRUN element, 7-8
MQTMC2data structure, 4-10
mquseradd, UNX shell command, 3-13, F-24
3843 3744–002 Index–5

Index
mquserdel, UNX shell command, F-25
mquserlist, UNX shell command, F-26
multiple
platforms, data formatting, A-1
queues, setting up one runstream to
handle, 4-7
WMQ2200 installations, 2-56
N
n8toh9 function (h9ton8/o), A-10
namelist, 1-7
network-to-host functions, h9ton8/o,
n8toh9, A-10
network-to-host functions, hton/o
ntohl, A-3
ntohs, A-4
sntohl, A-4
sntohs, A-4
network-to-host functions, hton-ucob/o
NTOHL, A-7
NTOHS, A-8
SNTOHL, A-7
SNTOHS, A-8
node authentication, user-provided, 1-15
nonpersistent message type, Open
Distributed Transaction
Processing, 1-17
ntohl function (hton/o), A-3
NTOHL function (hton-ucob/o), A-7
ntohs function (hton/o), A-4
NTOHS function (hton-ucob/o), A-8
O
OAM (See Object Authority Manager)
Object Authority Manager (OAM), 1-15
objects
authentication information, 1-7
channels, 1-7
definition, 1-5
listeners, 1-8
namelists, 1-7
process definitions, 1-7
queue managers, 1-6
queues, 1-6
remote administration, 3-20
services, 1-8
OHIGH command, WMQ2200, E-7
OLOW command, WMQ2200, E-7
OLTP setting, APPLTYPE, 4-7
OLTPS setting, APPLTYPE, 4-8
Open Distributed Transaction Processing
configuring multiple WMQ2200
installations, 2-57
configuring WMQ2200 as a static
resource manager, 2-47
examples, B-1
global transactions, incomplete, 8-7
integration, 1-16
persistent and nonpersistent message
type, 1-17
recovery
server (TMSC), 2-49
TX verbs, samples, B-1
WMQ2200 as resource manager, 1-17
Open Distributed Transaction Processing
recovery server, 2-49
Open Distributed Transcation Processing
installing WMQ2200 as a static resource
manager, 2-56
OS 2200 QProcessor Administration
Console
access, G-2
capabilities, G-1
OS 2200 QProcessor architecture, 4-13
OS 2200 QProcessor user mappings, 3-13
Index–6 3843 3744–002
P
paging function, commands, F-2
performance events, 1-10, 1-11
queue depth, 1-11
queue service interval, 1-11
Persistence field of MQMD, 1-17
persistent message type, Open Distributed
Transaction Processing, 1-17
pid (process-id), 1-20
port setup, 2-34
prerequisites for using product, 1-1
print files, background process, 7-8
PrintConnectionDownWarning
parameter, 2-32
problems, troubleshooting, 7-1
procedure
shutdown WMQ2200, 3-2
startup WMQ2200, 3-2
process
background, 7-8
definitions, 1-7
listeners, 1-8

PROCESS definition, 4-6
process-id (pid), 1-20
product
application program interface, 1-14
components, 1-13
configuration, 2-22
customization, 3-7
installation, 2-16
interfaces, 1-13
limitations, D-1
overview, 1-1
prerequisites for using, 1-1
restrictions, D-1
scenarios, B-1
programs
crtmqcvx, 4-3
sample, 4-17
Q
QM (See MQSeries Queue Manager)
queue
definition, 1-5
queue depth events, 1-11
queue manager events
authority, 1-9
channel, 1-10
inhibit, 1-9
local, 1-9
performance, 1-10
remote, 1-9
start and stop, 1-10
queue manager log files, 3-16
queue manager traces
obtaining, 7-5
queue managers
definition, 1-6
events, 1-9
remote administration, 3-20
services provided by, 1-6, 1-14
starting, 3-3
terminating, E-13
WebSphere MQ Queue Manager
(QM), 1-14
queue service interval events, 1-11
queues (See also message queuing)
initiation, 4-4
setting up one runstream to handle
multiple, 4-7
WebSphere MQ object, 1-6
queuing, definition, 1-5
Index
3843 3744–002 Index–7
R
RealTimeLevel parameter, 2-33
receiving system, 2-36
recommendations, user application
development, 4-17
recovery
server, TMSC, 2-49
WebSphere MQ, 8-1
recovery logs, 8-1
refresh object events, 1-12
release media, 2-1
remote administration, 3-20
remote events, 1-9
remote user ID
change, 3-14, 3-15
delete, 3-14
display, 3-15
replacement, 2-2, 2-3
report, system, F-34
requirements
build, 2-50
for administration, 1-20
hardware, 1-18
software, 1-18
user ID, 1-19
resource manager
configuring under Open Distributed
Transaction Processing, 2-47
Resource Manager (RM), 1-16
resource managers
FCSS, 1-16
MCB, 1-16
MQS2200 under Open Distributed
Transaction Processing, 2-44
static, 2-44
Universal Database Control, 1-16
WMQ2200 under Open Distributed
Transaction Processing, 1-16, 1-17
resources, information about system, F-28,
F-33
restore
data for queue manager, F-18
log files, F-19
WebSphere MQ Queue Manager
(QM), 1-15
restrictions
MQI clients, 5-3
WMQ2200, D-1
RM (See Resource Manager)
roll back
message, 8-7

Index
rootmod, UNX shell command, F-27
rsvmqtrn command, 8-9
runmqdlq control command, F-2
RUNMQLSR command, 2-34
runmqsc definition, 4-5
RUNMQSC START LISTENER command, 2-35
runstreams (See also addstreams)
reinitializing WMQ2200 file system, 7-15
setting up one to handle multiple
queues, 4-7
S
samples (See examples)
save (See back up)
saveqmgr, UNX shell command, F-27
scenarios, MQS2200 API and TX verbs, B-1
SecOpt security environment, 1-19
secure access, queues, 3-8
security
environments, 1-19
WebSphere MQ Queue Manager
(QM), 1-15
semaphores, F-28
sending system, 2-36
server, 1-8
service objects, 1-8
commands, 1-8
servers, 1-8
services provided by queue manager, 1-6,
1-14
shared memory, monitoring usage, F-28
shell
processor (UNX), 1-20, F-1
shtonl function (hton/o), A-2
SHTONL function (hton-ucob/o), A-5
shtons function (hton/o), A-3
SHTONS function (hton-ucob/o), A-6
SHUTDOWN command, WMQ2200, E-7
shutdown WMQ2200, 3-2
sntohl function (hton/o), A-4
SNTOHL function (hton-ucob/o), A-7
sntohs function (hton/o), A-4
SNTOHS function (hton-ucob/o), A-8
software requirements, 1-18
ss display, F-28
ss, UNX shell command, F-28
ss-m display, F-29
ss-q display, F-30
start and stop events, 1-10
START command, WMQ2200, E-8
start listeners, 2-34
start queue manager, 3-3
strmqm command, 3-4
starting
of daemon keyin, 7-7
of daemon keyin, E-1
of trigger monitor, 4-12
startup WMQ2200, 3-2
static resource manager, MQS2200 under
Open Distributed Transaction
Processing, 2-44
static resource manager, WMQ2200 under
Open Distributed Transaction
Processing, 2-47, 2-56
STATS command, WMQ2200, E-8
STATS OFF command, WMQ2200, E-9
STATs ON command, WMQ2200, E-9
STATS RESET command, WMQ2200, E-9
STATUS command, WMQ2200, E-9
sticking transaction, 4-20
programs, 4-20
stop listeners, 2-35
strmqm command, 3-4
subsystem, deactivating WMQ2200
subsystems, 7-15
Syncpoint
Open Distributed Transaction
Processing, 1-17
WebSphere MQ Queue Manager
(QM), 1-14
sysinfo, UNX shell command, F-33
system
resource use, F-33
system files installed
configuartion, 2-28
system, resource use, F-28, F-33
Index–8 3843 3744–002
T
tape assign options, 2-1
TED
commands, C-3
format and options, C-1
ted, UNX shell command, F-33
TERM command, WMQ2200, E-13
terminate queue managers, 3-4
termination
of demand applications, 3-4
of input to runmqdlq, F-2
of queue managers, E-13
of trigger monitor, 4-13

terminology, message queuing, 1-4
TermWaitTime parameter, 2-33
test configuration, 2-20
time (See Coordinated Universal Time)
TIP (See also TIP files)
setting, APPLTYPE, 4-8
TIP files (See also TIP)
TIP/HVTIP applications
user mappings, 3-16
TMSC program, 2-48, 2-49
tool to deploy exit code
buildexit, 2-44
tools, 3-19
traces, 7-5
transaction manager, B-2
transactional support, 1-16
transactions, resolving
incomplete global, 8-7
trigger
creating user-defined monitor, 4-9
definition, 4-4
examples, 4-11
monitoring, 4-10
starting monitor, 4-12
terminating monitor, 4-13
WebSphere MQ Queue Manager
(QM), 1-15
troubleshooting
background process print files, 7-8
core dump, 7-7
daemon keyin, 7-8, E-1
deactivating WMQ2200 subsystems, 7-15
gather system information, 7-1
MQSRUN elements, 7-8
obtaining error information, 7-4
obtaining queue manager traces, 7-5
overview, 7-1
queue manager status information, 7-1
recover unstable WMQ2200, 7-15
reinitializing OS 2200 QProcessor
system, 7-15
TX verbs, samples, B-1
types of user IDs, 3-9
U
uname, UNX shell command, F-34
Universal Coordinated Time (See
Coordinated Universal Time)
Universal Data Control resource
manager, 1-16
UNX shell
commands, F-1
traces, 7-6
using an asterisk, F-1
UNX shell commands, F-4
UNX shell processor
checking for availability, 7-9
continuation line, 1-21
format, F-1
overview and format, 1-20
ss command, F-28
UP command, WMQ2200, E-13
upgrading from MQS2200, 2-2
co-install, 2-2
migration, 2-2
replacement, 2-2
uptime, UNX shell command, F-34
user ID
OS 2200, 3-9
remote, 3-9
requirements, 1-19
user mappings
create, 3-13
delete, 3-14
user-defined
group permissions, 1-15
trigger monitor, 4-9
user-provided node authentication, 1-15
using channels, connecting queue
managers, 2-35
using, daemon keyin, 7-8, E-1
Usysreport diagnostics, 7-11
usysreport, UNX shell command, F-34
UTC (See Coordinated Universal Time)
Index
3843 3744–002 Index–9
V
values (See configurable values)
verbs, sample sequences, B-1
verification of installation and
configuration, 2-20
VERSION command, WMQ2200, E-14
W
WebSphere MQ
client applications, 5-1
Explorer, 3-20
Log Manager, 1-14
Object Authority Manager (OAM), 1-15

Index
objects, 1-5
Queue Manager (QM), 1-14
Syncpoint, 1-14, 1-17
WebSphere MQ control commands, 3-10
WebSphere MQ encodings, 4-14
WebSphere MQ listener process, 2-34
WebSphere MQ log files,recovery, 8-1
WebSphere MQ OAM authentication, 3-11
WebSphere MQ Object Authority Manager
(OAM), 3-9
WebSphere MQ recovery capabilities, 8-1
WebSphere MQ XA/Open XA interface
rules, 2-48
whoami, UNX shell command, F-35
whoamilx, UNX shell command, F-35
WMQ2200 architecture, 3-1
WMQ2200 daemon background run, 7-7
WMQ2200 daemon START command, 3-4
WMQ2200 utilities, F-4
Index–10 3843 3744–002
X
XA rules, B-2
XA/Open XA interface rules, 2-48
XA-compliant
Resource Manager (RM), 1-16
transactional coordination, 1-14
XATMI calls, 4-8, B-1

© 2010 Unisys Corporation.
All rights reserved.
*38433744-002*
3843 3744–002