The value of WebSphere Message Broker

V6 on z/OS

The Enterprise Service Bus

WebSphere Message Broker features and functions

IBM® WebSphere® Message Broker for z/OS®, V6 (hereafter called Message Broker V6)
enables you to connect a wide range of applications using different interaction patterns,
protocols, and message formats.
Supported interaction patterns include:
• One-way messaging
• Request/response
• Aggregation
• Publish/subscribe (pub/sub)
Message Broker V6 supports the following protocols:
• WebSphere MQ
• HTTP
• Java™ Messaging Service(JMS)
• Real-time and multicast
 • File
• User-defined
Message Broker V6 enables you to model and transform a comprehensive set of message
formats:
• Record-based (COBOL, C)
• Industry standard string-based (SWIFT, TLOG, EDIFACT)
• XML, including all schema artifacts
• User-defined
Messages that pass through Message Broker V6 are potentially routed and transformed
between different formats on the way to their destination. Message Broker V6 provides a
range of technologies for transforming messages, which can be used in accordance with the
skill set of the integration developer:
• ESQL for users with relational database skills who prefer declarative rather than
algorithmic forms to specify message transformation
• Java for programmers skilled in Java
• Graphical mapping for straightforward transformations that do not require
programming
• XSLT for XML-based transformations based on an open standard
Using these features, Message Broker V6 can take messages from a wide variety of sources in
a wide range of formats and route and transform them as needed, so that they can be sent to
destinations to be consumed by applications in the formats and protocols that the applications
expect. This multi-step process is what message brokering is all about – end-to-end
connections between all parts of an enterprise.
Message Broker V6 development artifacts
Message Broker V6 functions are made available through three objects specific to the broker:
Message flows
Message flows represent the processing required to connect applications to each other. An
input message from a source application serves as input to the flow, which generates zero or
more messages, some of which are transformed and routed to target applications. A message
flow consists of one or more processing nodes.
Processing nodes
Processing nodes are the specialized building blocks from which message flows are
constructed. Nodes represent the individual operations that occur on a message as it passes
through a message flow. Nodes are customized to perform actions, such as getting a message
from a specified queue, storing a message in a database, or transforming the message from,
for example, an XML to a COBOL form. If the nodes available with the broker are not
sufficient, you can write your own and integrate them easily.
Parsers
Parsers are provided by Message Broker V6 to read and write messages in a broad range of
message formats. For message formats that can't be interpreted by the built-in Message
Broker V6 message parsers, you can write your own parsers, but you rarely need to to so
because of the flexibility of the built-in parsers.
Message Broker V6 components
There are four components of Message Broker V6:
Toolkit
• In the Development Perspective, Message Broker V6 provides user-friendly, Eclipse-
based tools that help you develop broker artifacts such as message flows and message
sets. Message Flows, message definitions, and any other associated files are packaged
into deployment containers called broker archive (BAR) files ready for deployment to
the broker runtime.
• An Administration Perspective lets operations staff deploy BAR files to any broker
within the administrative domain. In addition, the full operational state of each broker
is visible and can be controlled from this perspective. The Administrative Perspective
uses the Configuration Manager (described below) to effect changes and report status.
The Eclipse toolkit runs on Linux® and Windows®. Each developer requires a broker
toolkit with a Development Perspective, and each administrator may use a broker
toolkit for graphical administration as required. A full suite of command-line tools and
programming interfaces is also available for operations management.
• The Eclipse toolkit runs on Linux and Windows. Each developer requires a broker
toolkit with a Development Perspective, and each administrator may use a broker
toolkit for graphical administration as required. A full suite of command-line tools and
programming interfaces is also available for operations management.
Broker
• The Broker is the run time where deployed flows execute within containers called
execution groups, which appear as z/OS address spaces. Execution groups provide an
excellent opportunity for vertical scaling and isolation.
• Operational personnel have a full range of commands, both JCL and console-based,
that let them view and control the operational state of a broker.
Configuration Manager
• The Configuration Manager is the single management and administration component
for a collection of brokers in a domain. The configuration manager controls all
operational actions via access control lists. It also monitors broker state and holds
topology information related to deployments and inter-broker connectivity.
• All users’ toolkits are connected to a configuration manager.
User Name Server
• The User Name Server component is used in pub/sub networks to determine the set of
user and groups used for pub/sub security checking. This set can be either the users
 defined to the z/OS operating system, or those defined with a user-created program or
