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 Delivered
Workspace COBOL Compilers
Created by Guest
Created on Nov 16, 2014

RELATED IDEAS

COBOL working storage variable for use in the occurs value

One of the issues we see is having to compile programs when we have an abend due to a internal COBOL table overflow.

It would be nice to be able to have a working storage variable used in the occurs value so that we could set up a table with those values in it for the program to retrieve at run time. This way if there was an abend we would simply update the value in the table and restart the program which would pick up the new value.

For example:

WS-TABLE OCCURS 100 TIMES would now be coded.

WS-TABLE OCCURS WS-OCCURS <<< this would be a value retrieved from the a table and then moved to the working storage field to be used. Thus avoiding having to do a recompile in production.

Please let me know if you have any questions or want to discuss.

Idea priority High
  • Guest
    Reply
    |     Apr 24, 2020

    Hi,

    Support for ALLOCATE and FREE has been added in COBOL V6.1.

    Please see if this is sufficient. Marking this RFE as delivered. Feel free to open a new one if additional changes need to be made.

    Thanks.

  • Guest
    Reply
    |     Sep 14, 2015

    Due to processing by IBM, this request was reassigned to have the following updated attributes:
    Brand - Servers and Systems Software
    Product family - Programming Languages
    Product - COBOL Compilers

    For recording keeping, the previous attributes were:
    Brand - Rational
    Product family - Design & development
    Product - COBOL Compilers

  • Guest
    Reply
    |     Aug 28, 2015

    If COBOL development wants to encourage usage of dynamic memory allocation in COBOL programs then COBOL development really should considerring adding explicit language support for this; specifically the COBOL standard ALLOCATE and FREE statements.

    Yes, I know about the LE CEEGTST and CEEFRST services, but I believe that adding explicit language support would make COBOL programmers more comfortable and more likely to use dynamic memory allocation.

    (I still think that COBOL dynamic-capacity tables is the more ideal solution...)

  • Guest
    Reply
    |     Aug 27, 2015

    Hi, after taking a closer look at this RFE, we believe there is a current solution.

    WORKING-STORAGE is allocated from compile information, so a table in WORKING-STORAGE could not change size dynamically.
    We currently provide a solution for tables that might need to grow, ie by using the "OCCURS 1 TO UNBOUNDED DEPENDING ON" syntax,
    moving the table into LINKAGE SECTION, and dynamically acquiring storage for it each time the program runs.
    That way you can have whatever size table you need and adjust with a runtime parameter.

    Please consider using this solution.

  • Guest
    Reply
    |     Jul 6, 2015

    I just reread this and believe that I, for one, misread the requirement. I am now thinking that the answer to the requirement is the COBOL 2014 feature "dynamic-capacity tables". This would allow tables to increase (and decrease!) at run time, rather than needing a set maximum number of occurrences to be declared at compile time.

    While this does not match the original specification of this RFE, I believe it actually is a better solution to the issue than what is being proposed here.

    I have submitted an RFE for this very thing here:
    https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=73693

  • Guest
    Reply
    |     Jan 14, 2015

    I think this should be a more general requirement to support COBOL 2002 "constant entries", e.g.:

    01 tbl-1-occurs CONSTANT AS 10.

    This could be used as follows to fulfill the current requirement:
    01 table-1.
    05 tbl-1-entry PIC X(80) OCCURS tbl-1-occurs TIMES.

    Further, it would have many other useful usages, for example:

    01 string-1 PIC X(80).
    01 str-1-len CONSTANT AS LENGTH OF string-1.
    01 hold-string-1 PIC(str-1-len).
    Any time the PICTURE clause of "string-1" is changed it would automatically be reflected in the picture of "hold-string-1".

    I'm sure there are plenty of other uses of the COBOL constant entry facility.

  • Guest
    Reply
    |     Dec 4, 2014

    This is inline with our multi-year strategy, but has not yet been put into plan. The RFE will be updated once its in plan for a future compiler version.

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.