Skip to Main Content
IBM Z Software


This portal is to open public enhancement requests against IBM Z Software products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Not under consideration
Categories Open Access TM
Created by Guest
Created on Apr 26, 2021

support for multiple MQ systems in OTMA destination descriptor TYPE=MQSERIES

For high availabity reasons we have configured 2 production lines in the same sysplex:
CEC01-LPAR01-IMS01-MQ01
CEC02-LPAR02-IMS02-MQ02
Both lines are coupled by various product features.
I1) IMS01 and IMS02 use the same IMS shared message queue
I2) IMS01 and IMS02 run with the same OTMA XCF group, GRNAME=OTMAIM12
I3) IMS01 and IMS02 have the same OTMA destination descriptor MQDES0A in DFSYDT0x
IMS01 : MQDES0A … MQRTQMGR=MQ01 MQRTQ=KTW TPIPE=MQDES0A
IMS02 : MQDES0A … MQRTQMGR=MQ02 MQRTQ=KTW TPIPE=MQDES0A
M1) MQ01 and MQ02 are member of the same MQ queue sharing group MQSG
M2) Each MQ has 2 MQ IMS Bridges , one for each IMS
MQ01
DEFINE STGCLASS(STGCIM01) XCFGNAME(OTMAIM12) XCFMNAME(IM01)
DEFINE STGCLASS(STGCIM02) XCFGNAME(OTMAIM12) XCFMNAME(IM02)
MQ02
DEFINE STGCLASS(STGCIM01) XCFGNAME(OTMAIM12) XCFMNAME(IM01)
DEFINE STGCLASS(STGCIM02) XCFGNAME(OTMAIM12) XCFMNAME(IM02)
.
p.67 of https://share.confex.com/share/123/webprogram/Handout/Session16096/Nathan_Handout.pdf
describes to some extent ( read callout message instead of reply message) processing for ‚asynchronous IMS callout to MQ on the base of OTMA destination descriptor TYPE=MQSERIES‘ .
In case of planned and unplanned MQ downtimes processing is stuck between step 11 and 12 of p.67.
We currently have to surround the MQ downtime in our automation package by
• /PST TRAN X Y Z and
• /STA TRAN X Y Z
for the descriptor MQDES0A exploiting (CHNG/ISRT call to ALTPCB) transactions X,Y and Z in order to avoid
• Elongated application response times
• IMS monitoring alarms due to deviation of normal state , IMS queue empty‘

We would appreciate to have support in DFSYDT0x and IMS for either
• a list of MQ systems in the OTMA destination descriptor, i.e. MQDES0A … MQRTQMGR=(MQ01,MQ02) or
• a MQ queue sharing group MQSG in the OTMA destination descriptor, i.e. MQDES0A … MQRTQMGR=MQSG
This way IMS could send via XCF to ANY active MQ-Member (if one is down take another one) in the OTMA XCF group (step 12 p.67 in above cited presentation) .

Idea priority Medium
  • Guest
    Reply
    |
    Nov 25, 2022

    Can see this has been rejected, just wanted to add we are also very interested in this, and have had to write a DRU exit to try and achieve some level or resilience This isnt ideal, and should really be a feature of IMS, its handled in IMS connect with super members, it feels like MQ should be treated the same

  • Guest
    Reply
    |
    May 5, 2021

    Hi,

    Thank you for your interest in keeping IMS a vital and successful product. Software development has continuously evolved during IMS’s lifetime, and so has IMS itself. We have kept pace with, adopted, and implemented many industry standard best practices within our organization, including Continuous Delivery, Design Thinking, and Agile.

    When choosing new features to add from the list of requirements in our backlog, we assess which will bring the most value to as many clients as possible and prioritize those.

    At this time, after reviewing this request for enhancement and assessing its potential value, we have decided to reject it. The reason we are rejecting this RFE is the following: We are certainly evaluating this item as part of our scalability futures roadmap, however, we don’t feel we can deliver it within the next 18-24 months which is the goal we have set for RFE deliverables as part of our IMS Gold program. You are welcome to resubmit this RFE at a later date and we will reconsider.

    We appreciate your input to IMS, and we hope that you will continue to submit ideas for improvements as customer feedback is a key component to shaping the future direction of IMS.

    Thank you.