s57

IBM Software Group

WebSphere MQ V6 Overview with z/OS focus – May 2005Guide/Share Europe – Riga May 2005 S57

Dermot Flaherty – Messaging and ESB [email protected]

© 2005 IBM Corporation 1

2

IBM Software Group

© 2005 IBM Corporation S57 - Websphere MQ V6.0 Overview with z/OS emphasis

WebSphere MQ

¡ Makes it easy to connect applications and systems

¡ Once-only assured delivery of data

¡ Many environments� Broad range of operating system and hardware platforms� Supports range of programming languages� Communications Protocols� Point-to-point and publish-subscribe styles� ... all available through simple APIs

¡ The industry standard for industrial messaging

¡ Recently celebrated 10th anniversary!

3

IBM Software Group


Introduction

4

IBM Software Group


§This section give a quick overview to the release and environment in which it runs

WebSphere MQ V6 - Introduction

N

O

T

E

S

5

IBM Software Group


WebSphere MQ V6 - Themes

¡ In announcement letter 204-126 (June 2004) IBM issued a Statement of Direction:

“IBM intends to … release new versions of WMQ ... in 1H2005. These releases will make it even easier to build and extend your ESB ...”

¡ Improved Usability� Simple File Transfer, Quick Tour� New cross-platform configuration tooling

¡ Improvements to manageability � Find out what the system is doing, and influence it� Easier problem determination and problem avoidance

¡ Improved Availability� Exploiting z/OS services

¡ Extended performance, capacity and scalability� Exploiting 64-bit address space

¡ This presentation shows how IBM has met this statement

6

IBM Software Group


§As a new version of WMQ is planned, we try to classify all of the candidate pieces of work into a small number of themes. These are the key priorities for the release, and function ought to fit in one or more of the themes for it to get a chance of being implemented. (Remember that there are always many more candidate pieces of function than we could ever develop in an acceptable time or at anacceptable code. Although anything that doesn't make one release is automatically given a chance of being put into the next release.)

§Two areas we wanted to look at this time around were a) making it easy for people who were new to WMQ to pick it up and use it quickly and b) making it easier to manage WMQ even if you are experienced with earlier versions.

§We have been carrying on some of the z/OS-specific activity, completing what should be the final phase of the shared queue work

§And also making a number of enhancements to reflect broader industry activity.

§Details of many of these items will now appear on the next slides

WebSphere MQ V6 - Themes

N

O

T

E

S

7

IBM Software Group


Schedule

¡ Beta program started September 2004� A program for a limited number of customers and partners

¡ Announcement on April 19 2005� Open beta for some platforms on or soon after announcement

¡ Electronic GA (downloadable) in May 2005 for Distributed platforms

¡ Physical media and z/OS GA in June 2005

8

IBM Software Group


Initial Platform Coverage

¡ AIX 5 (64-bit systems only)

¡ Solaris (64-bit Sparc systems only)

¡ HP-UX 11i (64-bit PA-RISC only)

¡ Linux/Intel (32-bit), Linux/pSeries (64-bit distros only), Linux/zSeries� RHEL3, (RHEL4), SuSE8, SuSe9

¡ z/OS 1.4

¡ Windows 2000, XP, 2003

¡ OS/400 V5R2, i5/OS V5R3

9

IBM Software Group


§WMQ V6 has essentially the same platform coverage as V5.3, although the base level of some of the operating systems has been increased. For more detail on which levels of each OS have been tested/supported look at

§http://www-306.ibm.com/software/integration/websphere/mqplatforms/supported.html

§This Supported Software web page changes regularly as new environments get tested, and is the official location for what is supported by a version of WMQ.

§On Linux, you will now see specific distributions (eg Red Hat and SUSE) listed as the supported environments, rather than the more general prereqs that were stated at V5.3. This is inline with IBM SWG policy, and makes it easier to compare different products, to ensure they all have the same required levels of software. On Linux/zSeries we will only be testing the 64-bit distros, although WMQ on this platform is only a 32-bit product.

§In this set of platforms we do not include any support for Itanium-based operating systems.

Initial Platform Coverage

N

O

T

E

S

�http://www-306.ibm.com/software/integration/websphere/mqplatforms/supported.html

10

IBM Software Group


Other Platforms

¡ Other platforms/environments (eg 64-bit) under consideration for a later GA2� April 19 announcement includes a Statement of Direction for these� "In the second half of 2005, IBM intends to deliver WebSphere MQ V6.0 on

additional platforms, including but not limited to, variants of HP-UX and Linux."

¡ OpenVMS recently upgraded to V5.3� Both Alpha and Itanium hardware� Includes SSL support

¡ Statement of Direction for Tandem (NSK/NSS) to ship a V5.3 port in 2H05� Both MIPS and Itanium hardware� Includes SSL support

11

IBM Software Group


§There are clearly additional platforms where customers might like to have WMQ V6, and the Statement of Direction in the April 19announcement acknowledges this. Not all environments could be delivered in one set, and we expect to deliver some additional platforms later.

§Two platforms have been at V5.1 for a while: OpenVMS and HP NSS (aka NSK aka Tandem). The V5.3 OpenVMS port shipped in January 2005 and there was also a Statement of Direction for HP NSS that a V5.3 port will be shipped towards the end of 2005.

§The ports are based on V5.3 FP06 source code, and provide all the appropriate function for the platform, as well as some platform-unique capabilities. In particular, SSL channels will be supported on both of the products.

§And on HP NSS, there are a number of extensions to the code to match the Non-Stop environment.

Other Platforms

N

O

T

E

S

12

IBM Software Group


Support Status

¡ Everyone should be at V5.3 or V5.3.1, and should consider migrating to V6

¡ V5.2 ended its support some time ago� From Jan 1 2004 on Windows, Unix, Linux� From April 30 2004 on z/OS, OS/400

¡ V5.3 Distributed EOS dates show as "open" on the official website� This means that there will, at some point, be an announcement giving minimum 12

months notice of withdrawal of support� Change in SWG support strategy for Distributed; closer matches how z/OS does it� This means the EARLIEST POSSIBLE EOS for V5.3 is September 2006.

Improvement on the year-on-year extensions we had before for Distributed

¡ V5.3.1 for z/OS also has “open” EOS� V5.3 for z/OS has EOS October 2005

¡ No statement has yet been made about the EOS for V5.3� Its date will be set to give a suitable migration period to V6

13

IBM Software Group


§Important to know these dates! All customers should by now be on V5.3 (or 5.3.1 on z/OS). They will not be able to get support for earlier versions (where there is a superceding product). We are also finally ending marketing - and then support -of some very old platform versions that were never updated to V5.

§The rules changed, for the better, on the Distributed platforms. This is intended to make it easier to put together a set of products, with an expectation of a reasonable lifetime.

§Lots of older SupportPacs (both cat2 and cat3) have been removed or semi-hidden. This should make it easier to find the supported or "useful" material that is still relevant to the current products.

§V5.3 for z/OS does have an EOS date; all customers should be using V5.3.1 instead.

§No statement has yet been made about EOS for V5.3; a date will be set that gives customers a reasonable time to migrate to V6. Even when the normal EOS happens, additional support can normally be purchased for up to two more years.

Current Support Status

N

O

T

E

S

14

IBM Software Group


New functions

15

IBM Software Group


§Now we'll move into the main part of the presentation, the new function

WebSphere MQ V6 – New functions

N

O

T

E

S

16

IBM Software Group


Getting to know WMQ

¡ For people new to WMQ there are two items on Windows and Linux:

¡ 1. The QuickTour� Animation that demonstrates the concepts and terminology of WMQ

¡ 2. File Transfer� A simple application that works “out-of-the-box”. � No need to write your own test programs.� Command line and GUI� Very, very simple ... not even CR/LF conversion

