COBOLは本質的にはDSLなんだけど、一見汎用プログラミング言語に見えてしまってRubyやPythonなんかと比較するのが誤解のもとではあると思う。今の人でも知ってそうなCOBOLに似ている言語はたぶんSQLで、データを処理するための専用言語。ただ、SQLは頑張ればすごく複雑なこともできるパワフルな言語で、だからこそ現代でも生き延びているわけだけど、COBOLはわりとシンプルなデータ処理を想定している感じ。

SQLだけでアプリケーションを作れないのは触ったことある人なら誰でもわかると思う。普通はJavaやRubyで全体の流れを記述してデータベース入出力をSQLで書く。COBOLもそんな感じで、全体の流れをJCLやShellスクリプト、あるいはJP1のような運用管理ソフトで書く。SQLの1個の処理に相当するのがCOBOLのコンパイル単位で、それごとにソースファイルが分割される。ひとつのソースファイルに2個以上の処理を書くこともできるけど普通はしない。ここまで理解すると古いCOBOLに1ファイル内のすべての処理に影響するグローバル変数しかないのや、今のCOBOLにコンパイル単位をまたぐ真のグローバル変数がないのも、それほどクリティカルではないことがわかると思う。もし、本当に複数の処理にまたがる値が必要なら、データベースに格納してしまえばいいんだし。

で、SQLでいうところのデータベースに相当するのがCOBOLではデータファイル。sedやawkでテキストファイルやCSV ファイルを行ごとに処理するのとちょっと似てるけど、COBOLの場合は固定長ファイルという点が違う。改行文字は入ってなくて、たとえば150バイトごとに次のレコードみたいな形式。これの1レコードごとに何月何日何時に〇〇という商品を□□円で売ったとか書いてあるのが典型的なデータの内容。それを集計して今日は〇〇が何個売れて売上がどれだけあったとか、出金合計がいくらで入金合計がいくらで、みたいな財務諸表を作ったり。SQLと同じように税率なんかが書いてあるマスタデータと、日々の売り上げが書いてあるトランザクションデータがあって、突き合わせたりということもする。こういう集計処理だから UIはなくて、夜中に自動起動するようなバッチプログラムが主な使われ方。（混乱するから余談だけど、今のCOBOLはSQLを使って普通のRDBにもアクセスできる。ただ使い方としては、RDB→ファイル処理→ファイル処理→ファイル処理→ファイル処理→ファイル処理→RDBみたいに、最初と最後だけみたいなのが普通）

入出力がファイルだから今の感覚で考えるとアクセスは遅い。でもメリットもあって、1回に1行しかメモリに乗せないからどんな巨大なデータでも時間さえかければ処理できる。それこそ国民ひとりひとりの年金データとかね。あと、途中でバグや不正データで止まってもデータを失うのは最小限で済むので復旧が比較的楽だったり。

データベースの話に戻ると、テーブル定義はどこに書いてあるかというとデータファイル側ではなくてCOBOL プログラム側、というのがSQLと一番違うところかも。つまり、このデータファイルの構造はこれこれこうなっていると想定して読みます、とソースコードに自分で書く。当然実際のデータ構造がそれと違ってたらおかしくなる。

まあそんな感じで80年代くらいに会計処理をする目的だったら悪い言語ではなかったので、銀行や官公庁とか、電力水道ガスといったライフラインを扱う大企業がこぞって導入して今に至る感じ。普通の大企業は途中でSunとかに置き換えてその後Linuxやクラウドにさらに置き換えたりしたけど、最初に作ったシステムが大きければ大きいほど、重要であれば重要であるほど現代的な環境に置き換えられないというのが今の課題。