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.

Add a new idea Subscribe
Status Not under consideration
Workspace CICS Transaction Server for z/OS
Categories Runtime
Created by Guest
Created on May 8, 2020

RELATED IDEAS

Possibility to change dynamically the interval that message DFHDS0102I is issued

In CICS TS 5.6, message DFHDS0102I was introduced to show the QR TCB CPU Dispatch Ratio.

This message is issued, by default, every 5 minutes. To change the frequency of this message it is necessary to specify INITPARM=(DFHQRCPU='nn') as a system initialization parameter where 'nn' is a number between 01 and 59 minutes.

Clients need the possibility to change the interval dynamically and have a more granular interval ( in seconds).

Workloads can spike suddenly or client may know the day and time when high workload is expected.

The DFHDS0102I is important to know if CPU starvation is happening for QR TCB.

Monitoring on peak workload time is usually done closely on client's site.
Clients need to take decisions in-flight, sometimes adding more CPs or acting when workload batching (can occur each 15 seconds) happens.

So, having the granularity of seconds for the interval is important to help them taking decisions.

When the peak workload is over, it is also important to have the possibility to set dynamically (without stop / start) a much larger interval to avoid having an overwhelming amount of messages DFHDS0102I.

Idea priority Urgent
  • Guest
    Reply
    |     May 27, 2020

    We have assessed this requirement. We have no current plans for this to be implemented and so 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 11, 2020

    This RFE was intended for AORs and FORs to change the granularity of the interval in peak workload periods.

  • Guest
    Reply
    |     May 10, 2020

    The display of the QR CPU dispatch ratio was not implemented for the purposes of reacting to it on a per second basis. Such a use of it would be folly. It is a tool for the service organisation to spot sustained cpu starvation.

    There are a number of valid reasons why the ratio could be below, some of which are because of operating system resources and the operating system will have its own mitigating techniques, but these will not operate on a per second basis because the result would be thrashing. For example, a low ration could be cause of:

    1. The LPAR is busy. The CICS region is competing with other address spaces for CPU and the operating system cannot allocate processor resource when requested.

    2. The LPAR fair share is reached or capped. The operating system has dispatched the CICS QR TCB onto a logical processor, but the hardware cannot dispatch the logical processor onto a physical processor.

    3. CICS is subject to capped resources in the LPAR. The LPAR may not be fully utilized, but operating system controls have restricted the amount of processor resource available to the CICS region.

    4. Application code issuing non-CICS API requests (for example, MVS macro requests) which result in the QR TCB being blocked until the request completes.

    5. Excessive system paging is taking place.


    There are also a number of valid reasons from a CICS point of view why the ration may be temporarily low. here are just three examples:

    1. During CICS system initialization. A low ratio is observed immediately after control is given to CICS and is considered to be normal, as CICS uses many MVS system services during initialization, all of which are being processed by the QR TCB.

    2. The region is a Terminal-Owning Region with the system initialization parameter HPO set to YES. In this case, VTAM® is subtasking the arriving work onto SRBs and the only CPU that is being used is for routing work elsewhere.

    3. When non-threadsafe applications in the region access VSAM RLS files, VSAM completes the file access request on an SRB, and the CPU consumed is not accumulated by the QR TCB dispatcher statistics.


    We have no plans to make the display of the DFHDS0102 happen on a second granularity basis.

    In addition, in CICS TS 5.6 a cobol sample program DFH0QRCP is provided which demonstrates how to calculate the ratio and output a message. The sample as provided also utilises INITPARM, but there is nothing to stop a customer changing this, so that it operates using parameters from data a TSqueue for example. This could be changed online by an application changing data in the tsqueue. However it should be stated again that reacting to a low ratio on a per second basis would lead to many false hits and wouldbe counter-productive.

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.