WebSphere MQ 7.1
Migration
Agenda




PTFs de toleration & coexistence
Serverpac issue
Hiper apars
WMQ V7.1
PTFs



PM55455 - v710 fix problems encountered in
qmgr and chin - needed for stability and
migration => UK76567 open
PM52894 - v701, backward migration from
v710 and coexistence with v710 + prereq
PM55306 - BIND plan CSQ5U7A1
PM52877 - v600, backward migration from
v710 and coexistence with v710 - BIND plan
CSQ5U603
Server Pac issue


APAR OA38849 SERVERPAC CUSTOMERS
INSTALLING WEBSPHERE MQ BASE 7.1.0
PRIOR TO FEB 2012 MISSING CSQNL25E
CSQFSTAB FOR FMID HMS7100.
Customers can run SMP/E GENERATE for
FMID HMS7100 and execute the resulting link
edit statements / step for the missing load
module and it's alias
Hiper Apars WMQ V7.1

PM58258 WMQ V7.1 - QUEUE
MANAGER LOOPS AFTER A DISPLAY
QSTATUS DIS QMGR COMMAND IS
ISSUED AND MONQ IS NOT OFF.
QSG V7.0.1 V7.1

New structure CSQSYSAPPL for :


SYSTEM.QSG.CHANNEL.SYNCQ
SYSTEM.QSG.UR.RESOLUTION.QUEUE
must reside on.
WMQ V7.1

Features requiring OPMODE=(NEWFUNC,710):







CFLEVEL(5)
SMDS
CF Application structure connectivity loss toleration
(CFCONLOS)
Automatic CF application structure recovery (RECAUTO)
IMS resource monitoring (MQ-IMS Bridge)
CF Administrative connectivity loss toleration (CFCONLOS on
the QMGR object)
CICS 4.2 and MQ 7.1 support CICS group UR
WMQ V7.1 SMDS






large shared message can now be stored in a shared message
data set (SMDS)
Much faster than DB2 for large messages
DEFINE CFSTRUCT option OFFLOAD(SMDS|DB2) at new
CFLEVEL(5)
Can switch between writing new large messages to shared
message data sets or DB2
offload rules
Each application structure has an associated group of shared
message data sets, with one data set per queue manager.
 Named using DSGROUP parameter on CFSTRUCT
definition.
WMQ V7.1 SMDS Characteristics



Each shared message data set is a VSAM linear data
set.
Data set space is managed in blocks of a fixed size
(usually 256K).
Message data blocks are referenced directly by
information in CF entry.
 Entry contains list of starting CI numbers of each
message block.
 No need for any index or similar indirect
mechanism as in DB2.
Shared message data sets for two queue managers
z/OS SYS1
QM01
z/OS SYS2
CFSTRUCT(APPL1)
QM02
SHRQ1
Read-only
Read-only
Read/Write
Read/Write
SMDS(QM01)
SMDS(QM02)
WMQ V7.1 SMDS Offload rules




Offload rules at CFLEVEL(5) apply to DB2 as well as SMDS.
Each structure has three offload rules, specified on the CFSTRUCT
definition
Each rule specifies a message size and a structure usage threshold
percentage using a pair of keywords
OFFLD1SZ(size) and OFFLD1TH(percentage)
OFFLD2SZ(size) and OFFLD2TH(percentage)
OFFLD3SZ(size) and OFFLD3TH(percentage)
Each rule means that a new message exceeding the specified
total CF entry size has its data offloaded (as for a large
message) if the structure usage currently exceeds the specified
percentage.
WMQ V7.1 SMDS



Normal Run : Queue manager opens own SMDS
read/write, other SMDS read
DISPLAY SMDSCONN shows current status and
availability
OFFLDUSE by DISPLAY CFSTATUS shows usage DB2,
SMDS or both
WMQ V7.1 SMDS performance tests on z196
Achieved Transaction Rate 3 LPAR Non-DataSharing Test
Achieved Transaction Rate 3 LPAR Non-DataSharing Test
64KB Non-Pers is tent Mes s ages In-Sync point - D B2
64KB Non-Pers is tent Mes s ages In-Sync point - SMD S
400
7000
6000
300
Transactions / Second
Transactions / Second
350
250
200
150
100
50
0
5000
4000
3000
2000
1000
0
1
2
3
4
5
6
7
8
9
10
1
2
3
Queue Pairs
NP SIS Scaling –
3 qmgr
NP SIS Scaling –
6 qmgr
4
5
6
7
8
9
Queue Pairs
NP SIS Scaling –
9 qmgr
NP SIS Scaling –
3 qmgr
NP SIS Scaling –
6 qmgr
NP SIS Scaling –
9 qmgr
 Tests show comparable CPU savings making SMDS a much more usable feature for managing your CF Storage usage
 SMDS per CF structure provides better scaling than DB2 BLOB storage
 zBLC Req. WRBC0407-1050 (RBC) (CF Flash Offload will complete the story !)
