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 COBOL Compilers
Created by Guest
Created on May 19, 2020

RELATED IDEAS

Enhance INITCHECK(STRICT) for different types of used-before-set warnings

Given:
INITCHECK(LAX) will issue IGYCB7311-W when a data item is completely
uninitialized on all logic paths leading to that statement.
INITCHECK(STRICT) will issue IGYCB7311-W when a data item is uninitialized on
any logic paths leading to that statement.

Enhance INITCHECK(STRICT) to:
• Issue IGYCB7311-W when it finds a data item that is completely uninitialized in all paths. (Like INITCHECK(LAX).)
• Issue IGYCB7319-W when it finds a data item that is initialized on some, but not all paths. (Basically, issue a different message number with different text.)

Advantages
• This would allow customers to set an option default to INITCHECK(STRICT) and then use MSGEXIT to change the IGYCB7311-W message to IGYCB7311-S, while leaving IGYCB7312-W as is.
• The differing messages for INITCHECK(STRICT) would allow customers to more easily diagnose the scenarios where the initialization of the data item is missing.

Action Items
1) Change the IGYCB7311-W message text in the compiler and the description for the
IGYCB7311-W message in the Messages & Codes manual to include the text in bold:
===============================================================
IGYCB7311-W The data item '&1' may be used at this statement before it is set.
No logic path to the statement was found that initialized the data item.

Explanation
When compiling with the INITCHECK option, the compiler detects that a data item is
used as a sender, but may not have been assigned a value on any of the logic paths
leading to the statement. INITCHECK(LAX) requires that at least one logic path be
initialized. INITCHECK(STRICT) requires that all logic paths to the statement be
initialized.
===============================================================

2) Add the new IGYCB7319-W message to the compiler and add the description for the
new IGYCB7319-W message the Messages & Codes manual. (Use whatever message
number is actually chosen.):
===============================================================
IGYCB7319-W The data item '&1' may be used at this statement before it is set.
All logic paths to the statement must initialize the data item per the
INITCHECK(STRICT) compiler option.

Explanation
When compiling with the INITCHECK(STRICT) option, the compiler detects that a
data item is used as a sender, but may not have been assigned a value on all of the logic
paths leading to that statement. One or more logic paths to the statement were found
that initialized the data item, but all paths must initialize the data item per the
INITCHECK(STRICT) compiler option.
===============================================================

Idea priority Medium
  • Guest
    Reply
    |     Aug 19, 2020

    Hi, we have investigated this RFE.

    To provide you with a detailed explanation, there isn't a LAX path vs a STRICT path in the underlying analysis. For each straight-line block of code in the program, the analysis determines what items are initialized in the block, and runs dataflow analysis (tracking the flow through the program) to determine what items are initialized at the start of each block. When looking at a block, the algorithm finds all paths to that block and looks at the incoming sets of initialized data items on each path. Under LAX, an item is considered initialized at the top of the block if initialized on any path; under STRICT, it must be initialized on all. The only difference is in how we combine the sets; the code is otherwise identical.

    To do what the RFE is asking, we only have two choices: to re-code INITCHECK so that it tracks BOTH things at once, which will use double the memory for an already-fairly-expensive global operation, or run LAX mode to completion, record the items we report, and then rerun from scratch with STRICT mode, checking if we already reported the same variable on the same line and statement number under LAX mode, and only reporting under STRICT mode if we didn't already report under LAX. We are already limiting analysis for large programs, to keep memory use and compilation time reasonable, so since one option uses double the memory and the other uses a bit more memory plus double the speed, we'd need to cut the current threshhold in half. Furthermore, the first option where we track both at once will also be slower than just doing one or the other. Because programs have loops, we repeatedly iterate until we have convergence (iterating again doesn't change anything). Tracking two sets, we would have to iterate until BOTH converge, which could be slower than doing either one separately.

    To change the behavior of LAX or STRICT to do any of the above approaches would not be worth the effort as the above approaches are not efficient.

    If users wants to fix things reported under LAX only, they should use LAX. If users instead use STRICT, they should fix everything, not bothering to investigate whether the messages are legitimate or not (because if everything is initialized, it shouldn't matter anyway), which will make all the messages go away in the way we would recommend.

    For the above reasons, we have decided to reject this RFE.

  • Guest
    Reply
    |     Jun 23, 2020

    Hi, we are still investigating this RFE further and will update once we have more info.

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.