WebSphere MQ 7.1 Migration

1. WebSphere MQ 7.1Migration

2. Agenda • PTFs de toleration & coexistence • Serverpac issue • Hiper apars • WMQ V7.1

3. 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

4. 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

5. 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.

6. QSG V7.0.1 V7.1 • New structure CSQSYSAPPL for : • SYSTEM.QSG.CHANNEL.SYNCQ • SYSTEM.QSG.UR.RESOLUTION.QUEUE must reside on.

7. 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

8. 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.

9. 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.

10. Shared message data sets for two queue managers z/OS SYS1 z/OS SYS2 CFSTRUCT(APPL1) QM02 QM01 SHRQ1 Read-only Read-only Read/Write Read/Write SMDS(QM01) SMDS(QM02)

11. 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.

12. 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

13. WMQ V7.1 SMDS performance tests on z196 • 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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