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 Dec 22, 2021

Enterprise Cobol - Free from the constraint of the organization of Divisions

Hi,

According to the standard, a COBOL program must be organized into 4 Divisions, and these Divisions must appear in a specific order.
It is the same with the standard Sections of the Divisions, such as for example the Working-Storage Section or the Linkage Section.

Other languages ​​do not enforce this organization and accept sequences of data declarations mixed with sequences of code declarations.

COBOL should evolve and no longer impose such a rigid organization.

For writing a stand-alone program, that wouldn't help much.
On the other hand, for writing a framework based on COPYBOOKs, this would be very easy: the same COPYBOOK could contain both the data, associated either with Working-Storage or Linkage, and the procedural code, or even statements affecting the Environment Division.

At compilation time, the different parts would be brought together and put end to end, in the order of their declarations.

The separation between different COBOL units would remain the IDENTIFICATION DIVISION.

This request may seem iconoclastic ... but it should be analyzed in relation to the openness of the language COBOL has populations accustomed to much more flexibility in coding with other languages.

Afterwards, we can stick to a dogma, "the standard, nothing but the standard", but I think that this would be a disservice to the COBOL language, too often seen as a restrictive language and with a narrow mind.

From a purely technical point of view, I see no difficulty in allowing to have the same Division or Sections several times in a COBOL source code, and not to respect, during coding, the order of the Divisions and Sections.

Idea priority Low
  • Guest
    Reply
    |
    Jan 25, 2022

    You are targeting your answers too much to the compiler without considering the needs to make it easier for developers to code programs.

  • Guest
    Reply
    |
    Jan 25, 2022

    The use case was just an example to illustrate the request.
    Your answer concerning an alternative to the use case does not answer the substance of the request.

  • Guest
    Reply
    |
    Jan 21, 2022

    We have investigated this RFE. We recommend using a separate COBOL program (instead of copybooks) and have that called from another COBOL program.
    We maintain COBOL standard conformability and portability with other compilers. Implementing this RFE would go against that and as a result, we would need to reject it.

  • Guest
    Reply
    |
    Jan 8, 2022

    @fswarbrick

    From what I read in the ISO COBOL standard drafts, indeed the "Identification Division" header is optional, but apparently not "Environment Division", nor "Data Division", nor "Procedure Division".
    On the other hand, the Divisions are optional (there is no obligation to declare the 4 Divisions in the source code), and if the Division is totally absent, then its header is also absent.

    On the removal of the division headers, I don't know if that would facilitate or complicate the proposed evolution.

    Basically, I have the impression from seeing error messages and bug descriptions in the fix lists, that the IBM COBOL compiler translates the source code into C language before compiling it. However, the C language allows the mixing of data declaration sequences and code declaration sequences, just like assembly language. So I see no obstacle to the COBOL language authorizing it as well, except by wanting to remain imperatively in a very restrictive and penalizing standard ... (which does not bother IBM any more than that when it is in its interest not to follow the standard).

  • Guest
    Reply
    |
    Jan 8, 2022

    An alternative would be to consider this evolution through the use of "macro".
    Instead of using a "COPY" directive, we would use a "MACRO" directive, with exactly the same syntax as the "COPY" directive.
    The "MACRO" directive would be declared in a particular section of the source code, probably in the Environment Division, perhaps the "REPOSITORY" section, or a new section to be created.
    The contents of the "MACRO" would be distributed in the source code as in the example provided for the "COPY".

    IDENTIFICATION DIVISION.
    PROGRAM-ID. MYPROG.
    *
    * Minimal work for developer
    *
    ENVIRONMENT DIVISION.
    REPOSITORY.
    *--- the framework -----------------------------------------------
    macro FICREAD
    replacing ==:DDN:== by ==MYFIC==
    ==:LRECL:== by ==80==
    ==:RECORD:== by ==MYRECORD==
    .
    *-----------------------------------------------------------------
    DATA DIVISION.
    WORKING-STORAGE SECTION.
    01 MYRECORD.
    05 MYRECORD-DATA PIC X(80).
    PROCEDURE DIVISION.
    MAIN.
    perform MYFIC-OPEN
    perform MYFIC-READ
    perform until MYFIC-EOF
    display MYFIC-COUNTER MYRECORD-DATA
    perform MYFIC-READ
    end-perform
    perform MYFIC-CLOSE
    goback.

  • Guest
    Reply
    |
    Dec 23, 2021

    Attachment (Use case): COBOL program as understood by compiler

  • Guest
    Reply
    |
    Dec 23, 2021

    Attachment (Use case): COBOL program after expansion of COPYBOOKs

  • Guest
    Reply
    |
    Dec 23, 2021

    Attachment (Use case): COBOL program as written by developer

  • Guest
    Reply
    |
    Dec 23, 2021

    Attachment (Use case): COPYBOOK of framework for use of a sequential file in read mode

  • Guest
    Reply
    |
    Dec 22, 2021

    It's certainly an interesting thought.
    One thing I've pondered about requesting is the elimination of all of the DIVISION labels. I believe the recent COBOL standards actually do make the IDENTIFICATION DIVISION label optional (so programs can start with just PROGRAM-ID, or FUNCTION-ID, or whatever). Would this fit in with your requirement, or would it make your requirement more difficult to implement?