file. These values are sent to both the configuration manager and the broker for
subsequent administrative and run-time processing.
A typical configuration is shown below in Figure 1. The diagram represents a broker domain
containing three brokers under the administrative control of the Configuration Manager. You
can perform development and administrative tasks using the Message Brokers toolkit (in this
configuration, a user name server is not shown.) The Message Broker run-time component is
responsible for routing and transforming messages between applications using message flows,
nodes, and parsers.

Figure 1. WebSphere Message Broker domain

Platform choice for components

The toolkit component runs on Linux and Windows under the Eclipse environment using
Rational Application Developer. The other components such as Broker, Configuration
Manager, and User Name Server may be placed on your chosen platform. For z/OS, you can
deploy brokers, the Configuration Manager, and the User Name Server components to this
platform.
A broker domain should contain the appropriate mix of platforms to meet the message
processing needs of connected applications. If transformed messages need to be sent to
applications that reside on z/OS, or information needed to route and transform messages
requires data on z/OS, then it usually makes sense to place a broker on z/OS. As explained
below, operational characteristics of the z/OS broker components mean that users who need a
highly available and scalable technology close to their enterprise data and applications will
select z/OS as a natural platform for these components.
Moving from development to production
In most enterprises, the needs of developers are different to those of production staff.
Developers tend to prefer their own systems under their own control with the ability to share
resources with their co-workers as appropriate, so that they can minimize the time required for
the compile-test-fix cycle. Production environments have different criteria for success:
operational personnel tend to require characteristics such as stability and control.
In development environments, developers usually have their own Toolkit, Configuration
Manager, and Broker running on Windows or Linux workstations. Developers have full
control over creating, deploying, and managing broker domains in this environment. In many
cases, teams of developers will share development resources such as transformation logic or
message definitions using one of the library systems supported by Eclipse, such as CVS or
Rational ClearCase.
When a project has finished its development phase, artifacts required for the production
rollout are packaged into BAR files (see above), so you can send then through quality
assurance procedures and prepare them for deployment to live systems.
Moving towards production rollout, project focus turns to proving that functional,
performance, and stability criteria are met. The platforms for test and quality assurance tend
to be close to those used for production environment, and for many large enterprises this
means z/OS. Since all broker capabilities are available on all platforms, projects developed on
Windows or Linux can be seamlessly transitioned to z/OS knowing that behaviour is
maintained. You can move from project development through test and quality assurance to
production by deploying the same project BAR files successively into these environments and
verifying that project goals continue to be met. Support for deployment descriptors within
BAR files lets you change configuration parameters such as queue names and database table
and schema names without changing transformation or message modelling logic.
Once a project is ready for production deployment, operational staff can deploy using the a
graphical tool, but are more likely to use JCL or z/OS console commands to deploy BAR file
artifacts into the broker run time, and similar commands to verify and report deployment
status. Deployment, monitoring, report, and control can be handled completely by z/OS
production personnel.
In summary, Message Broker's strong platform support, uniformity of behaviour, flexible
deployment capabilities, and range of tools support (graphical, command-line, and
programmable) support the demanding needs of z/OS development and operational staff.
Message Broker V6 topologies
Message Brokers can either be deployed individually as standalone processing engines or in
connected topologies to create highly available and scalable architectures. Whether a hub,
bus, or arbitrary graph topology is employed is a decision based on the architectural or
business needs of a project rather than functional characteristics. Message flows and their
associated artifacts can be deployed to one, many, or all of the brokers within a domain
topology. Applications connected to a message broker node can interoperate with other
applications connected to any other broker node within the topology, using any protocol or
message format combination. Figure 2 below shows how brokers may be arbitrarily connected
together to create a topology that meets the scalability and availability needs required. For
example, applications can communicate with other applications connected to the same or to
different brokers within a domain.

Figure 2. WebSphere Message Broker topologies

