Contributed by: remy Friday, 28 June 2013, 11:08 @ CEST
In it’s first conception Cobol featured the ALTER statement. It was a naive and unfortunate try to conceptualize what we nowadays know as a switch or case construct. It followed the habitude of programming to insert a variable jump in the program code. A sorting algorithm is the kind of program that would benefit from this weird construct. Also, synchronizing updates (a mutation file) against a Master Data File would gain performance when equipped with the ALTER statements in the proper places. And the test and debug sessions became a nightmare.
It was not incidental that a Cobol program of even >> 10.000 lines started at the first sentence in the PROCEDURE DIVISION and ended at the last sentence at the bottom of the last page. Lots of pages with procedures, loops and branches, written with symbolic references (names) that are not obviously located within the program, often not on the same page or it’s neighborhood pages. Desk checking without making notes was impossible.
Subscripting was difficult to explain and a background in mathematics was necessary to understand multi-dimensional arrays. Same for the PERFORM with multiple VARYING variables. It was nearly a mystical journey to use these constructs, but doing so enforced the unimpeachable respect of outsiders. And it took awful amounts of time to do it right.
When Cobol rose, a favorite effort was to pack as much statements on one line (in the punched card era) as possible. This did affect the naming of data fields and favored the obsoleting of the optional keywords in the syntax. When IT management started to count the number of statements (lines) that are written in order to measure productivity, this habit vaporized quickly. But we still get caught with maintenance of this programming „style”.