13
10
WMQ V7.1 CF resilience



Tolerate loss of connectivity to CF structures
without abending
Attempt to rebuild structures into a better
location following loss of connectivity
Automatically recover failed structures during
queue manager startup
WMQ V7.1 CF resilience




QMGR CFCONLOS(TERMINATE|TOLERATE)
 Specifies whether loss of connectivity to the admin structure
should be tolerated, default is TERMINATE
CFSTRUCT CFCONLOS(TERMINATE|TOLERATE|ASQMGR)
 Specifies whether loss of connectivity to application
structures should be tolerated, only available at CFLEVEL(5)
CFSTRUCT RECAUTO(YES|NO)
 Specifies whether application structures should be
automatically recovered
New command : RESET CFSTRUCT ACTION(FAIL)
 Allows CF structures to be failed by administrator command
 Intended as a last resort in situations where a structure
needs to be deleted and then recovered, possibly in a
different CF
WMQ V7.1 CF – Admin structure






Queue managers will tolerate loss of connectivity to the admin
structure without terminating if the QMGR CFCONLOS attribute is set to
TOLERATE
All queue managers in the QSG will disconnect from the admin
structure, then attempt to reconnect and rebuild their own admin
structure data
If a queue manager cannot reconnect to the admin structure, for
example because there is no CF available with better connectivity,
some shared queue operations will remain unavailable until the queue
manager can successfully reconnect to the admin structure and rebuild
its admin structure data
The queue manager will automatically reconnect to the admin structure
when a suitable CF becomes available on the system
Failure to connect to the admin structure during queue manager
startup is not tolerated, regardless of the value of CFCONLOS
Console message issued during queue manager startup and whenever
the QMGR CFCONLOS attribute is altered to indicate whether loss of
connectivity to the admin structure is tolerated
WMQ V7.1 CF – Application structure



All queue managers that lose connectivity to an application
structure will disconnect from the structure
The next action depends on whether it is a partial or total loss
of connectivity (according to MQ’s definition)
 loss of connectivity is partial if there is at least one system in
the sysplex that still has connectivity to the CF that the
structure is allocated in.
 loss of connectivity is total if all systems in the sysplex have
lost connectivity to the CF that the structure is allocated in.
In the case of total loss of connectivity
 the structure will (probably) need to be recovered using the
RECOVER CFSTRUCT command
 non-persistent messages will be lost
WMQ V7.1 CF – Application structure



If the case of partial loss of connectivity

queue managers that lost connectivity to the structure will attempt
to initiate a system-managed rebuild in order to move the structure
to another CF with better connectivity

if the rebuild is successful, both persistent and non-persistent
messages will be copied to the other CF

queue managers that didn’t lose connectivity to the structure may
experience a slight delay during system-managed rebuild
processing, but shared queues will remain available
If an application structure cannot be reallocated in another CF with
better connectivity, queues on the structure will remain unavailable
until connectivity is restored to the CF that the structure is allocated in

API calls will complete with reason code
MQRC_CF_NOT_AVAILABLE
Queue managers will automatically reconnect to the structure when it
becomes available
WMQ V7.1 CF – Automatic structure recovery



If a structure has been defined with RECAUTO(YES) it will be
automatically recovered in the following situations:

when a queue manager detects that it is failed or empty at
connection time (including during queue manager startup, when
the queue manager will now try to connect to all application
structures)

when a structure fails while a queue manager is connected

when a queue manager detects total loss of connectivity for a
structure that it is connected to
Automatic recovery will take place after a delay of a few seconds to
allow several structures to be recovered simultaneously
Recovery can take place on any queue manager in the QSG