¡ These are updated versions of what was in WMQ Express V5.3

17

IBM Software Group


File Transfer

18

IBM Software Group


File transfer

¡ This really is a simple transfer program

¡ It does not include any data conversion, not even ascii/ebcdic or cr/lf.

¡ There is a command line so people could write automated procedures around it.

¡ There is no real maximum file size as files are split into multiple MQ messages; a file does not have to fit into a single message.

N

O

T

E

S

19

IBM Software Group


Making it easier to configure WMQ

¡ A new graphical configuration tool based on Eclipse� Runs on Linux and Windows

¡ Replaces the MMC snap-in on WMQ V5.3 for Windows

¡ Can connect to, and configure, WMQ on all platforms� Including WMQ V6 for z/OS (but not earlier versions on z/OS)� Connections can be local or direct client or via intermediate qmgr� Supports SSL for secure communication

¡ Extensible� We hope to include more plug-ins in the future� Vendors and users can develop new function and integrate seamlessly

¡ Documented interfaces allow� New options to be put on the “right mouse button” menus for objects� New top-level entities (like “queue managers” and “Queue Sharing Groups”)� Plug-ins do not need to duplicate configuration work like getting list of queue mgrs

20

IBM Software Group


§We're replacing the current MMC-based graphical tool with something that looks fairly similar, but built on top of the Eclipse (IBM Workbench) package. This makes it much more portable, and although it initially will only be supported on Windows and Linux, it has the potential to be supported elsewhere.

§There are a number of enhancements compared to the MMC snap-in, including:

ƒ1. It is able to control WMQ V6 for z/OS, including platform-unique functions such as shared queuesƒ2. It has more variations on how to connect to remote queue managers, including SSL channelsƒ3. It has documented extension points which will allow more plug-ins to be developed, to appear as

seamless interfaces§All new function in V6 is available from the GUI, as well as being able to manage V5.3 (and older) Distributed platforms.

§Because of the componentised nature of Eclipse plug-ins it is easy for IBM to add new capabilities through service updates to WMQ, without disrupting other function.

Configuration Tooling

N

O

T

E

S

21

IBM Software Group


§We ship a Workbench, customised to run the WMQ plug-in by default, but these plug-ins could be added to other Workbenches where they are at the same level. For example, when Message Broker tooling uses the same level of Eclipse it could present a single panel containing message flow development panels, and a list of the queues that message flow is going to access. WMQ will be based on Eclipse V3.01.

§The next group of slides are screenshots, showing how similar the basic interface is to the MMC view, but it fits with the Eclipse look-and-feel. The highlighted area ("Filter") on one screenshot provides access to a function we'll discuss in more detail later. But briefly, it will allow simple selections on the panels - eg only show queues with a depth greater than 10. This will make it easier to see what's happening, perhaps for Problem Determination.

§Lots of options to customise things like order of displayed columns, and save the schemes.

Configuration Tooling

N

O

T

E

S

22

IBM Software Group


Configuration Tooling Main Screen

23

IBM Software Group


Configuration Tooling – WMQ Clusters and QSGs

24

IBM Software Group


Configuration Tooling - Looking at Queues

25

IBM Software Group


DIS CONN(*) ALLAMQ8276: Display Connection details.CONN(3CF17F4020000E01)

TYPE(CONN) PID(3248) TID(1)APPLTAG(AMQAPI.EXE) APPLTYPE(WINDOWSNT)CHANNEL() CONNAME()CONNOPTS(MQCNO_STANDARD_BINDING)USERID(metaylor)UOWLOG() UOWSTDA(2004-04-16)UOWSTTI(15.56.15) UOWLOGDA(2004-04-16)UOWLOGTI(15.58.19) URTYPE(QMGR)QMURID(0.7)

Who is using the queue manager

¡ Already have DISPLAY QSTATUS to show who is using a queue

¡ New command DISPLAY CONN to show who is connected and which queues they have opened

¡ New command STOP CONN to force a disconnect (not on z/OS)

¡ Also shows UOW timestamps

26

IBM Software Group


§In V5.2 and V5.3 commands were added to show who was accessing a queue. In V6 we add a new command to show who is accessing the queue manager. This will show similar information to QSTATUS, to identify the user - channel name, pid, tid, program name etc. But it also shows HOW the connection was made, and details of any transaction that might be in progress. Using the UOW information, it is possible to see which application might have a long-running UOW, and hence which application might be causing log files to fill up. It also shows whether the transaction is internal or external, whether it is a participant in a global transaction etc.

§The 2nd example, on this page, shows the list of queues that the application has open, and which options were used for the MQOPEN.

§On Distributed platforms, the CONN tag can be used to break the connection to the qmgr. A WMQ administrator might not have operating system privileges to kill an errant application, but can remove its access to WMQ. The program itself is not killed, but any in-flight work is backed out, and any further API call from that program will get CONNECTION_BROKEN. Ending the connection will allow recovery logfiles to move forward, and the queue manager could be stopped normally. There are technical reasons why this could not be implemented on z/OS at this stage, but other enhancements (“log shunting”) on that platform reducethe problems caused by long-running UoW.

DIS CONN(*) WHERE(PID EQ 3248) TYPE(HANDLE) ALLAMQ8276: Display Connection details.CONN(3CF17F4020000E01)

TYPE(CONN)OBJNAME(LOCALQ) OBJTYPE(QUEUE)OPENOPTS(MQOO_INPUT_SHARED,MQOO_OUTPUT,MQOO_FAIL_IF_QUIESCING)


N

O

T

E

S

27

IBM Software Group



28

IBM Software Group


§This screenshot shows how it appears in the GUI


N

O

T

E

S

29

IBM Software Group


Easier to link applications with the queue manager

¡ Can now have applications automatically started and stopped along with the queue manager (Distributed platforms)� Trigger monitors, listeners, user apps ... � Could even be a runmqsc script� Variable substitutions: +QMNAME+ etc

30

IBM Software Group


§We’ve just seen how to display the applications that are connected to the queue manager. But this new panel also makes it easierto assign applications to automatically be started (and stopped) along with the queue manager. The SERVICE definitions allow us to define programs, and have them started at the same time as the queue manager. This replaces the “custom services” panels that were on Windows. There are some well-known services – listeners and the command server – which have special definitions, but any other program can also be defined. For example, a broker or a trigger monitor. There are attributes to allow stdout/stderrto be redirected to files.

§This is available on Distributed platforms only; z/OS already has this kind of capability built into the operating system.

Easier to link applications with the queue manager

N

O

T

E

S

31

IBM Software Group


Managing z/OS – adding PCF commands

¡ Making it easier to write administration and monitoring programs� Same programs can drive z/OS and Distributed platforms

¡ It has always been comparatively easy to convert a PCF command into MQSC

¡ The difficult bit has been parsing the responses� PCF is structured, self-describing format � MQSC is pseudo-English, random ordering

¡ z/OS Command Server is now able to handle both formats

¡ PCF structures extended to handle the multiple sets of responses from QSGs� Other extensions to the “language” for new structures� E.g 64-bit, name-value pairs

¡ All appropriate z/OS commands get PCF definitions� There are still a few that only make sense for local consoles � E.g. START/STOP TRACE

32

IBM Software Group



¡ All existing PCF commands that apply to z/OS

� Object commands, like -Create/Change/Delete/Inquire Queue, Inquire Queue Status

� Operation commands, like -Start/Stop Channel, Refresh Cluster, Start Channel Initiator

¡ Most other z/OS-only commands

� Object commands, like -MOVE QLOCAL, DEFINE/ALTER/DISPLAY/DELETE STGCLASS

� Operation commands, like -ALTER SECURITY, DISPLAY USAGE, DISPLAY DQM, STOP CHINIT

