Scope: Plano, Auburn Hills, Charlotte, Sacramento and Tulsa Complexes
Effective Date: Immediately
Group Name: U.S. Leveraged Software Capability IMS/MQSeries
Affected Locations: Plano, Auburn Hills, Sacramento, Charlotte and Tulsa Processing Centers
Summary: Notify z/OS sites of the planned upgrade to Websphere MQSeries V7.0.1 that will require user involvement and post implementation testing to validate impact of the upgrade.
Justification: To maintain current software levels.
Currently, most HP locations are running Websphere MQ V6.0.0 for z/OS. This user communication provides planning information for sites in preparation for the 2011 rollout of WebSphere MQ V7.0.1 for z/OS. Actual upgrade dates will be determined with each account using normal change management processes. Upgrades will be performed in an accounts test Websphere MQ subsystem prior to production to allow for application testing. We expect to complete these upgrades by the end of 3Q2011.
WebSphere MQ V7.0.1 is the most current release available from IBM
WebSphere MQ V7.0.1 introduces new enhancements over 6.0.0, and also includes fixes for known problems.
Benefits to Users:
WebSphere MQ V7.0 (5655-R36) delivers:
Enhanced ease of use for publish and subscribe and Java Message Service (JMS) messaging.
Graphical configuration of publish and subscribe and JMS through the Eclipse-based MQ Explorer for improved usability.
Enhanced publish and subscribe performance, increasing throughput by up to 20%.
Enhanced JMS performance, increasing selector rates by up to 250% and message listener throughput by up to 45%.
Support for IMS applications to use the WebSphere MQ message property APIs so that IMS applications can communicate with JMS applications.
Extended calls and behaviors for the MQI programming interface, improving developer productivity.
Enhanced WebSphere MQ clients, increasing non-persistent throughput by up to 300% and increasing failure detection and availability.
Web 2.0 support to help create a richer user experience by bridging HTTP applications with Asynchronous JavaScript and XML (AJAX) and Representational State Transfer (REST) to the MQ messaging backbone.
New Log compression feature to help increase performance and log bandwith. Log compression reduces the size of message logs that are produced by persistent messages.
MQ Explorer, available via download, can be used to remotely configure MQ for z/OS. MQ Explorer support pac (MS0T) is available.
Integrated accounting and statistics data formatter. This allows you to print the accounting and statistics data within SMF records produced by MQ. Previously available via the MP1B supportpac.
Enhanced SSL security support via new alternative approaches to certificate management.
New RACF classes to allow profiles to be defined to protect mixed case object names.
MQ V7.0.1 uses 64-bit storage for storing:
- Locks used in transactions (units of recovery).
- Indexes created to access messages within queues.
- Caches of userid security authorizations to queue managers.
Select on Get capability to specify a message selection criteria at the time the MQOPEN (for input) is issued.
CPU costs and throughput are not significantly different in version 7.0.1 for typical messaging workloads.
The option for batch and USS applications to use z/OS XPLINK, which is a high performance calling interface available for C applications. It uses dynamic link libraries (DLLs).
The option for automatic client reconnection after a queue manager or network failure. It allows the client application to continue processing without having to issue an MQCONN or MQCONNX MQI call to reconnect to the queue manager.
Support for message selectors on MQOPEN using the SelectionString field in the MQOD structure. This allows for point-to-point selectors and removes the need to use PROVIDERVERSION=6.
The new OPMODE property to control new functionality and backward migration.
The option for automatic client reconnection after a queue manager or network failure.
The CSQUMGMB utility to migrate the publish/subscribe configuration data from WebSphere Event Broker
Details:
Migrating client-connection and server-connection channels
This topic describes issues relating to migrating client-connection or server-connection channels to WebSphere® MQ Version 7.0.
The default for client channels is to use sharing conversations. On client channels only that use sharing conversations, heartbeats can flow across the channel (from both ends) at any time, depending on channel activity and the heartbeat interval. On versions of WebSphere MQ earlier than Version 7.0, or on WebSphere MQ Version 7.0 channel instances which are configured to not allow sharing conversations, heartbeats can flow on client channels only when an MQGET call is outstanding. This can affect whether you set heartbeating on client channels and what value you set it to. The default value on a migrated client-connection or server-connection channel for the SHARECNV channel attribute is 10, and the default WebSphere MQ V7.0 sharing MQCNO value for an existing client application is MQCNO_ALL_CONVS_SHARE. Conversations are, therefore, shared on TCP/IP channel instances by default when you migrate to WebSphere MQ Version 7.0. This is not apparent, unless you have send, receive, or security exits written to perform actions that are not generally expected in send, receive or security exits. In particular:
- If send or receive exits alter the MQCD structure on an MQXR_INIT call, the effect of these exits will differ, depending on whether they are on the first, or subsequent conversations on a channel
instance with sharing conversations:
- If the MQCXP SharingConversations field is set to FALSE, this exit instance applies to the first conversation on the channel instance. No other exit can be changing the MQCD at the same time and
changes that are made to the MQCD can affect the way that the channel runs.
- If the MQCXP SharingConversations field is set to TRUE, this exit instance applies to a conversation that is sharing the channel instance with other conversations. Changes made to the MQCD in the
exit instance are retained in the MQCD but cannot affect the way the channel runs.
- If send, receive, or security exit instances alter the MQCD, when the MQCXP SharingConversations field is set to TRUE, exit instances on other conversations can be changing the MQCD at the same
time and updates can be overwritten; this does not affect the way the channel runs, but if you use the data in the MQCD for a different purpose that requires the integrity of the data to be preserved,
then it might be necessary to serialize access to the MQCD across these different exit instances.
- For further information on the MQCXP SharingConversations field, see Using sharing conversations.
- If send or receive exits on the server-connection side of the channel instance need to perform MQI calls on the connection with which they are associated, they use the connection handle provided in the
MQCXP Hconn field. You must be aware that client-connection send and receive exits cannot make MQI calls.
- Performance implications of sharing conversations on client-connection channels. The SHARECNV channel attribute specifies the maximum number of conversations that share each TCP/IP channel
instance. Sharing conversations has performance implications when migrating client-connection channels to WebSphere MQ Version 7.0.
Application Stub Modules
Stub modules that are link-edited with applications and exits (CSQASTUB, CSQBRSSI, CSQBRSTB, CSQBSTUB, CSQCSTUB, CSQQSTUB, and CSQXSTUB) might not work with earlier versions of the queue manager. For example, stubs supplied with Version 6 can be used by applications running on a Version 6 or Version 7 queue manager, however an application linked with Version 7 stubs might not work with a Version 6 queue manager. To take advantage of the new APIs introduced at Websphere MQ Version 7, for example MQSUB and MQCB, you must link-edit your application with the appropriate Version 7 stub or, for an LE program, the sidedeck. Such an application will not run on an earlier version of the queue manager.
PL/I programs require that thlqual.SCSQPLIC be included in the their compilation. This dataset includes member CMQEPP which in Websphere MQ for z/OS v7 contains the definitions for the new API verbs. However, these new verbs are not supported in either
the IMS or CICS environments. This causes the link edit of the compiled program to issue message IEW2456E for each of the unsupported verbs when the program is designed for either environment and is thus linked to include the stub for that environment, CSQQSTUB for IMS and CSQCSTUB for CICS.
The solution is to specify the EXTRN(SHORT) option when compiling PL/I programs. With this option specified, EXTRNs are emitted only for those constants that are referenced.
This option needs to be specified as the default is EXTRN(FULL) meaning that EXTRNs are emitted for all declared external entry constants.
Coexistence of WebSphere MQ classes for JMS
Administered objects for WebSphere MQ Version 7.0 clients can read a WebSphere MQ Version 6.0 connection factory or destination object. An object written under WebSphere MQ Version 7.0 can be used by a WebSphere MQ Version 6.0 client, but any of the new WebSphere MQ Version 7.0 properties that have been set are ignored.
Multiple queue manager versions in a queue-sharing group
A queue-sharing group can have Version 6.0 and Version 7.0 queue managers active and accessing shared queues and other shared objects.
The Version 6.0 queue managers must have a Version 7.0 coexistence PTF applied to enable them to run in a queue-sharing group with Version 7.0 queue managers.
After the Version 7.0 coexistence PTF has been applied the Version 6.0 queue manager must be started at least one time to allow the migration of MQ internal objects.
A Version 7.0 queue manager cannot coexist in a queue-sharing group with other queue managers running code earlier than Version 6.0. If there is a Version 5.3.1 queue manager in the queue-sharing group, or the queue-sharing group migration actions have not been performed you cannot start a Version 7.0 queue manager as a member of that queue-sharing group. After you have performed queue-sharing group migration actions, or if there are Version 7.0 queue managers active in the queue-sharing group, you cannot start queue managers at Version 5.3.1 or lower in the queue-sharing group. Version 6.0 queue managers will not start in such a queue-sharing group unless they have had the Version 7.0 coexistence PTF applied.
You are recommended to only have a mixed version queue-sharing group for the time it takes to migrate all queue managers to Version 7.0. While the queue-sharing group contains mixed version queue managers, WebSphere® MQ for z/OS® Version 7.0 allows prototyping with new Version 7.0 facilities on a Version 7.0 queue manager, and tolerates operation at the Version 6.0 level or above.
Migrating a queue manager cluster:
Cluster queue managers can participate in clusters with other queue managers running at different versions. When you migrate a cluster, it is good practice to stage the migration. You can leave several days between migrating each queue manager in the cluster, to test applications before wholly committing all queue managers to run at the new version. It is advisable to migrate full repositories first. If all full repositories are migrated before partial repositories, all queue managers running at the new version can exploit features of the new version. Queue managers at the back-level version cannot take advantage of new features, and will appear in the repositories of new-version queue managers with the default values for any new attributes. If full repositories are not migrated before partial repositories, the cluster continues to work but not all new-version queue managers are able to take advantage of new features. This is because of the manner in which cluster objects are published to the cluster, via full repositories.
Operation and Control Panels
Panels at the V7.0 level work with V7.0 queue managers. They also work with some restrictions with V6.0 queue managers (Messages will warn you about restrictions).
With coexistence PTFs panels at the V6 level works as for V7.0 however warning messages will occur which can be ignored.
Client connectivity
If you do not have the Client Attachment Feature installed you can attach a max of 5 clients only by setting the MAXINST attribute on the server connection channel to a value between zero and five.
Page Set Usage with Small Messages:
As stated in SupportPac MP1G, to allow the scavenger to work more efficiently with small messages, each message is now stored in a separate 4K page. Prior to version 7.0.1, small messages were stored such that multiple messages could co-exist on the same page. The change will have a positive effect in most cases but could increase the size requirements for your page sets, depending on workload patterns. A tuning attribute, MAXSHORTMSGS, can be used under the direction of IBM Service to use the pre-7.0.1 function if necessary.
Websphere MQ Explorer
If you use the WebSphere MQ Explorer to administer your z/OS queue manager, you must perform the following actions after migration between releases:
1. Start the WebSphere MQ Explorer.
2. Right click the Queue Managers folder icon in the Navigator pane.
3. Remove the migrated z/OS queue manager from the list of managed queue managers using the Hide option within the Hide/Show Queue Managers function.
4. Add the migrated z/OS queue manager back into the list by using the Show option within the Hide/Show Queue Managers function.
Do this when migrating from Version 6 to Version 7 or when migrating back from Version 7 to Version 6. These actions ensure that the WebSphere MQ Explorer's cached view of the queue manager attributes, including the command level, are correctly refreshed after the migration
Admin structure recovery
At WebSphere MQ Version 7.0.1 and later, the first queue manager started can rebuild the admin structure partitions for other members of the queue sharing group as well as its own, and it is no longer necessary to restart each queue manager in the queue sharing group at this stage
Support dropped for the following items
The Application Messaging Interface (AMI) is no longer part of MQ. It is now available as the MA0F supportpac.
The CICS Mover is no longer supported.
The Internet Gateway is no longer supported.
Vendor Website (Public Internet):
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp
Primary Contact:
If you have questions about this information,
contact: Sonny Smith
phone: +1-856-451-1367
email: sonny.smith-iii@hp.com
|
Usercomm - Websphere MQSeries V7.0.1 Upgrade Information