An initial deployment on z/OS will probably involve a single Message Broker, because a
relatively simple pilot will help you gain familiarity with Message Broker V6 concepts and
technology. As you roll out more deployments, you may want to scale horizontally onto
multiple zSeries machines to increase both capacity and availability.
On z/OS, you can use SYSPLEX technology to scale horizontally and still maintain a single
system view from an operational perspective. Because broker domains are designed to support
multiple brokers, the single operational SYSPLEX view is consistent with the architectural
construct of a broker domain. Therefore you can easily deploy highly available and scalable
broker architectures using SYSPLEX technology.
It’s also natural to create combinations of brokers on different operating systems. Your
enterprise may have applications running on a variety of platforms in order to meet business
needs, including AIX®, HP-UX, Linux, Solaris, and Windows. Message Broker V6 lets you
connect the applications throughout your enterprise, regardless of the platform they run on.
Message Broker V6 capability comparison
All Message Broker V6 capabilities are available on z/OS in a consistent and complete
fashion compared to WebSphere Message Broker on other platforms. Therefore, you can
develop and test solutions on your platform of choice, put them through your quality
assurance procedures, and deploy packaged solutions (BAR files) on z/OS. Deployment
descriptors let you reconfigure the parameters that control detailed behaviour of a message
flow, such as queue names or database schemas, without changing the message flow.
Message Broker V6 also has platform-specific capabilities and advantages. While some
capabilities are available only on z/OS (see below), most are built-in to the broker, so that
your applications benefit from the increased performance, manageability, and resilience
without design changes.
High availability
Parallel SYSPLEX
Message flows deployed to brokers on z/OS can benefit from using resource managers such
as WebSphere MQ and DB2 that are Parallel SYSPLEX aware. Objects including WebSphere
MQ queues and DB2 databases are available as shared resources within a SYSPLEX, making
them simultaneously available to all applications within the SYSPLEX. As long as one z/OS
image is available, these resources are available. What’s really powerful is that this is a truly
shared resource. In the event of failure, the remaining images will make the failed work
available immediately, without a restart -- availability in its highest sense.
For example, a message flow deployed to brokers in a WebSphere MQ Queue Sharing Group
and transforming XML messages from a shared input queue may perform that processing
anywhere in the SYSPLEX. As long as one queue manager in the group remains available,
messages can continue to be transformed. What differentiates this arrangement from "shared
nothing" solutions is that after a failure, rolled back messages are immediately available
within the SYSPLEX, and can be processed by other flow instances servicing the shared input
queue.
Message flows also exploit a special mode of operations with shared queues that preserves
message order in the event of a failure. Messages rolled back after a failure are delivered to
another message flow in the SYSPLEX in the same message order. This capability is vital
when in-order delivery of messages is critical, as with financial deposits and withdrawals.
This capability goes beyond message replication to true resource sharing.
Similar capabilities exist for DB2 resources when using DB2 Data Sharing Groups.
Automatic Restart Manager (ARM)
ARM is a z/OS subsystem that ensures that you can restart appropriately registered
applications and subsystems after a failure. Applications and subsystems can either be
restarted on the image on which they failed, or in the case of image failure, on another
available image in the SYSPLEX. ARM also covers application restart dependencies where
applications require other applications or subsystems to be present before they restart.
Message Broker V6 is fully ARM-enabled, and it is simple for an operator to assign an ARM
classification and name to the broker. When the broker is started or stopped, it performs the
necessary registration with ARM, enabling it to be restarted as defined in the ARM policy by
the z/OS systems programmer.
The Configuration Manager and User Name Server components are also ARM enabled.
WebSphere MQ clustering
For z/OS users not using Parallel SYSPLEX, MQ clustering provides an excellent way to
exploit high availability for new messages in the event of failure. In this mode of operation,
brokers in a domain have a partitioned copy of the input queue, and clustering ensures that in
the event of a failure, new messages are sent only to queues that are still available. Although
MQ clustering is a "shared nothing "solution, in many scenarios it can be good enough to
enable the availability of new work, especially when combined with ARM.
Workload management
Goal-oriented resource allocation
When a Message Broker V6 execution group address space starts, you can assign to it a
Workload Manager (WLM) service class. Systems programmers can assign different goals
(typically response time) to this service class through WLM configuration choices.
The ability to assign WLM service classes to message processing workload has two
significant benefits:
• As work passes through subsystems that are WLM enabled, the service class can be
maintained. Resources such as CPU and IO "follow" users’ work requests to make
sure these requests meet, if possible, the goals set by WLM.
• WLM classification means that in the event of resource constraint (at peak time for
example), high priority workloads can receive appropriate resource to ensure that
critical workloads are completed at the expense of less important work.
It is possible to assign different Execution Group address spaces to different WLM classes so
that CPU and IO resource allocation can be prioritized appropriately for different classes of
work performed with a single message broker.
Workload scaling
z/OS z/OS SYSPLEX brings vast potential processing capacity to Message Broker V6. Not
only are z9 processors extremely powerful on their own, but up to 32 can be configured in a
single z/OS image. Moreover, up to 32 z/OS images can participate in a SYSPLEX
configuration. Message Broker V6 is designed to exploit all of these capabilities without any
design changes to message flows.
Message flows have a built-in multiprocessing capability. Each instance of a message flow
can execute on a separate thread (z/OS TCB), letting the broker easily exploit multiple CPUs.
If a flow is not able to process enough messages due to a CPU constraint, it is simple to assign
more instances to the message flow to dynamically increase the number of eligible CPUs for
processing. No outages or changes in flow design are needed.
When you need to deploy flows across multiple execution groups, for example, to overcome
the 2 GB virtual storage limit on z/OS address spaces, it is easy to assign a message flow
(including its additional instances, if necessary) to these new address spaces. Again, no design
changes are needed -- the flow is just assigned and becomes active automatically and without
broker restart.
As described above, it’s simple to scale message flows across the SYSPLEX by deploying to
multiple brokers within the SYSPLEX broker domain. Again, this reconfiguration process is
dynamic and does not require restart. Similarly, you can remove brokers, execution groups,
and message flow instances as needed.
Workload isolation
In some scenarios, message processing workloads must be separate from each other. For
example, regulatory requirements may mandate that infrastructure groups that are processing
workloads from third parties must keep those workloads separate. While you can assign a new
broker to each party, it is simpler and just as effective to assign separate execution group
address spaces to different types of work. From a storage isolation perspective, these
execution groups are completely separate, and storage in one address space is not visible to
another execution group. In the event of a failure, an execution group is restarted without
affecting any execution groups owned by the broker -- failures are isolated to execution
groups.
Reporting and chargeback
System Management Facilities (SMF)
SMF collects and records performance and accounting information generated by z/OS
subsystems. This information is generally used for two purposes:
• Enable efficient and effective tuning of message flows.
• Enable infrastructure departments to charge users for their use of broker facilities, in
accordance with agreed metrics, to help recover the cost of the infrastructure.
Message Broker V6 lets operational staff gather SMF data per message flow. Message flow
developers do not need to instrument their designs in any way. Once the operator enables
statistics for a message flow, the broker measures a broad range of flow- and node-related
metrics, including CPU, IO, and user-relevant metrics such as number of messages processed,
maximum message size, and average elapsed time. Common usage scenarios include using
the number of messages processed by a flow to chargeback, and measuring the CPU, IO, and
elapsed time averages for a node within a flow for hotspot analysis.
In some situations, message flow designers may wish to influence data by determining the
source of messages processed by the broker, when a single message flow is processing
requests on behalf of many disparate users. The flow designer might, for example, extract an
application identifier from an MQ Message Descriptor field, or they might extract a
department code from a message body. Once the flow designer determines the accounting
origin, Message Broker V6 will partition performance and accounting information for this
origin and record it separately to SMF, which lets you detail exact usage by a particular user
or department.
Coordinated reporting
SMF also lets subsystems report performance and accounting information at the same time for
a given processing interval, which lets you correlate statistics between Message Broker V6,
WebSphere MQ, and DB2 subsystems and artifacts. This capability provides a powerful
performance analysis tool for understanding relationships between subsystems.
Event Notification Flag 37 (ENF37) is signaled by SMF when it wishes subsystems to write
performance and accounting information. Message Broker V6 is enabled for coordinated SMF
reporting using ENF 37.
Reduced cost of ownership
These improvements mean that existing users will see significant benefit from moving to
Message Broker V6. Similarly, new users can be confident that z/OS broker-based solutions
deliver a high-performance solution with excellent value for the money.
Using zSeries Application Assist Processor (zAAP)
You can now offload machine instructions generated by the Java Virtual Machine to
dedicated processors called zAAPs. A zAAP costs significantly less than a regular central
processor, and zAAP capacity is not included in MSU capacity. Therefore you can offload
Java-based applications without any increase in software costs. zAAP is available with z/OS
V1.6 or later.
Message Broker V6 has several features that directly exploit zAAP technology, namely the
Java Compute node, XLST node, and JMS Real-time and Multicast nodes. Therefore message
transformations in Java and XSLT may be able to offload a significant percentage of their
workload. Message distribution using JMS real-time and Multicast transports will similarly
benefit.
The Java Compute node has been designed to cater for the needs of integration developers
who wish to use Java as a transformation and routing language. All transformation logic
written in these nodes is eligible for offload to zAAP. (However, parsing operations are still
performed by non-Java components and are not eligible for offload). The exact offload
amount depends on the amount of transformation logic compared to the amount of parsing.
For simple messages that don't require too much parsing, or relatively complex message
transformations, the zAAP offload should be significant.
XSLT processing, while requiring an XML input message, is increasingly significant.
Because processing is entirely in Java, offload ratios as high as 80% have been observed in
lab tests using this node. JMS Real-Time and Multicast components can be fully offloaded to
zAAP, which means that non-queue-based pub/sub messaging involving a z/OS broker can
benefit significantly. Also, the Configuration Manager is implemented in Java, so on z/OS, all
of its CPU processing can be offloaded to zAAP.
50% Performance Improvement with V6
Message Broker V6 is an industry leader in high-performance transformation and routing. But
the CPU cost associated with these functions is significantly higher than with traditional data
processing. For example, parsing large XML documents requires lots of processor cycles. To
dramatically reduce cost of ownership, IBM has made significant performance improvements
in Message Broker V6 compared to previous versions.
Message Broker V5 and V6 were compared using a comprehensive range of tests involving
different messaging styles, protocols, and message formats. In customer-oriented end-to-end
messaging scenarios, messaging throughput increased by 50% with Message Broker V6.
These reductions in processing costs are in addition to benefits from zAAP offloading when
using broker Java components. The improvements were achieved without external product
interface changes, so if you migrate from a previous release, you should see these
performance improvements for existing message flows without changes to integration logic.
These improvements have been achieved without external product interface changes, meaning
that users migrating from previous releases will see an improvement for existing message
flows without having to change their integration logic. These performance improvements
result from work in the following areas:
• Parser improvements: Industry based (e.g. SWIFT) and record based (COBOL/C)
parsers have seen improvements by up to a factor of four
 • ESQL improvements: Implementation has been thoroughly analysed and their