¡ But not some special commands like -START/STOP TRACE, ARCHIVE LOG, RESET TPIPE

33

IBM Software Group


§Support for PCF command messages has been added to z/OS. This makes it easier to write a single management application that can work with both Distributed and z/OS queue managers. This ought to reduce the time-to-market for products to support new features; and reduce the time taken to write home-grown management tools. A QALIAS definition has been created so you don’t even need to know that the command input queue has traditionally had different names on z/OS and Distributed platforms.

§The "language" has been extended for PCF messages. The new format is required for z/OS control. There are also many other extensions to the PCF definitions, which can now allow arbitrary “name/value” pairs.

§You can continue to use MQSC format messages if you wish, for administration - the command server will process both.

§The PCF interface is exploited by the new Eclipse-based MQ Explorer when managing WMQ for z/OS; this is why only V6 is supported by the Explorer on that platform.


N

O

T

E

S

34

IBM Software Group


Improved availability for z/OS

¡ 63KB limit for Shared Queue messages now removed

¡ Dynamic recovery from Shared Queue Administration Structure failure

¡ Non-shared message pagesets can now be up to 64GB in size

¡ Dynamic addition and deletion of pagesets and buffer pools

¡ Dynamic addition and deletion of buffers in a buffer pool

¡ Dynamic addition of active log datasets

¡ Pre-emptive pageset expansion

¡ Dynamic setting of CHIN parameters

¡ Multiple TCP/IP stack support

¡ Multiple browsers for the CICS Bridge

¡ SUSPEND/RESUME IMS Bridge commands

35

IBM Software Group


z/OS Availability – Large messages on Shared Queues

¡ Removes the 63KB limit for shared queues so removing a significant constraint for WMQ application exploitation of shared queues � Maximum shared queue message length now 100MB� same as that for non-shared messages

¡ Uses DB2 to store large message payloads as BLOBs� Header stored as V5.3 in CF with pointer to BLOB� Transparent to applications� Small messages stored as in V5.3, without DB2

¡ There are performance implications ...� Expect degradation (indications are >4x for large persistent messages)� All customer feedback indicates that only a small percentage of applications that

use shared queues will have messages > 63KB so the performance cost is believed to be acceptable

¡ Administrator control of whether it is permitted

36

IBM Software Group


z/OS Availability – Large SQ message setup

¡ Requires TWO object changes:� ALTER / DEFINE SQ MAXMSGL(104857600) - up to 100MB� can be set independently of the CFLEVEL of the associated Structure object

� ALTER / DEFINE CFSTRUCT CFLEVEL(4)� the CFLEVEL attribute can be ALTERed up to 4 only if all the Qmgrs in the

QSG are at WMQ V6� the CFLEVEL attribute can be ALTERed down from 4 ONLY if all the shared

queues in that structure are empty and closed� Note: a WMQ V6 Qmgr can DEFINE a new structure object at CFLEVEL 4

even within a mixed QSG

¡ Additional parameter on QSGDATA keyword in CSQ6SYSP:-� Old: QSGDATA=(Qsgname,Dsgname,DB2name,DB2serv)� New: QSGDATA=(Qsgname,Dsgname,DB2name,DB2serv,DB2BLOB)� DB2BLOB - number of BLOB servers

– same as DB2serv (DB2 servers) - in range 4-10– default = 4– transparent - can compile existing ZPARM definitions

37

IBM Software Group


§This release completes the functionality for shared queue support within WMQ. Shared queues can now be used in exactly the same way as private queues. Both persistent and non-persistent messages can be up to 100MB.

§The Coupling Facility resources used by the queue manager stay the same, as we will not store more than 63KB of the message payload directly in the CF, even for these large messages. Instead, we put a "pointer" into the CF, and the main body of the message into a DB2 table which is then shared between the queue managers.

§Putting data into DB2 is slower than directly storing within WMQ, and we have observed a slow-down of these large messages compared to private queue storage. So this is not going to be recommended for system designs where ALL messages are going to be large. But for many applications - those which only have a minority of large messages - the slow-down of occasional messages will not be so important, especially if it is the price to pay for the higher availability (and better overall system design) that you can get with shared queues. Small messages continue to work at the same speed as in V5.3. We have observed slow-downs of at least 4x for large persistent messages, when compared to putting the same message on a private queue.

§Large messages have to be enabled by the system administrator

ƒCF structure where message will reside must be CFLEVEL(4). ƒMAXMSGL of the shared queue must be set to a large enough value to accommodate the size of the largest anticipated messageƒDB2 needs to be configured

§In WMQ for z/OS 5.3.1 failure of a queue-sharing group's administration (admin) CF structure will cause all the queue managers in the queue sharing group (QSG) to abnormally terminate. We thus recommend CF duplexing of your admin CF structures to reduce the possibility of CF structure failure. However this has an associated performance cost. In V6 we will enable queue managers within a QSG to tolerate failure of that QSG's admin CF structure. On detecting such a failure each queue manager will rebuild its part of the admin structure from its in-memory data. Peer recovery for a queue manager will be suspended until that queue manager has rebuilt its part of the admin structure, meaning that in-flight MQGETs and in-commit MQPUTs messages for the failed queue manager will only be available to other queue managers when the failed queue manager has restarted. All other applications, including shared queue applications, can carry on processing without the admin structure being available.

z/OS Availability – Large messages on Shared Queues

N

O

T

E

S

38

IBM Software Group


z/OS Availability – Toleration of Shared Queue Admin. Structure failure

¡ The Shared Queue Administration structure holds key WMQ control information across the queue-sharing group� Transaction state information to enable peer recovery� Serialised application support information� Structure interest information

¡ But today a loss of this structure will cause each connected Queue Manager to fail resulting in a total loss of the queue-sharing group

¡ In WMQ V6 this limitation is removed� Queue Managers will reconnect to/reallocate the structure� This is done automatically - no operator intervention required� Structure will be rebuilt from log data� Until the rebuild is complete some shared queue functions will not be available� existing threads keep running� no new shared channels can start� no Application structure rebuild is possible� no Queue Manager peer recovery is possible

39

IBM Software Group


z/OS Availability – Admin structure failure with V5.3 and V6.0

Queuemanager

Privatequeues

Queuemanager

Privatequeues

Queuemanager

Privatequeues

32SharedqueuesA

V6.0 Queuemanager

Privatequeues

V6.0 Queuemanager

Privatequeues

V5.3 Queuemanager

Privatequeues

V6.0 Queuemanager

Privatequeues

V6.0 Queuemanager

Privatequeues

32SharedqueuesA

40

IBM Software Group


z/OS Availability – Pagesets can now be 64GB in size

¡ In order to have page sets that exceed 4GB -� NEW PAGE SETS MUST BE CREATED

¡ Page sets MUST be DEFINED with an SMS DATA CLASS that specifies –� "EXTENDED ADDRESSABILITY"

¡ Create replacement page sets with the SAME SIZE as the page set that they replace, and REPRO old page sets to the new page sets - these page sets will 'grow' beyond 4GB by page set expansion

¡ Or brand new page sets can be allocated > 4GB and formatted ready for use

¡ Update QMGR JCL to point to new page sets

¡ Note: Existing page sets can continue to be used, but they will continue to have a maximum size of 4GB

41

IBM Software Group


z/OS Availability – Dynamic Pageset addition

¡ DEFINE PSID(x) BUFFERPOOL(y) EXPAND(z) DSN(abc)� (modified command)

¡ Page set must have been formatted with FORMAT RECOVER or FORMAT REPLACE - so a pre-existing page set, used in previous runs of a QMGR, but not available at restart, can be added into a running QMGR

¡ It is ready for use once the required Storage Class and Queue etc objects have been created

