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 Runtime
Created by Guest
Created on May 6, 2020

Global ENQ's Wait for a Cics Resource Dispatch Philosophy to be redesigned

To day when an Enqueue is wanted for a Resource between Cics Regions or LPARS, that is CEDA definition with ENQScope other than blank.
ENQScope : XXXX, and ends up enq GRS ENQS.

It can end up in, that one Cics Region can monopolize transactions having this ENQ, and not process other Cics Regions having similar ENQ'es

It could be of benefit, if dispatching philosophy could be redesigned to have a sort of FIFO dispatching, so ENQ'ed transactions would be dispatched
based on time suspend and waiting.

A PMR is made to IBM, number TS003203689

Idea priority Medium
  • Guest
    Reply
    |
    Jul 24, 2020

    Whilst this requirement is valid, based on our current plans and priorities, it is not likely that this could be implemented in the next 12-24 months, or in the next CICS TS release. Correspondingly this requirement is being declined at this point. The requirement will be kept in the RFE system and might be reassessed in the future. You also have an opportunity to resubmit in twelve months time if you wish it to be reconsidered then.

  • Guest
    Reply
    |
    May 7, 2020

    I agree with this requirement and was about to submit this same RFE - You beat me to this RFE by a day! Although I did not open a PMR, I identified this same problem to the application yesterday. The application uses global enq while making a socket call to a service that can take up to a second or two, so the arrival rate always guaranteed that another was waiting on the global enq. My solution to them was to isolate this particular function to one CICS region. They are serializing themselves with Global Enq to one at a time anyway and they can make this change dynamically. Another solution I offered is to use TCLASS=1 as that breaks the cycle of a waiting ENQ. The problem though is that the tranid processes many types of functions, and only this one function needs to be serialized, so tclass=1 limits the throughput of the entire application. They have 4 AOR regions so what we ended running with yesterday was TCLASS=30 in 3 of the regions ( so their other work can process) and TCLASS=1 in the lone region where the serialized function runs. I originally had a higher TCLASS in the lone region but I noticed occasionally a serialized request leaked into the other AORS, so setting TCLASS=1 released the ENQ so they could run.

    These actions were to help them until they solve the larger problem of serializing for so long. I have asked the application to change the length of the enq and only serialize when they need to.

    As far as a solution from IBM, I can see where this current solution optimizes enque processing, and so switching to FIFO might be resource intensive. Perhaps a flag on the TSMODEL could enable FIFO just for those enqueues that need it? Another choice might be to give it up after a "batch" - after 5 are processed, release the local ownership?

    Thanks for bringing up this RFE - it was very timely!
    Mike Giaquinto
    Wells Fargo