implementation improved by an average factor of two
• Locking and scalability: A significant reduction in CPU cost and wait times in
multiprocessing environments
• Aggregation implementation: MQ based implementation rather than database to give
up to four times improvement in throughput
• zSeries and z/OS technology exploitation
o XML Toolkit

 Exploitation of Unicode conversion services and native hardware

features
o IEE754

 Exploitation of native hardware IEE754 floating point operations

o New Compiler algorithms

 Generation of machine instructions for latest hardware ARCH(3) and

above
 Aggressive compiler optimization OPT(3)
 64 bit multiply and divide algorithm enhancements
 Native Unicode string generation
o z/OS 1.5 or above

 Complete XPLINK exploitation of LE, Broker, JVM and ODBC

New features
New features in Message Broker V6 let you perform existing processes more effectively:
• Java Compute Node to enable zAAP offload
• DATETIME and field formatting enhancements to simplify the most common
transformation operations and reduce their CPU cost
• Semi-persistent environment to improve message routing and counting scenarios
• MQGET node to maintain, where appropriate, processing context; and improve
request response processing performance
• Compact parsers for XML to reduce the CPU to read, write and navigate XML
documents
• Unicode database support to efficiently store data from worldwide sources without
loss
New pricing
IBM has reduced the price of Message Broker V6 compared to V5. In addition, V6 is
available in a "start-small-and-grow" edition at a reduced cost. This edition includes all
Message Broker V6 capabilities, and you can scale vertically by exploiting multiple CPUs,
including zAAPs. The only limitation is a capacity restriction of a single execution group per
broker, limiting processing to a single z/OS address space, which is sufficient for typical
initial deployments of Message Broker V6.
Operational characteristics
Using Message Broker V6 is a familiar experience for z/OS users. Whether you are dealing
with installation, customization, command and console support, problem determination,
coexistence, or security, Message Broker V6 looks and feels like a z/OS product. So you can
use all of your existing z/OS skills when creating and managing your Message Broker V6
infrastructure on z/OS.
Installation and customization
Message Broker V6 is installed using SMP/E, which makes it a familiar experience for z/OS
systems programmers. Fixes are delivered at PTFs and can be applied as necessary using
SMP/E. Collections of fixes delivered as fix packs supersede any installed PTFs, which gives
you a seamless upgrade path to the latest level of code.
Creating brokers, configuration managers, and user name servers is all JCL-based. Since most
z/OS users know JCL, they can integrate z/OS customization procedures for broker
components with existing procedures.
Command and console support
Broker component commands are available as JCL commands and via the MVS console. All
JCL command output is written to the JES SPOOL as expected. All MVS console output
appears on the MVS LOG.
Problem determination
Message Broker V6 writes informational, warning, and error messages to z/OS JOBLOGs for
each execution group, which gives operators a time-stamped record of all events in a broker
execution group. Messages for z/OS brokers and configuration managers also include a
JOBLOG audit trail to detail all changes and operations. Examples of these operations include
new and changed deployments, and actions on message flows such as starting and stopping
them. Combined with message flow and message set versioning, this lets operators quickly
determine the source of changes to their broker environment on z/OS.
If Message Broker V6 detects an internal error during processing, it produces a system dump
with code S2C1. This dump is written to a regular MVS dump dataset and can be used by
IBM Support to determine the reason for the error, and if necessary, provide a fix or
temporary workaround for the problem.
Coexistence and migration
Message Broker V6 is typically installed alongside previous versions, and you can have
multiple versions installed and operational. Therefore you can take a piecemeal rather than
big-bang approach to migration, moving artifacts to V6 on a schedule that fits your business
needs. You can also migrate Message Broker V6 components forwards and backwards
between versions, which is useful if the rollout of a migrated broker needs to be backed off, or
if business readiness requires it.
Security
You can secure all Message Broker V6 components using SAF-compliant security manager.
Broker, Configuration Manager, and User Name Servers all run as started tasks and are
assigned an appropriate z/OS user ID. Their access to z/OS resources nay be controlled
according to this user’s rights by a SAF-compliant security manager. The Configuration
Manager provides access control lists based on RACF users and groups to determine which
users are allowed to interact with the broker domain, and the level of command support to
which they are entitled.
Resource Recovery Services (RSS)
RRS is the transaction coordinator for Message Broker V6. Most z/OS subsystems are now
RRS enabled (MQ, DB2, CICS, VSAM), and hence any work performed by the broker is by
default within a fully transactional unit of work. Any node within a message flow that
interacts with an RRS-enabled resource manager is automatically enlisted in a transaction,
including user-developed and third-party nodes.
The Message Broker V6 transaction model is extremely powerful, enabling arbitrary nodes
within a message flow to participate within a transaction. In most cases, all resources are
updated as a single unit of work, but there can be cases where the ability to commit work
independently of a larger transaction is desirable, such as in logging successful and
unsuccessful transactions.
Disaster recovery
All key broker components needed for production systems are available on z/OS, providing a
solid platform for building a disaster recovery solution. Message Broker V6 is not a resource
manager like WebSphere MQ or DB2, so it does not have any transaction logs or page sets to
manage, which simplifies disaster recovery solutions. An effective disaster recovery
procedure requires all components and resources to be considered, and this article discusses
only Message Broker V6 aspects.
Message Broker V6 resources under consideration fall into three categories:
• Topology information such as brokers and any inter-broker domain connections,
execution groups within these brokers, and assignment of message flows within
execution groups.
• Development Artifacts such as message flows, message sets, JAR files and style
sheets.
• Run-time state information such as durable subscriber details, retained publications,
and in-flight aggregation state, which is held in WebSphere MQ queues and DB2
database tables.
In a disaster, all of these resources may be lost on the active system and may need to be
restored on a backup system at a state as close as possible to the state at time of failure.
First, all topology information must be restored. Whenever a change to a production
configuration is made, a record of the change needs to be made. Re-creation of topology
information can performed using JCL command scripts or the Configuration Manager
programming interface, as preferred. The record of the topology information is used to re-
create the environment from the last deployment change.
The vast majority of development artifacts are contained in BAR files. At the time of
deployment to a production system, a copy of the deployed BAR file should be made
available on the backup system. Any development resources deployed by hand should also be
made on the backup system. In the event of a failure, JCL command scripts or programming
interfaces are used to redeploy resources to brokers and execution groups as necessary.
Finally, run-time state is either restored from disaster recovery of WebSphere MQ or DB2
resources, or manually by end user applications if this is not possible. If this failed state is not
recovered, end users will have to remake the lost state. For infrequently changing information
such as durable and retained publications, it is relatively easy to make this information, but
restoring in-flight aggregation states is more difficult.
Message Broker V6 lets you create a fully scripted disaster recovery procedure that can be
rehearsed and followed by operational staff in the event of a disaster.
z/OS Specific nodes
Message Broker V6 contains all components and capabilities available with the family of
platform offerings, as well as significant design enhancements to support z/OS, as described
above. However, some nodes are available only on z/OS for interaction with unique z/OS
datasources and subsystems.
VSAM nodes
Message Broker V6 can process VSAM records in the same way as it processes messages
from or to other data sources. Message Broker V6 support for VSAM consists of a suite of
five nodes that let you perform record-oriented processing on VSAM files, including input,
read, write, update, and delete operations. You can combine these nodes for VSAM access
with other nodes to integrate VSAM processing into message flows, or use VSAM files to
drive message flow processing. Consider the following scenarios:
• Batch input processing
• Read a specified number of records from a VSAM data set and propagate each record
to subsequent nodes in your message flow
• With update processing allows record locking for update later in a message flow
• Data Enrichment and Routing from VSAM
• Use VSAM as a database to perform data enrichment or message routing
• Data logging to VSAM
• Record interesting events to a VSAM file
• Deletion of VSAM data
• Remove VSAM file records on the basis of message processing
These nodes are delivered as a category 3 fully supported SupportPac -- IA13. For details, see
Resources below.
QSAM nodes
A set of z/OS-specific nodes is also available for QSAM processing. These are similar in
concept and usage to the VSAM nodes, but oriented around sequential files, rather than
record-oriented files. These nodes are delivered as a category 3 fully supported SupportPac --
IA11. Details on where to get the node are are provided in the resources section.
CICS node
It has always been possible to drive CICS transactions using MQ messages generated by the
broker, either directly, if the CICS transaction program is MQ enabled, or via the CICS DPL
or 3270 bridge. However, there are disadvantages with this approach from a broker
perspective:
• The flow is broken into several legs, which means that processing is more complex.
• More transactions are required to achieve processing.
• The requesting context needs to be re-established when the response from CICS is
returned, which may involve expensive operations such as reparsing the original input
message.
The CICS request node lets a CICS program be driven synchronously within a message flow,
simplifying the flow structure, reducing the number of transactions, and maintaining the
processing context while the request is being handled by CICS.
Message Broker V6 processing using the CICS node is greatly simplified and improves
performance up to 3X (for details, see Support Pac IA12). The CICS node extracts a
COMMAREA from a node-defined portion of the input message and uses the EXCI interface
to execute the appropriate transaction program. The resulting COMMAREA is added back to
the message tree upon completion of the transaction. The CICS transaction program may
operate within the RRS coordinated unit of work, or be committed immediately according to a
node attribute.
The CICS node is delivered as a category 3 fully supported SupportPac -- IA12. For details,
see Resources below.
Conclusion
This article has described how Message Broker for z/OS, V6 offers a high performance,
highly available, scalable and manageable enterprise messaging backbone for a diverse range
of messaging styles, protocols and formats.
Message Broker V6 provides a first class z/OS subsystem implementation. It is very well
integrated with the key characteristics of the z/OS platform, which its users expect for their
business processing. These include:
• Availability
• Reliability
• Scalability
• Workload management
• Operational control
• Comprehensive reporting
 • Security
• Disaster recovery
Message Broker V6 and z/OS combine to form a powerful integration platform for
messaging.