Before using this information and the product it supports, be sure to read the general information under
“Appendix C. Notices” on page 105.
First edition (March 2000)
This edition applies to MQSeries for AS/400, Version 5 Release 1, and to all subsequent releases and modifications
until otherwise indicated in new editions.
This book describes IBM®MQSeries for AS/400, Version 5.1. It explains how
to plan for, install, and begin to use the product. For latest information about
MQSeries for AS/400, V5.1, refer also to the readme file on the publications
CD-ROM, and to the MQSeries family Web site at:
http://www.ibm.com/software/ts/mqseries/
Conventions
Knowing the conventions used in this book will help you use it more
efficiently.
v Boldface type indicates the name of an item you need to select.
v Italic type indicates new terms, book titles, or variable information that you
must replace with actual values.
v Monospace type indicates an example (such as a fictitious path or file name)
This chapter introduces IBM MQSeries and describes its relationship with
other products. It contains basic explanations of the following topics:
v “Message Queuing”
v “Messages and Queues” on page 2
v “MQSeries Objects” on page 3
v “Clients and Servers” on page 6
v “Instrumentation Events” on page 7
v “Transactional Support” on page 8
For more detailed explanations of these topics see the MQSeries Planning
Guide.
Message Queuing
MQSeries enables applications to use message queuing to participate in
message-driven processing. Applications can communicate across different
platforms by using the appropriate message-queuing software products. The
applications are shielded from the mechanics of the underlying
communications.
MQI – a Common Application Programming Interface
All MQSeries products implement a common application programming
interface (message queue interface or MQI), regardless of the platform on
which the applications are run. The calls made by the applications and the
messages they exchange are common. This makes it much easier to write and
maintain applications than it is when using traditional methods. It also makes
it easier to port applications from one platform to another.
The MQI is described in detail in the MQSeries Application ProgrammingReference book.
With message queuing, the exchange of messages between the sending and
receiving programs is time independent. This means that the sending and
receiving applications are decoupled; the sender can continue processing
without having to wait for the receiver to acknowledge receipt of the message.
In fact, the target application does not even have to be running when the
message is sent. It can retrieve the message when it starts running.
Message-Driven Processing
On arrival on a queue, messages can automatically start an application by
using a technique known as triggering. If necessary, the application can be
stopped when the message or messages have been processed.
Messages and Queues
Messages and queues are the basic components of a message queuing system.
What is a Message?
A message is a string of bytes that has meaning to the applications that use it.
Messages are used to transfer information from one application to another (or
to different parts of the same application). The applications can be running on
the same platform, or on different platforms.
MQSeries messages have two parts; the application data and a messagedescriptor. The content and structure of the application data are defined by the
application programs that use the data. The message descriptor identifies the
message and contains control information, such as the type of message and
the priority assigned to it by the sending application.
MQSeries for AS/400, V5.1 Quick Beginnings
2
What is a Queue?
A queue is a data structure that stores messages. The messages may be put on
the queue by applications or by a queue manager as part of its normal
operation.
Queues exist independently of the applications that use them. A queue can
exist in main storage (if it is temporary), on disk or similar auxiliary storage
(if it must be kept in case of recovery), or in both places (if it is currently
being used, and must also be kept for recovery). Each queue belongs to a
queue manager, which is responsible for maintaining it. The queue manager
puts the messages it receives onto the appropriate queue.
Queues can exist either in your local system, in which case they are called
local queues, or at another queue manager, in which case they are called remote
queues.
Applications use MQI calls to send and receive messages. One application can
put a message on a queue and another application can retrieve the message
from the same queue.
MQSeries Objects
An MQSeries object is a recoverable resource that is managed by MQSeries.
Many of the tasks that are described in this chapter involve manipulating the
following types of MQSeries object:
v Queue managers
v Queues
v Process definitions
v Channels
v Namelists
Messages and Queues
MQSeries creates default objects for you when you create a queue manager.
Each object has a name associated with it. You can specify that name in
MQSeries commands and MQI calls to refer to the object. Names must be
unique within each of the object types. For example, you can have a queue
and a process with the same name, but you cannot have two queues with the
same name.
Chapter 1. About MQSeries3
MQSeries Objects
Queue Managers
A queue manager provides queuing services to applications, and manages the
queues that belong to it. It ensures that:
v Object attributes are changed according to the commands received.
v Special events such as trigger events or instrumentation events are
generated when the appropriate conditions are met.
v Messages are put on the correct queue, as requested by the application that
makes the MQPUT call. The application is informed if this cannot be done,
and an appropriate reason code is given.
Each queue belongs to a single queue manager and is said to be a local queue
to that queue manager. The queue manager to which an application is
connected is said to be the local queue manager for that application. For the
application, the queues that belong to its local queue manager are local
queues. A remote queue is simply a queue that belongs to another queue
manager. A remote queue manager is any queue manager other than the local
queue manager. A remote queue manager may exist on a remote machine
across the network, or it may exist on the same machine as the local queue
manager. MQSeries for AS/400, V5.1 supports multiple queue managers on
the same machine.
Queues
A queue is an MQSeries object that can store messages. Each queue has queue
attributes that determine what happens when applications reference the queue
in MQI calls. The attributes indicate:
v Whether applications can retrieve messages from the queue (get enabled)
v Whether applications can put messages onto the queue (put enabled)
v Whether access to the queue is exclusive to one application or shared
between applications
v The maximum number of messages that can be stored on the queue at the
same time (maximum queue depth)
v The maximum size of messages that can be put on the queue (maximum
message size)
MQSeries for AS/400, V5.1 Quick Beginnings
4
Process Definitions
A process definition object defines an application that is to be started in response
to a trigger event on an MQSeries queue manager.
A trigger event is a logical combination of conditions that is detected by a
queue manager. For example, a trigger event may be generated when the
number of messages on a queue reaches a predefined level. This event causes
the queue manager to put a trigger message on a specified initiation queue.
This trigger message is retrieved by a trigger monitor, a special application that
monitors an initiation queue. The trigger monitor then starts up the
application program that was specified in the trigger message.
If a queue manager is to use triggering, at least one initiation queue must be
defined for that queue manager.
See the MQSeries Application Programming Guide for more information about
triggering.
Channels
A channel provides a communication path. There are two types of channel;
message channels and MQI channels.
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. It
shields the application programs from the complexities of the underlying
networking protocols.
MQSeries Objects
A message channel can transmit messages in one direction only. If you require
two-way communication between two queue managers, you need two
message channels.
An MQI channel connects an MQSeries client to a queue manager on a server
machine. It is for the transfer of MQI calls (for example, MQPUT) and
responses only and is bidirectional. A channel definition exists for each end of
the link. On some platforms, some types of MQI channel can be defined
automatically.
For more information about channels see the MQSeries Intercommunication
book.
Chapter 1. About MQSeries5
MQSeries Objects
Namelists
A namelist is an MQSeries object that contains a list of other MQSeries objects.
Typically, namelists are used by applications such as trigger monitors, where
they are used to list a number of queues. The advantage of using a namelist is
that it is maintained independently of applications. You can update a namelist
without having to stop any of the applications that use it. Also, if one
application fails, the namelist is not affected and other applications can
continue using it.
Clients and Servers
MQSeries supports client/server configurations for MQSeries applications.
An MQSeries client is a part of the MQSeries product, which is used to accept
MQI calls from an application and pass them to an MQI server machine. The
calls are processed by a queue manager on the server machine. Typically, the
client and server reside on different machines, but equally they may exist on
the same machine.
An MQI server is a queue manager that provides queuing services to one or
more clients. All the MQSeries objects, for example queues, exist only on the
queue manager machine, that is, on the MQI server machine. A server can
support local MQSeries applications as well.
The benefits of using an MQSeries client include:
v Reduced hardware requirements.
v Reduced system administration requirements.
v Small installation footprint.
v Alternative channels using different transmission protocols may be used.
For more information about clients, client support, and creating channels for
clients and servers, see the MQSeries Clients book.
MQSeries for AS/400, V5.1 Quick Beginnings
6
Instrumentation Events
You can use MQSeries instrumentation events to monitor the operation of
queue managers.
Instrumentation events cause special messages, which are called eventmessages, to be generated whenever the queue manager detects a predefined
set of conditions. For example, the following conditions give rise to a QueueFull event:
v Queue Full events are enabled for a specified queue, and
v An application issues an MQPUT call to put a message on that queue, but
the call fails because the queue is full.
Other conditions that can give rise to instrumentation events include:
v A predefined limit for the number of messages on a queue being reached
v A queue not being serviced within a specified time
v A channel instance being started or stopped
If you define your event queues as remote queues, you can put all the event
queues on a single queue manager (for those nodes that support
instrumentation events). You can then use the events that are generated to
monitor a network of queue managers from a single node.
Instrumentation Events
Types of Event
MQSeries events are categorized as follows:
Queue manager events
Performance events
Channel events
These events are related to the definitions of resources within queue
managers. For example, if an application attempts to open a queue
but the associated user ID is not authorized to perform that operation,
a queue manager event is generated.
These events are notifications that a resource has reached a threshold
condition. For example, a queue has reached its queue-depth limit
following an MQGET request, or a queue has not been serviced
within a predefined period of time.
These events are reported by channels as a result of conditions they
detect during their operation. For example, a channel event is
generated when a channel instance is stopped.
Chapter 1. About MQSeries7
Transactional Support
Transactional Support
An application program can group a set of updates into a unit of work. These
updates are usually logically related and must all be successful for data
integrity to be preserved. If one update succeeded while another failed then
data integrity would be lost.
A unit of work commits when it completes successfully. At this point all
updates made within that unit of work are made permanent or irreversible. If
the unit of work fails, all updates are instead backed out. Syncpoint coordination
is the process by which units of work are either committed or backed out
with integrity.
A local unit of work is one in which the only resources updated are those
belonging to the MQSeries queue manager. Syncpoint coordination is
provided by the queue manager itself, using a single-phase commit process.
A global unit of work is one in which resources that belong to other resource
managers, such as a DB2/400
®
database, are also updated. Here, a two-phase
commit procedure must be used and the unit of work is coordinated
externally by the operating system commitment controller.
Global units of work make it possible to integrate database updates within
MQSeries units of work. That is, you can write an application that makes
updates to MQSeries queues and to databases. You can issue commands to
commit or roll back the changes to both the queues and the databases.
This is achieved using a two-phase commit protocol. When a unit of work is
to be committed, the operating-system commitment controller first asks each
resource owner whether it is prepared to commit its updates. Only if the
database manager and the queue manager are both prepared to commit, are
all of the queue and database updates committed. If the database manager
cannot prepare its updates, the unit of work is backed out instead.
Full recovery support is provided if the queue manager loses contact with the
database manager during the commit process. If the database manager
becomes unavailable while it is in doubt (that is, it has been called to prepare
but the commitment controller has yet to receive a commit or backout
decision) the commitment controller remembers the outcome of the unit of
work until it has been successfully delivered. Similarly, if the queue manager
terminates with incomplete commit operations outstanding, these are
remembered over queue-manager restart.
MQSeries for AS/400, V5.1 Quick Beginnings
8
Chapter 2. What’s New in MQSeries for AS/400, V5.1
MQSeries for AS/400, V5.1 is an update to MQSeries for AS/400, V4.2.1.
However, it is more than just an upgrade to the features of that product. It
includes significant new function and a redesign of the product base, to bring
MQSeries for AS/400 to the same level of function as other version 5.1
products. MQSeries for AS/400, V5.1 now offers platform consistency with the
other products at the 5.1 level, which are:
v MQSeries for AIX
v MQSeries for OS/2
v MQSeries for HP-UX
v MQSeries for Sun Solaris
v MQSeries for Windows NT
The features of this release include:
MQSeries queue manager clusters
You can connect MQSeries queue managers to form a cluster. Within a
cluster, queue managers can make the queues they host available to
every other queue manager. Any queue manager can send a message
to any other queue manager in the same cluster without the need for
explicit channel definitions, remote queue definitions, or transmission
queues for each destination. The main benefits of MQSeries clusters
are:
v Fewer system administration tasks
v Increased availability
v Workload balancing
®
®
®
Clusters are supported by all MQSeries Version 5.1 products, and also
by MQSeries for OS/390
®
, Version 2.1.
See the MQSeries Queue Manager Clusters book for a complete
description.
MQSeries Administration Interface (MQAI)
The MQSeries Administration Interface is an MQSeries programming
interface that simplifies manipulation of MQSeries PCF messages for
administrative tasks. It is described in the MQSeries AdministrationInterface Programming Guide and Reference book.
Support for Windows 98 clients
You can connect a Windows 98 client to the MQSeries for AS/400,
V5.1 server.
MQSeries for AS/400, V5.1 supports the following new calls:
v MQCONNX, which allows you to specify queue-manager
connection options.
v MQCMIT, MQBACK, and MQBEGIN, which allow MQSeries to
coordinate a local unit of work.
Two-phase commit
MQSeries for AS/400, V5.1 participates as a two-phase commit
resource in global units of work (UOW) managed by OS/400
Automatic object creation
MQSeries for AS/400, V5.1 creates default objects automatically when
you create a queue manager.
Conversion of the EBCDIC new-line character
You can control the conversion of EBCDIC new-line characters. Thus
you can ensure that data transmitted between EBCDIC systems and
ASCII systems is unaltered by the ASCII conversion.
Multiple queue managers
MQSeries for AS/400 now supports multiple queue managers. You
can nominate one queue manager to be the default queue manager.
You can perform actions on a default queue manager without
specifying its name on the commands.
®
.
Job priority control
Users can set independent priority for individual MQSeries jobs - for
example, channel agents.
MQSeries subsystem
MQSeries for AS/400, V5.1 has its own subsystem. Previous releases
used QSYSWRK.
Euro support
MQSeries supports new and changed code pages that use the euro
currency symbol. Further details of code pages that include the euro
symbol are provided in the MQSeries Application Programming Reference
book.
Multithreaded channels
MQSeries for AS/400, V5.1 supports multithreaded channels.
Multithreaded applications
MQSeries for AS/400, V5.1 supports multithreaded applications.
MQSeries for AS/400, V5.1 Quick Beginnings
10
Message queue size
A message queue can be up to 2 GB.
Message size
A single message can be up to 100 MB.
Administration application
The administration application is not supported in MQSeries for
AS/400, V5.1.
What’s New
Chapter 2. What’s New in MQSeries for AS/400, V5.111
What’s New
MQSeries for AS/400, V5.1 Quick Beginnings
12
Chapter 3. Planning to Install the MQSeries for AS/400
Server
This chapter provides a summary of the requirements for running MQSeries
for AS/400. It discusses the network protocols and compilers supported, the
delivery media, and the various components of the product.
The information in this chapter applies to the server environment only. For
information about client environments, see “Chapter 6. Planning to Install
MQSeries Clients” on page 45.
Hardware Requirements
MQSeries for AS/400, V5.1 runs on any machine that is capable of running
OS/400 V4R4, and that has sufficient storage to meet the combined
requirements of the programming prerequisites, MQSeries for AS/400, V5.1,
the access methods, and the application programs, whether from IBM or other
vendors.
The installation requirements depend on the components you install and how
much working space you need. This, in turn, depends on the number of
queues that you use, the number and size of the messages on the queues, and
whether the messages are persistent. You also require archiving capacity on
disk, tape, or other media.
Disk Space Required
For the MQSeries for AS/400, V5.1 base code and server you should allow
approximately 60 MB of storage.
Software Requirements
This is the minimum supported software level. Later levels, if any, will be
supported unless otherwise stated.
OS/400 Version 4 Release 4
Connectivity
The network protocols supported by MQSeries for AS/400 are:
MQSeries for AS/400 installs into the AS/400 library structure and also uses
directories in the IFS root file system.
AS/400 Library Structure
Installation of MQSeries for AS/400 creates the following libraries:
QMQM
The MQSeries base product library.
QMQMSAMP
The MQSeries samples library (if you choose to install the samples).
QMQM29xx
A library containing a message file that is specific to your national
language. This message file is automatically copied into the
appropriate QSYS29xx library when the product is installed.
The following language versions are available for MQSeries for AS/400, V5.1:
Table 1. National-language versions of MQSeries for AS/400, V5.1
Language IDLanguage
2909Belgian English
2966Belgian French MNCS (Multi-National Character Set)
2981Canadian French MNCS
2950English Uppercase
2924English Uppercase and Lowercase
2938English Uppercase DBCS (Double-Byte Character Set)
2984English Uppercase and Lowercase DBCS
2928French
2940French MNCS
2932Italian
2942Italian MNCS
2931Spanish
2962Japanese
2986Korean
2989Simplified Chinese
Note: The Japanese language version of this product does not run correctly if
your job CCSID is 5026. For details of supported CCSIDs to use with
this language version, see the readme file.
QMxxxx Library
Each time you create a queue manager MQSeries automatically creates an
associated library. This library contains objects specific to the queue manager,
including journals and associated receivers. The name of this library is
MQSeries for AS/400, V5.1 Quick Beginnings
14
derived from the name of the queue manager prefixed with the characters
QM. For example, for a queue manager called TEST, the library would be
called QMTEST.
You can use the WRKLIB command to list all the libraries that MQSeries for
AS/400 has created. Against the queue manager libraries, you will see the text
QMGR: QMGRNAME. The format of the command is:
WRKLIB LIB(QM*)
These queue manager-associated libraries are retained when the product is
deleted.
IFS Root File System
The integrated file system (IFS) provides a common interface to the different
systems on the AS/400. When you install MQSeries for AS/400, V5.1 two
directories are created in the root file system. They are:
/QIBM/ProdData/mqm
Subdirectories below this contain all the product data - for example,
C++ classes. Data in this directory is deleted and replaced each time
the product is installed.
/QIBM/UserData/mqm
Subdirectories below this contain all user data relating to queue
managers. Three subdirectories, /QIBM/UserData/mqm/errors,
/QIBM/UserData/mqm/qmgrs, and /QIBM/UserData/mqm/trace,
are also created when the product is installed.
Connectivity
When you install the product, an mqs.ini file is created in directory
/QIBM/UserData/mqm/ (unless it is already there from a previous
installation). When you create a queue manager a qm.ini file is created
in the directory /QIBM/UserData/mqm/qmgrs/QMGRNAME/
(where QMGRNAME is the name of the queue manager.) The qm.ini
file is the equivalent of the QMINI file in previous releases of
MQSeries for AS/400.
Data in this directory is retained when the product is deleted.
The IFS file structure is shown in the MQSeries for AS/400 V5.1 SystemAdministration book.
Chapter 3. Planning to Install the MQSeries for AS/400 Server15
Connectivity
User Profiles
When you install MQSeries for AS/400, V5.1, a number of user profiles are
created. These include QMQM, QMQMADM, and NOBODY. These three
objects are central to the correct running of MQSeries for AS/400. Under no
circumstances should you alter or delete them. If you do, IBM cannot
guarantee correct behavior of your product.
These profiles are retained when the product is deleted.
Compilers Supported for MQSeries for AS/400, V5.1 Applications
MQSeries for AS/400, V5.1 supports the following compilers:
v IBM ILE C for AS/400 compiler (5768-CX2)
v IBM ILE C++ for AS/400 compiler (5799-GDW)
v IBM VisualAge
®
for C++ for AS/400 compiler (5769-CX4)
v IBM ILE COBOL for AS/400 compiler Version 3 (5769-CB1)
v IBM ILE RPG for AS/400 compiler (5769-RG1)
v AS/400 Developer Kit for Java (5769-JV1)
Delivery
MQSeries for AS/400, V5.1 is supplied on CD-ROM.
There are three CD-ROMs.
v One contains the MQSeries for AS/400, V5.1 base product and sample
programs.
v Another contains the client products that you can use with MQSeries for
AS/400.
v The third contains MQSeries for AS/400 publications.
Java support is supplied on the MQSeries Web site, at:
http://www.ibm.com/software/ts/mqseries/
MQSeries for AS/400 Components
The components are as follows:
BaseSupport to enable you to create and support your own applications.
This includes the run-time component that provides support for
external applications. It also includes support for client connections
from other MQSeries products.
MQSeries for AS/400, V5.1 Quick Beginnings
16
Samples
Sample application programs. The source is supplied in the
QMQMSAMP library and executables are supplied in the QMQM
library. See “Appendix A. Sample MQI Programs” on page 99.
MQSeries online documentation
HTML and PDF versions of the books are supplied on the
publications CD-ROM. They are not installable. You can read them
directly from the CD-ROM or you can copy them to your system. For
example, you could copy them to your PC hard drive, or store them
in the AS/400 IFS and then access them using a network drive.
Each book is supplied in U.S. English and also in some or all of the
following national languages:
v French
v German
v Italian
v Japanese
v Korean
v Spanish
v Simplified Chinese
See “Chapter 8. Obtaining Additional Information” on page 91 for
more information.
MQSeries for AS/400 Components
Readme file
Latest information about the product, which became available after
publication of this book. You can find the readme file on the
publications CD-ROM and should review it before starting to install
MQSeries for AS/400.
See “Chapter 8. Obtaining Additional Information” on page 91 for
more information.
Creating the System-Default Objects
System-default objects are created automatically when you issue the
CRTMQM command to create a queue manager.
You can refresh them using the STRMQM command. Refer to the online help
for information about using this command.
Chapter 3. Planning to Install the MQSeries for AS/400 Server17
18MQSeries for AS/400, V5.1 Quick Beginnings
Loading...
+ 97 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.