[lokedhs]

It's actually not that complicated. It's just different and, coming from traditional languages, strange.

Some technical mistakes in your post was already raised by another reply, and I just want to point out how the levels actually work. I've played around with COBOL on and off out of casual interest, but when the Oreilly COBOL book became available to me recently I decided to read it just for fun.

As it turns out, COBOL mixes the concept of variables and report definitions. To paraphrase an example from the book[1], which I can recommend:

    01 date-of-birth.
      02 year.
        03 century pic 99.
        03 year-in-century pic 99.
      02 filler pic x value "-".
      02 month pic 99.
      02 filler pic x value "-".
      02 day pic 99.

With that definition, you can read and write values to and from each individual field, but also access the higher level ones as a combined field. For example, if I assign a full ISO 8601 date to the variable date-of-birth, like so:

    move "2010-01-02" to date-of-birth

I can then read the year by simply reading the corresponding variable:

    display "year is ", year

It all becomes much more clear once one realises that variable definitions in COBOL are conceptually field definitions for reports and fixed column storage formats. If the task at hand matches the way COBOL thinks of data, things are pretty simple. Once you want to move outside that realm things becomes harder.

My understanding is that in the mainframe world, COBOL programs are parts of much larger workflows, all coordinated by JCL scripts. Since all data is already in fixed column form, typing together these COBOL programs is similar to how you build pipes out of different programs when you write shellscripts in Unix.

[1] https://learning.oreilly.com/library/view/beginning-cobol-fo...