¡ If BUFFERPOOL(y) does not already exist, it will be created with all the buffers that can be safely allocated. Msg P001 shows how many were allocated at the end of the command processing. If virtual storage is not constrained, 1,000 buffers will be created.

¡ Buffers can then be removed from another pool, and added to the new pool, dynamically, if required.

42

IBM Software Group


z/OS Availability – Dynamic Pageset deletion

¡ DELETE PSID(x)� (new command)

¡ This can only succeed if no Storage Class object exists that uses this page set.

¡ So - no msgs, no in-flight URs, no in-doubt URs - the page set WILL be empty

¡ The page set is de-allocated, and the data set remains available for installation use.

43

IBM Software Group


z/OS Availability – Dynamic Buffer pool addition

¡ A new buffer pool can be created in one of two ways:

¡ Either a buffer pool was defined at restart and was not used

¡ Or a page set was dynamically defined and is associated with a previously non-existent buffer pool

¡ Note: The DEFINE BUFFPOOL command cannot be used after restart has completed

44

IBM Software Group


z/OS Availability – Dynamic Buffer pool deletion

¡ DELETE BUFFERPOOL(x)� (new command)

¡ Can only succeed if no PSID remains that uses this buffer pool. Therefore all page sets that use this buffer pool must have been deleted.

45

IBM Software Group


z/OS Availability – Dynamic Buffer pool sizing

¡ Judging the number of buffers required in a buffer pool is a black art

¡ Then you see msg "CSQP020 xxx Buffer pool x is too small" and you cannot do anything about it!

¡ Solution: Add some more buffers to the buffer pool (if appropriate)!

¡ But if you have allocated 'all' available buffers, you may need to first steal some from another buffer pool!

¡ So a new command becomes available:� ALTER BUFFPOOL(x) BUFFERS(y) where y is the new TOTAL # of buffers

� If y is greater than the current number of buffers, the difference is added� if less, the difference is removed

46

IBM Software Group


z/OS Availability – Dynamic Active log dataset addition

¡ Problem: Full active log ring� temporary problem with archiving

¡ Add new active log� DEFINE LOG(name) COPY(1|2)

¡ Dataset dynamically allocated

¡ Used as next in indicated 'ring'

47

IBM Software Group


z/OS Availability – Pre-emptive page set expansion

¡ A page set is dynamically extended before it becomes full� When page set is 90% full� Exception:

