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
Workspace COBOL Compilers
Created by Guest
Created on Jun 19, 2018

COBOL DISPLAY prefixed by program-id - compile option

If COBOL developers make DISPLAY in CICS and do not ensure that the DISPLAY-text contains a unique identifier, it can be very difficult to find the programs, that make the DISPLAYs and a lot of parallel DISPLAYs can be a serious performance problem in CICS.

By default COBOL DISPLAYs in CICS are prefixed by terminal-id, transaction-id and date-time, but now a days most transactions ar running without a terminal and many transaction-ids execute hundreds of different programs, especially if use a common 'distributor' transaction-id. Therefore a unique identifier of the program that makes the DISPLAY is needed.

A possible solution of the problem could be a compiler-option, that could tell that the DISPLAY should be prefixed by the COBOL program-id, which ought to be unique.

To be more flexible the compiler-option could specify if you want the DISPLAY to be prefixed by the program-id or the DISPLAY to be prefixed by the current load-module-id.

It will make sense to implement this functionality both in CICS and in batch environment, but the problem to be resolved is mostly a CICS-problem

Idea priority Medium
  • Guest
    Reply
    |
    Dec 16, 2020

    IBM Enterprise COBOL for z/OS is a continuous delivery offering, and aims to satisfy the needs of a rapidly evolving market segment. Product strategy evolves and requirements are continuously evaluated against that strategy. This RFE has recently been reappraised against the wider product strategy and does not fall into IBMs delivery plans for the next 12 month. Whilst this RFE might be valid and we might look to deliver longer term, this RFE is being rejected at this time. The requirement will be kept in our internal RFE backlog and might be reassessed in the future.

  • Guest
    Reply
    |
    Nov 9, 2020

    I think the problem is more complex than presented.
    The DISPLAY commands and all LE messages are sent to one TDQUEUE (CESE).
    This reading of the output of DISPLAY commands , even if nicely formatted, is clumsy.
    COBOL 6 makes things worse, as NUMCHECK messages are handled by LE and they proliferate the CESE TDQ as well.
    If this RFE is addressed I think it important to direct the LE and COBOL messages to distinct Qs, so that each are readable.
    I don't think it is necessary to provide a PARM to determine the name of the Q. Any 2 Q names would be fine.

  • Guest
    Reply
    |
    Nov 4, 2020

    This can also be helpful in IMS and WLMAE for DB2 stored procedures or any other shared address space with many different programs executing.
    It would be nice to have as an LE option so existing programs can benefit without needing to be re-compiled. The value of this enhancement is much lower if it is only implemented on newly compiled programs.

  • Guest
    Reply
    |
    Apr 15, 2020

    We could have a compiler option and a special register for this RFE. Hence, accepting.

    The RFE will be further updated once put into plan.

    Thanks.

  • Guest
    Reply
    |
    Jun 14, 2019

    Run time messages coming from COBOL modules in CICS and Db2 Stored Procedures also need an identifier so that the messages can be tied to the appropriate application issuing the message. Both CICS and Db2 SP address spaces can have many different application modules being executed over time and there needs to able to tie messages to application programs.

  • Guest
    Reply
    |
    Aug 31, 2018

    I think this request is a programming problem and should not be handled by the compiler: it is up to the programmer to write his DISPLAY statement including the necessary informations.
    How would you handle batch / cics mixed subprograms ?
    To see if the setting up of an exit at the level of the QUEUE TD CESE (XTDOUT ?) would make it possible to identify the context of the program at the origin of the writing in this QUEUE to recover the name of the loadmodule, or of other information such as the signed CICS user.

  • Guest
    Reply
    |
    Jul 24, 2018

    Hi,

    We can include the program-id, but not the load module name.
    A runtime option would apply to all the programs running. A compiler option would only affect the compiled program.

    Would a runtime option be be more useful?

  • Guest
    Reply
    |
    Jul 23, 2018

    We have similar problems with Cobol-DISPLAY in CICS too and I appreciate the proposed solution. A LE runtime option to prohibit Cobol DISPLAY will also be welcomed.