Talk:COBOL

PERFORM does not promote modular programming

PERFORM is like GOSUB in BASIC, that does not promote modular programming. It promotes to divide de program in sections like additions, deletions and changes, very common in batch processing. That is not modularity. The lack of modular programming is the main problem of COBOL, it has PROCEDURE DIVISION USING to declare subroutines, but its verbose style, even using COPY files (similar to #include in C) is not easy to use. For that reason the statement "which promoted modular programming" may be changed to "which promoted to divide the program in sections" could a be better choice, but that can be confusing because SECTION is a keyword in COBOL which refers to a subdivision of DIVISION. Maybe "which promoted to divide the program in parts" could be better.

"GO TOs were largely replaced by the PERFORM statement and procedures, which promoted modular programming[154] and gave easy access to powerful looping facilities. However, PERFORM could only be used with procedures so loop bodies were not located where they were used, making programs harder to understand.[155]"

66 RENAMES were not forbidden as said citing McCracken book

The article say:

"A level-number of 66 is used to declare a re-grouping of previously defined items, irrespective of how those items are structured. This data level, also referred to by the associated RENAMES clause, is rarely used[127] and, circa 1988, was usually found in old programs. Its ability to ignore the hierarchical and logical structure data meant its use was not recommended and many installations forbade its use.[128]"

That seem wrong to me, because the level 66 RENAMES corresponds to union in C and Pascal's variant records. It was used very often in old COBOL programs because data files were usually pouched in 80 column cards. Records larger than 80 chars where stored in several cards, using a record id and one column to mark which part of the record it has. Even today many programmers ignore how to use unions, but that is not a dangerous feature of any language that ought to be forbidden as is attributed to the book by McCracken.

I don't have that book to corroborate that. Other book by McCracken about numerical methods in Fortran was very popular in that time, I don't have it neither, maybe those books were written before structured programming became a standard. By 1988 it was broadly accepted to write structured programs and OOP started to gain popularity, but many programmers were still using data flow diagrams which incentive undisciplined use of GOTOs, and were reluctant to use structured pseudocode, particularly by programmers out of academy.

GA concerns

After reviewing this article, I am concerned that it no longer meets the GA criteria. My concerns are listed below:

• The lede is several paragraphs long with lots of information added since it passed GAN in 2015. Can this be formatted to better conform to WP:LEDE?
• The "COBOL 60" section is quite bloated: while it was large when it passed GAN in 2015, it seems to have gotten larger since then and contains many short paragraphs. Is anyone interested in reducing and/or removing information?
• There is some uncited information.

Anyone interested in fixing up this article? If not it might be nominated to WP:GAR. Pinging the GAN nominator @EdwardH:. Z1720 (talk) 01:23, 26 May 2024 (UTC)

GA Reassessment

COBOL

Article (edit | visual edit | history) · Article talk (edit | history) · Watch • Watch article reassessment page • Most recent review

Result pending

This article contains a bloated lede (as well as other sections), an orange tag outlining missing information from 2021, and many uncited statements. I posted my concerns on the article talk page, but there was no response. Z1720 (talk) 15:37, 5 June 2024 (UTC)