If page set is more than 90% full on restart, the first expansion will occur synchronously, and all Putters to relevant page set will be suspended (This is the today's behaviour)

¡ Expansion is performed Asynchronously from the MQPUT thread

¡ Other MQPUT threads on same page set are delayed by 5 milliseconds (system under stress) until expansion completes

¡ If the remaining 10% of the page set is all used before the expansion completes, following MQPUT tasks using the same page set will besuspended until completion (as before)

¡ A page set with NO secondary extents defined CAN be extended!

48

IBM Software Group


z/OS Availability – Pre-emptive page set expansion methods

¡ Method 1� No page set expansion is to take place

¡ Method 2� User specification for secondary extent size is honoured. If no secondary extent

size defined, page set expansion fails.

¡ Method 3� Secondary extent size is set at 10% of the 'current page set size'.� so size goes from 100, 110, 121... (rounded up to next cylinder boundary)

� Page set can grow to 75,000 times original size� Works if page set defined with no/zero secondary extent size

¡ Method is specified on the DEFINE PSID command in CSQINP1� Method 1 - DEF PSID(x) BUFFPOOL(y) EXPAND(NONE) � Method 2 - DEF PSID(x) BUFFPOOL(y) EXPAND(USER) � Method 3 - DEF PSID(x) BUFFPOOL(y) EXPAND(SYSTEM)

49

IBM Software Group


z/OS Availability – Dynamic CHIN parameter setting

¡ CSQXPARM parameters are now attributes of the Queue Manager object� Supports common methodology for “Queue Manager” parameter changes between

z/OS and Distributed Websphere MQ

¡ So with WMQ V6 no need for CHIN recycle

¡ Note: Some specific attributes may still require a recycle, determined on a case by case basis.

¡ Example –� ALTER QMGR ADOPTCHK(ALL)

ADOPTINT(120)ADOPTMCA(NO)TCPKEEP(YES)RCVTIME(X2)RCVTMIN(120)

50

IBM Software Group


z/OS Availability – Multiple TCP/IP stack support

¡ In some recovery scenarios WMQ may be running on a different LPAR with a different TCP/IP stack

¡ In these scenarios need to be able to specify both a Listener stack and the stack that an Outbound Channel should use

¡ New CHIN parameter TCPSTACK -� TCPSTACK=SINGLE� Restricts channels and listeners to the stack named in TCPNAME� CHIN will behave the same as with WMQ V5.3

� TCPSTACK=MULTIPLE� Channels and listeners may bind to any available stack� TCPNAME stack will be the default

¡ Listener IPADDR and channel LOCLADDR used as with WMQ 5.3 to indicate communications address within the stack

51

IBM Software Group


z/OS Availability – V5.3 CICS Bridge Monitor

¡ The CICS Bridge provides MQ interface to legacy CICS applications

¡ With WMQ 5.3 it comes in two flavours -� DPL Bridge - Link to program with data in Commarea� 3270 Bridge - Transaction with BMS map� Uses CICS Attach bridge facility

¡ Bridge monitor browses queue, performs authority checks and starts a transaction to process the message.

¡ BUT .. Significant restrictions� Only one bridge monitor per bridge queue� 3270 transactions cannot be routed to AORs� Reduces reliability and scalability because tied to single region

¡ Some enhancements introduced in MQ 5.3.1� Reply expiration, null truncation, sync on return

52

IBM Software Group


z/OS Availability – CICS Bridge with WMQ V5.3

Bridge monitor

DPL Prog

Tran B

Tran A

CICSA

Each instance of the Bridge must have exclusive access to the Bridge Queue.

Also the form of the EXEC CICS START does NOT allow transaction routing so TRAN A and TRAN B can only run in the CICSA region.

53

IBM Software Group


z/OS Availability – V6 CICS Bridge Monitor enhancements

¡ Multiple bridge monitors for single queue

¡ Transaction Routing

¡ Tolerate & return additional headers (e.g. RFH2)

¡ Honour Backout threshold and requeue queue name

¡ Error messages to CICS joblog option

¡ Optional reply to queue

¡ Enhanced passticket support

¡ Honour MQRO_DISCARD_MSG and MQRO_PASS_DISCARD_AND_EXPIRY

54

IBM Software Group


z/OS Availability – CICS Bridge with WMQ V6.0

CICSA CICSX

Bridge monitor

DPL Prog

Tran B

Tran A

DPL Prog

Tran B

Tran A

Bridge monitor DPL Prog

Tran B

Tran A

DPL Prog

Tran B

Tran A

CICSB CICSY

Using the multiple bridge monitor and routing support allows the equivalent of the TOR - AOR set up.

Multiple Bridge Owning Regions (BORs) can take messages from a shared queue and feed work to a number of AORs thereby providing scalability and eliminating single points of failure.

55

IBM Software Group


z/OS Availability – SUSPEND/RESUME IMS Bridge

¡ The problem� how to quiesce IMS bridge with a shared request queue � MQPUT inhibit of request queue stops all bridge instances � STOP QMGR leaves replies trapped in IMS or in bridge

¡ The solution � SUSPEND QMGR BRIDGE(IMS)� stops MQGETs by bridge for all bridge queues � allows MQPUT by bridge of replies from IMS

� RESUME QMGR BRIDGE(IMS)� starts MQGETs by bridge for all active bridge queues

¡ Scenario to quiesce QMGR � issue SUSPEND QMGR BRIDGE(IMS)� wait until replies complete � no relevant IMS transactions running � MQ XMIT queues to remote QMGRs empty � issue STOP QMGR MODE(QUIESCE)

56

IBM Software Group


Improved Availability for Distributed Platforms

¡ Log file information provided to permit Disaster Recovery solutions to be built

¡ Queue manager reports on required, in-use, no-longer-needed log files� When you are using linear logging

¡ Command to force advance of log to new log file� Can now get a consistent copy or backup of log files at a specific time

¡ Ability to replay log files on a DR site, on a “backup” queue manager before any disaster requires it to be done� Reduces time needed for restart in a live situation

¡ Also increased the amount of active log space that can be configured

57

IBM Software Group


§There are a number of requirements that have been raised related to the management of WMQ log files. In particular we want to make it easier to design recovery solutions, especially for disaster recovery.

§So reports can be generated giving information about which logs are needed. This has always been available from other routes (responses to commands, entered in an error log) but now the information can be "pushed" from the queue manager to a management tool. A new command will force the log to advance to a new extent; this will allow you to then copy all earlier logfiles to a backup (disaster recovery) location, knowing the state of the qmgr at that point.

§A disaster recovery site can be prepared, as a replica of the original location, dynamically replaying the logfiles as they become available from the main site, but without fully starting the queue manager. That means that if a full restart is needed, only "recent" logfiles need be replayed.

§There has also been a requirement to permit larger and/or more logfiles – in this release, the active log size increases from 4GB to 128GB on Unix, 64GB on Windows

Improved Availability for Distributed Platforms

N

O

T

E

S

58

IBM Software Group


Improved monitoring

¡ New application status command � DISPLAY CONN

¡ Additional channel information � DISPLAY CHSTATUS

¡ Additional queue information � DISPLAY CHSTATUS

¡ Filtering on DISPLAY commands� WHERE keyword

59

IBM Software Group


DIS CONN(*) ALLAMQ8276: Display Connection details.CONN(3CF17F4020000E01)

TYPE(CONN) PID(3248) TID(1)APPLTAG(AMQAPI.EXE) APPLTYPE(WINDOWSNT)CHANNEL() CONNAME()CONNOPTS(MQCNO_STANDARD_BINDING)USERID(metaylor)UOWLOG() UOWSTDA(2004-04-16)UOWSTTI(15.56.15) UOWLOGDA(2004-04-16)UOWLOGTI(15.58.19) URTYPE(QMGR)QMURID(0.7)

Improved Monitoring – who is using the queue manager

¡ Already have DISPLAY QSTATUS to show who is using a queue

¡ New command DISPLAY CONN to show who is connected and which queues they have opened

¡ New command STOP CONN to force a disconnect (not on z/OS)

¡ Also shows UOW timestamps

60

IBM Software Group


DISPLAY QSTATUS(TESTQ)AMQ8450: Display queue status detailsQUEUE(TESTQ) IPPROCS(1) OPPROCS(1)CURDEPTH(24) UNCOM(NO)LPUTDATE(2004-04-16) LPUTTIME(18:09:16)MSGAGE(323) QTIME(1340,4540)MEDIALOG(S0000001.LOG)

Improved Monitoring – Additional status information

¡ Problem determination (and problem avoidance) indicators� Show "instantaneous" information about activity

¡ DISPLAY CHSTATUS� Cluster transmission queue sub depth and “average” throughput times� “Average” batch size� "Substate" - sending data on wire, waiting for nameserver response, in an exit� Response time from remote end

¡ DISPLAY QSTATUS� “Average” time messages lived on queue (short & long-term indicators)� Last GET/PUT times� Oldest message still on queue

61

IBM Software Group


Improved Monitoring – CHSTATUS additions¡ Adds new fields to the STATUS display for Channels

¡ SUBSTATE - Low level view of operation of channel (Name server / receive / User-exit / ...)

¡ NETTIME - The “average” time taken for a request to be sent to the remote end of the channel and a response received (short/long term indicators)

¡ EXITTIME - The “average” time spent in user exits per message (short/long term indicators)

¡ XQMSGA - The number of messages queued on the transmission queue available to the channel for MQGET.

¡ XQTIME - The “average” time messages remain on transmission queue before being sent (short/long term indicators)

¡ XBATCHSZ - The “average” size of batch sent down the channel (short/long term indicators)

¡ These fields are only displayed when Online Monitoring is being collected for that Channel. Fields may be requested individually or the MONITOR keyword will show all monitoring values

62

IBM Software Group


Improved Monitoring – QSTATUS additions

¡ Adds new fields to the QSTATUS display for local queues

¡ QTIME - contains the “average” time a message remains on the queue before being destructively read by an MQGET (short-term & long-term indicators)

¡ MSGAGE - the age in seconds of the oldest message on the queue

¡ LPUTDATE/LPUTTIME - The last date/time a message was put to the queue

¡ LGETDATE/LGETTIME - The last date/time a message was read from the queue

¡ These fields are only displayed when Online Monitoring is being collected for that Queue. Fields may be requested individually or the MONITOR keyword will show all monitoring values:

63

IBM Software Group


Improved Monitoring – Configuration options¡ Online Monitoring data is controlled by Qmgr and Queue/Channel attributes

¡ At Qmgr level -� MONCHL (NONE | OFF | LOW | MEDIUM | HIGH)� MONQ (NONE | OFF | ON )

¡ At Channel level (on each channel)� MONCHL (QMGR | OFF | LOW | MEDIUM | HIGH)

¡ At Queue level (on each queue)� MONQ (QMGR | OFF | ON )

¡ Data collection rate can be controlled as follows -� LOW (1 in 64 messages)� MEDIUM (1 in 8 messages)� EVERY (each message)

¡ The default definition per object is 'QMGR' (inherit the Qmgr setting) � To switch on monitoring for all channels/queues set the appropriate data collection setting

in the Qmgr attribute� To override the Qmgr attribute, change the setting on the appropriate channel/queue

definition

64

IBM Software Group


§This new capability is available on both Distributed and z/OS queue managers. It extends the STATUS information for queues and channels.

§For queues, you can now see what is the oldest message on the queue. You can also see how fast, on average, messages are passing through the queue. If the averages are low, but the oldest message is very old, then that might indicate an application doing a get by msgid/correlid and that message is in some way badly formatted or doesn't have the correct identifier. If all messages are staying for a long time on the queue, then that might indicate the serving application is overloaded, or more servers are needed to process the input.

§Similar information is available for channels, where cluster channels can report on their associated transmission queue or subqueue. And there is more detailed state - not just RUNNING, RETRY etc - to show exactly what a channel is doing. For example, is it running a user exit at this point, or is it calling the TCP/IP nameserver.

§One important goal of this lineitem was to keep the (performance) cost of collecting the information cheap. Anything that involved scans through queues, for example, would normally not be acceptable. All of this data was already used internally in the queue manager or could be easily derived.

More status

N

O

T

E

S

65

IBM Software Group


Improved Monitoring - Display Filtering for Commands¡ PCF and MQSC commands extended with WHERE clause� All object types; any attribute

¡ Single attribute can be filtered using usual operators� GT, LT, EQ, NE, GE, LE, CT ["contains"], EX ["excludes"]� No AND, OR combinations

¡ Some common questions can be answered:� Show me the applications causing log files to fill by not committing transactions� Show me the queues with a message older than 5 minutes� Show me the queues not recently imaged for media recovery� Show me all the queues used by an application

¡ Easy to write scripts for these requests� Then could use response to take action

66

IBM Software Group


Improved Monitoring - Display Filtering examples¡ WMQ V5.3 abilities:

� queues with names starting ABC� all queues� channels of type RCVR� channel status� all open queues

¡ WMQ V6.0 abilities:� queues with names starting ABC and CURDEPTH > 20

� DIS QUEUE(ABC*) WHERE (CURDEPTH GT 20)

� all queues with GET(DISABLED)� DIS QUEUE(*) WHERE(GET EQ DISABLED)

� channels of type RCVR with SCYEXIT non-blank� DIS CHANNEL(*) TYPE(RCVR) WHERE(SCYEXIT NE ' ')

� channel status for connections to qmgrs starting DE� DIS CHSTATUS(*) WHERE(RQMNAME EQ DE*)

� all open queues with 'input exclusive' access � DIS QSTATUS(*) TYPE(HANDLE) WHERE(INPUT EQ EXCL)

67

IBM Software Group


Improved Monitoring – DISPLAY CONN and WHERE used together

¡ CSQJ160I - Long-running UOW found.URID=000A123456DC, CONNECTION NAME=CHINMSTR

¡ Tells us that we have a long-running channel that hasn't reached commit yet.

¡ How do we find out more ?

¡ DISPLAY CONN WHERE (QMURID EQ 000A123456DC)

68

IBM Software Group


§MQSC commands can have a simple WHERE clause added, to restrict the amount of data returned from a DISPLAY command. Only a single attribute can be added, but that is often sufficient for problem determination or status enquiries. There is no AND/OR combination permitted.

§The same queries can also be used in PCF commands, which of course are now also available on z/OS.

§The FILTER option in the GUI, that we saw earlier, is implemented by passing it through to the command server.

§Filtering in the queue manager is an efficient use of resources, instead of all management tools doing their own filtering, with each response coming back in a message. This reduces the number of messages flowing for system management.

§It would be easy to write scripts that issue these commands, which might reflect “typical” problems in a customer environment, and then use the responses to drive some action like forcing an application to disconnect from queue manager; restarting a server application; or generating an alert to network operations

Display Filtering for Commands

N

O

T

E

SDISPLAY QLOCAL(SYS*) WHERE(PUT EQ ENABLED) CURDEPTH DESCR

AMQ8409: Display Queue detailsDESCR(WebSphere MQ Queue Manager Related Event Queue)QUEUE(SYSTEM.ADMIN.QMGR.EVENT) CURDEPTH(1)

AMQ8409: Display Queue detailsDESCR(WebSphere MQ Queue Manager Authority Data Queue)QUEUE(SYSTEM.AUTH.DATA.QUEUE) CURDEPTH(34)

69

IBM Software Group


Improved flexibility for WMQ Clusters

¡ New options make large clusters easier to handle� Based on real customer scenarios

¡ Can create backup networks that are automatically used when all prime servers are unavailable

¡ Can restrict the number of servers accessed by a “small” client

¡ Can override the "always select local queue if it exists" rule

¡ Can ask for more work to be sent to more powerful servers

¡ No automatic feedback from servers; attributes could be adjusted by system monitors

70

IBM Software Group


§Lots more options to control the workload balancing feature of WMQ Clusters.

§All of these options have been derived from customer experiences and requests, some of whom have been building very large clusters.

§There is no automatic dynamic modification of the weighting - eg we do not inspect machines to see how "busy" they are - but this could be added by custom code. One reason for this is that it is very difficult to define "busy" for a general audience.

§New attributes for queues, queue manager and cluster channels

§Greater flexibility in prioritising and weighting the "round-robin" choice made for distributing messages

§Default behaviour is unchanged

§Easier to create "Backup/standby" networks where the queue managers are only used when all "normal" queue managers are unavailable

§Easier to restrict number of active outbound channels

§Easier to weight so that bigger boxes get sent more work

Improved flexibility for WMQ Clusters

N

O

T

E

S

71

IBM Software Group


N=0N=1

New Cluster Options¡ Weighting & priorities

¡ Include local instance

ClusQ

QM

ClusQ

QM1

ClusQ

QM2

ClusQ

QM3

ClusQ

QM4

PRI=2WT=2

PRI=2WT=1

PRI=1WT=2

PRI=1WT=1

N=0

N=0

N=0N=1N=2N=3N=4

N=2

Site1

Site2

72

IBM Software Group


N=0

N=2

N=1

New Cluster Options¡ Weighting & priorities

¡ Include local instance

ClusQ

QM

ClusQ

QM1

ClusQ

QM2

ClusQ

QM3

ClusQ

QM4

PRI=2WT=2

PRI=2WT=1

PRI=1WT=2

PRI=1WT=1

N=0

N=4

N=1N=2N=3N=4

N=2

Site1

Site2

73

IBM Software Group


System Statistics

¡ Statistics are useful for checking what applications and the queue managers are doing. They could be used for charge-back or capacity planning.

¡ This release puts SMF-style information in the hands of Distributed administrators, as it is now reported via PCF Event Messages

QueueManager: klein

IntervalEndDate: 2004-08-10

IntervalEndTime: 14:39:50

CommandLevel: 600

SeqNumber: 0

ApplName: amqsput.exe

ApplicationPid: 9408

ApplicationTid: 1

UserId: 'metaylor'

ObjectCount: 1

OBJECTS:

QueueName: ‘APP.QUEUE.X'

QueueType: Predefined

QueueDefType: Local

OpenCount: 1

OpenDate: 2004-08-10

OpenTime: 14:39:49

CloseCount: 1

CloseDate: 2004-08-10

CloseTime: 14:39:50

PutCount: [0, 1]*

PutFailCount: 0

Put1Count: [0, 0]

Put1FailCount: 0

PutBytes: [0, 4]

PutMinBytes: [0, 4]

PutMaxBytes: [0, 4]

*array shows non-persistent, persistent

74

IBM Software Group


§In this release, a lot more information is available in Event messages. The PCF language has been extended, not just for z/OS, but also to permit more complex capabilities. For example, there is the ability to group elements together as "substructures", This allows PCF messages to have arbitrary name/value contents. There is also a 64-bit integer datatype.

§These new structures are required to support several functions, including this one: the equivalent of SMF reports for activity within the queue manager and attached applications. Just like SMF reports, you will be able to see "statistics" which report about the qmgr, and "accounting" information which is generated for each application.

§Two new event queues are created by the queue manager (automatically during migration if necessary), and the event messages are put there.

§The information is similar to that generated for SMF; our experience on z/OS has been used to decide which precise elements have proved useful.

§The information is generated at configurable intervals, and at the end of an application (MQDISC). There is also an option on the RESET QMGR command that forces statistics to be emitted immediately.

§A sample program, amqsmon, can be used to format the event messages – it was that program that produced the output for this chart. Source code is included.

§Just as on z/OS, WMQ does nothing interesting with the data once it's been generated! It is assumed that anyone collecting this data will buy or write a tool that collects the event messages and processes them somehow.

System Statistics

N

O

T

E

S

75

IBM Software Group


Network Configuration Checker - Traceroute for WMQ

¡ Reports generated showing message flowing

¡ Transmission queues, channel names, final queue

¡ Timestamps

¡ Could be used to validate cluster workload distributions

XMITQ

QM1

RemQ

RplyQ

XMITQ

QM2

RemQ

RplyQ

LoclQ

QM3 RplyQ

Put to REMQ, which is XMITQ on QM1

Taken from XMITQ, put toRemQ on QM2 which is

XMITQ on QM2

Taken from XMITQ, put toLoclQ on QM3

76

IBM Software Group


§This function allows a WMQ network to be debugged.

§It does NOT answer the question of finding an existing message that has already been sent. However it does allow you to find where the message MIGHT have gone. A "tracer" message is injected into the network, being put to a queue, and it can then report back all of the channels and transmission queues through which it passes before reaching its final destination, where it may be automatically discarded.

§The generation of reports is controlled by flags in the MQMD. In theory any application could turn on these flags, and you could get reports of every message flowing around the network, but that would clearly overload the system. This should be used mainly to verify a configuration.

§A command (dspmqrte) is provided on the Distributed platforms that will generate messages, with many options for the dispositionof the reports - collation at the far end, independent reports generated at each hop, etc. As dspmqrte can connect as a client, it can be used to debug flows that start from a z/OS queue manager.

§The format of the messages, and how reports are added or generated, are documented. One potential use is for applications to add their own "activity" information to messages that they process. The architecture is designed to permit this.

Network Configuration Checker - Traceroute for WMQ

N

O

T

E

S

77

IBM Software Group


Typical OutputActivity:ApplName: 'es\MQSeries\bin\dspmqrte.EXE'ApplType: WindowsNTActivityDesc: 'WebSphere MQ Display Route App'

Operation:OperationType: PutOperationDate: '20040907'OperationTime: '12431483'QMgrName: 'QMA'QName: 'RQMC' ResolvedQName: 'QMB'RemoteQName: 'RQMC'RemoteQMgrName: 'QMB'

TraceRoute:RecordedActivities: 1UnrecordedActivities: 0DiscontinuityCount: 0MaxActivities: UnlimitedRouteAccumulation: NoneRouteForwarding: IfSupportedRouteDelivery: No

Activity:ApplName: 'es\MQSeries\bin\AMQRMPPA.EXE'ApplType: WindowsNTActivityDesc: 'Receiving Message Channel Agent'

Operation:OperationType: ReceiveOperationDate: '20040907'OperationTime: '12431483'

QMgrName: 'QMC 'RemoteQMgrName: 'QMB 'ChannelName: 'TO.QMC'ChannelType: Receiver

--------------------------------------------------Operation:

OperationType: DiscardOperationDate: '20040907'OperationTime: '12431483'

QMgrName: 'QMC 'QName: 'QMC 'Feedback: NotDelivered

TraceRoute:RecordedActivities: 5UnrecordedActivities: 0

78

IBM Software Group


§A selection from the dspmqrte command to show the kind of output produced. You can see the start of the report generated by a real setup like the picture on the previous chart. You can see the message is put to remote queue RQMC on QMA, which resolves to a transmission queue (QMB). Then there is the final stage, showing how the message is received by an MCA and discarded as it lands on the target queue.

§The full report has a lot more detail in it, including the MQMD of the messages being transferred. But this selection shows some of the key points.

Typical Output

N

O

T

E

S

79

IBM Software Group


Standards - JMS 1.1 and J2EE

¡ JMS 1.1 is required for current J2EE compliance

¡ Joins pub/sub and point-to-point methods into a single set of methods� Backwards-compatible� JMS applications can still use the older 1.02 APIs

¡ Shipped in V5.3 FP06 and in V6

¡ WMQ JMS is always supported inside WAS and now also for WebLogic� It is not the “embedded” provider for WAS6, but still (of course) can be used

¡ V5.3 FP08 and V6 also include MA0C Publish/Subscribe component� Making it easier to use full JMS function without downloading or buying extras

80

IBM Software Group


§WMQ V5.3 FP06 included an updated version of the JMS classes, to match the current version of the JMS standard. This is a required implementation for any app server that hopes to support the J2EE 1.4 standard, but it is also a useful thing to have in its own right.

§The big change from JMS 1.02 was to simplify the class structure, and unify the publish/subscribe and point-to-point operations. So now, instead of calling CreateQueueConnection, you can just CreateConnection. It allows a single transaction to span both pub/sub and point-to-point operations, provided both are going via the same session (in WMQ terms, via the same hConn), without needing a two-phase commit coordinator.

§Existing JMS programs continue to work unchanged as the older APIs are maintained.

§WAS6 introduces a new embedded messaging provider, WebSphere Pla tform Messaging, which replaces the crippled version of WMQ V5.3 which was part of WAS5. This new provider (unlike the o ld one) can be used to connect into an external WMQ network. Or you can still use WMQ JMS as an alternative provider directly.

§WAS is not the only application server that is officially supported by WMQ. WebLogic has also been tested on some platforms and is supported.

§The MA0C Publish/Subscribe SupportPac is now part of the base product. This makes is easier for people to obtain the code, especially as the 64-bit changes in V6 would have required another refresh of the SupportPac.

Standards - JMS 1.1 and J2EE

N

O

T

E

S

81

IBM Software Group


Standards – Web Services over WMQ

¡ WMQ V6 ships an updated and integrated version of MA0R SupportPac

¡ Transport SOAP messages over a reliable transport instead of http

¡ Sender and listener support for� Axis host Web Services environment� .NET host Web Services environment

¡ Client and server SOAP layers may be heterogeneous� eg .NET client to Java server� If they interoperate using HTTP, they will

interoperate using WMQ� Also planned to work with WAS

SOAP/JMS and CICS SOAP/MQ

¡ Scripts for deployment assistance

clientapp

SOAPlayer

HTTP

WMQsender

transportWMQ

listener

SOAPlayer

HTTPserver

targetobject

HTTP

WMQ

SOAPenabled

client

SOAPdeployedservice

user

SOAP

WMQ

key to provider:

82

IBM Software Group


Standards – Web Services over WMQ

¡ Service code unchanged� Now hosted by WMQ listener� May run in a transaction

¡ Simple client code (almost) unchanged� Client or proxy needs to include ‘wmq:’ prefix location� Usually embedded in proxy by deployment tooling� SOAP layer switches based on this prefix� Can use WebSphere Studio AD, Visual Studio .NET, etc to generate� Can also position Web Services for future asynchronous support� No formal standard yet

¡ WSDL� As for SOAP/HTTP� With target uri of form ‘wmq:queueName…’� Options control other WMQ details such as queue manager, persistence etc

83

IBM Software Group


Standards - IPv6

¡ The new version of the TCP/IP protocol

¡ IPv6 expected to get more important during the lifetime of this release� Allows many more addresses

¡ Extensions to WMQ attributes & parameters to allow IPv6 addresses� eg instead of 9.20.3.4 you can have fe80:43e4:0204:acff:fe97:2c34:fde0:3485� 32 bits extended to 128 bits

¡ IPADDR determines which stack(s) to listen to

¡ CONNAME and LOCLADDR determines which stack to send on

¡ Clusters will work with IPv6 stacks

84

IBM Software Group


§Not much more to say about this! There's very little external change needed to WMQ itself; the main thing needed is to ensure the operating system is correctly configured, especially with dual stacks (IPv4 and IPv6). A new qmgr attribute names which stack touse in preference, where both are available.

§Note that Windows 2000 does not support an IPv6 stack, so if you are running Windows, you must be using Windows XP SP1 or Windows 2003 for IPv6.

Standards - IPv6

N

O

T

E

S

85

IBM Software Group


SSL Enhancements

¡ Dynamically refresh any cached repository and LDAP server data� Location of CRLs� Updated certificates� No need to restart CHIN

¡ On Windows, SSL implementation now uses same toolkit as Unix platforms� Gives a common model� V5.3 configurations are migrated to gskit repositories

¡ FIPS-140 certification� The cryptographic modules in gskit have FIPS certification� WMQ can be configured to only permit those certified algorithms

¡ Certificate Authority’s Distinguished Name available in chstatus, security exits� Shows who authorised the user’s certificate� Allows you to distinguish between the same “user” validated by different authorities

86

IBM Software Group


§A few changes to SSL processing

§The main one is the migration on Windows to use the gskit toolkit instead of Microsoft’s SSL provider. This gives a number of advantages, including common administrative models across multiple platforms. A tool is provided to take certificates out of the Microsoft stores and populate an equivalent gskit repository.

§The REFRESH command is provided so that the channel programs do not need to be restarted when there are changes to the certificate chains, for example to replace an expired certificate. The modified store is automatiaclly reread next time a channel starts. This also refreshes any cached LDAP server connection information used to access CRLs. The CRLs themselves are not cached, just the locations of the servers which hold the CRLs.

SSL Enhancements

N

O

T

E

S

87

IBM Software Group


Scalability and Performance

¡ On AIX, HP-UX, Solaris, Linux/pSeries, WMQ is now a 64-bit product� Supports existing 32-bit applications� Two sets of MQI libraries provided, for 32-bit and 64-bit development� Most exits (eg channel) will need to be provided in both “sizes”

¡ Some customers wanted to use 64-bit memory for their applications� No real performance difference for applications unless apps are redesigned

¡ The benefit mostly seen inside the queue manager� Much like database engines

¡ It permits WMQ to handle more data (messages, queues) concurrently� New internal design to improve performance of operations such as get-by-correlid� These structures take memory which was too scarce on 32-bit systems

88

IBM Software Group


WMQ V6 Performance

¡ Enhanced persistent message throughput� Higher throughput across client scaling� AIX and Linux (X & Z) better by over 20%� Analysed and redesigned high usage locks

¡ High performing non-persistent messages� Performance held despite additional function

¡ Growth in virtual memory (swap file) due to 64-bit and function

89

IBM Software Group


WMQ AIX(p690) 2K byte Persistent Messsages

0500

1000150020002500300035004000

4 16 28 40 52 64 76 88 100

112

Number of Clients

Rou

nd tr

ips

per

seco

nd

V6 V5.3

Example of improved performance

90

IBM Software Group


§In this release we support only 64-bit systems for AIX, HP-UX (PA-RISC), Solaris and Linux/pSeries. This is because we can get a lot of constraint relief inside the queue manager, by exploiting the 64-bit memory address range. Most Unix machines shipped for several years have been capable of running 64-bit programs. There are some internal changes to the queue manager, such as better indexing on correlids, that we can now do with the expanded memory.

§Existing applications continue to run unchanged, as we will provide 32-bit versions of libmqm. However some "system-level" components such as exits - anything that might run inside a 64-bit process - will need to be recompiled. This will include API Exits, channel exits and Data Conversion exits. Channel programs, like the rest of the queue manager, will be 64-bit processes.

§New applications can choose to either use the 32-bit or 64-bit bindings to the queue manager. The choice is likely to be determined by factors outside WMQ's scope; it is unlikely to affect WMQ performance whichever choice is made. In most cases there is no immediate performance benefit available just from recompiling code; redesigns are normally necessary to take advantage of the large memory.

Scalability and Performance

N

O

T

E

S

91

IBM Software Group


Channel Compression

¡ All platforms now include optional channel compression� Particularly useful with some types of data - text, XML� Makes best use of network bandwidth� Should give better performance for encrypted (SSL) channels

¡ Channel compression allows V6 queue managers and clients to communicate using compressed data on a per channel basis

¡ Header data compression and/or message data compression can be selected

¡ Message data is compressed using either RLE or ZLIB compression� Options for ZLIB to prefer faster or better compression

92

IBM Software Group


Channel Compression

N

O

T

E

S

170082%ZLIBHIGH

130081%ZLIBFAST

22055%RLE

CompTimeCompRate

¡Compression on channels has a selection of algorithms, to allow trade-offs between the CPU cost of compression, and the benefit of sending fewer bytes on the network. The algorithms have been chosen to deal well with text and XML messages. The CPU cost of compression ought to be paid back if you are also using encryption on SSL channels. This will work on both qmgr channels and client connections. When channel monitoring is enabled, information about compression percentages and time taken is shown in channel status outputs.

¡Note that compression will alter the data passed to send and receive exits, but not message exits

¡SDR - RCVR channel with COMPHDR(SYSTEM)� Header length reduced from 476 bytes to 66 bytes (86 %)

¡CLNTCONN - SVRCONN channel with COMPHDR(SYSTEM) - MQPUT� Header length reduced from 500 bytes to 89 bytes (82 %)

¡Message Compression� Message Compression rates are dependent on the form of the data� Example below of blank padded text strings (2590 bytes)

93

IBM Software Group


Migration – Functions removed from V5.3

¡ 32-bit hw for AIX, Solaris & HP-UX� 32-bit applications support remains

¡ DCE� ("*_d") libraries on HP-UX� DCE security and nameservice exits

¡ Support for Windows NT

¡ AMI on z/OS à Cat3 SupportPac

¡ CICS Mover

¡ MMC snap-ins on Windows

¡ Windows Services for auto-start

¡ UDP transport protocol on AIX

¡ Move to 64 bit operating system

¡ Apps which use these need relinking

� Use SSL for security

¡ Migrate to a later Windows platform

¡ Consistent with other platforms

¡ Use CHIN

¡ Use the new Eclipse plug in

¡ Use new WMQ service objects

¡ Use TCP/IP

94

IBM Software Group


§These functions have been removed from this release, and the right-hand side shows suggested replacement if any

Migration

N

O

T

E

S

95

IBM Software Group


Miscellaneous – z/OS

¡ Audit trail for MQSC/PCF commands� Complements existing Configuration Events

¡ Log Shunt� Makes it quicker to resolve long-running UOWs

¡ Improved granularity for Passticket security validation� Can specify Passticket name on STGCLASS definition

¡ Addition of channel Message Retry parameters to match Distributed platforms

96

IBM Software Group


Miscellaneous – Distributed platforms

¡ Security � Admin commands (setmqaut etc) get PCF equivalents

� OAM-based security for channel operations

� New exit point to allow local authentication

¡ Optional filtering of some error log entries

¡ .Net trigger monitor

¡ Pub/Sub Broker (nee MA0C) included on all Distributed platforms

¡ JMS and Java classes to work with client channel table

¡ JMS and Java classes to support channel exits written in C

97

IBM Software Group


§The auth commands on Distributed platforms can now be issued remotely, via PCF commands. This will permit a central admin tool to manage the ACLs.

§An extension to the OAM interface will also allow custom-written modules to modify which userid is used for local bindingapplications. MQCONNX has been extended to have userid/password fields; these are passed to the OAM. Note that the OAM shipped with WMQ does not do any authentication. But there should be an example to show how it could easily be added (and the chaining facilities of the OAM would allow an authentication-only module to be written, while keeping the standard OAM for everything else).

§Error log filtering makes it easier to see significant events in the error log: when multiple similar events happen, they will be replaced by a single message saying something like "previous message repeated 10 times in 30 seconds". In particular some of the channel start/stop messages are filtered; very useful when restarting a queue manager after a system failure, and hundreds of channels simultaneously try to reconnect. Some messages can be suppressed entirely.

§A new object type, "SERVICE", makes it possible for all the Distributed platforms to automatically start programs along with the queue manager. This replaces the Custom Services capability that was only part of the Windows MMC GUI. There is no need for this function on z/OS which has a suitable mechanism in the operating system.

§Channels on Distributed platforms can now have security controls applied to them, so some people can start/stop channels but not modify the definitions.

§Updates to the Java classes make it easier for an administrator to set up definitions regardless of the client that is being used. No longer will you have to know that a client program is written in Java.

§The MA0C pubsub broker that was included in FP08 for V5.3 is also shipped with V6. This means you won’t need to download a new copy of the code that would have been required fo r V6 64-bit platforms.

Miscellaneous – Distributed platforms

N

O

T

E

S

98

IBM Software Group


Summary

¡ A major enhancement to our core messaging technology

¡ Builds on the well-established principles needed for enterprise solutions

¡ Many customer requirements included

99

IBM Software Group


§This presentation has covered less than half of the lineitems from the list of about 200 that are being implemented for WMQ V6. I picked the items which seemed to have most importance. (Some of the unmentioned items are "business as usual" or prereqs for the larger items mentioned here, but there is other real function.)

Summary

N

O

T

E

S

s57

Documents