一見すると

東証のシステムトラブルですが、
東証のシステム障害、設定ミスをテストでも見抜けず | 日経 xTECH（クロステック）

板情報を配信するプログラムは本来、1銘柄当たり1280バイトの作業用メモリー領域を2万8000銘柄分、合計3万5000Kバイト確保するよう記述しなければならない。だが、1銘柄当たりのメモリー領域を誤って4バイトとしてしまったため、プログラムは本来の320分の1の109.375Kバイトしか確保しなかった。

との事です。

一瞬、「ははぁん、sizeof(struct_hoge) を sizeof(struct_hoge*) にしちゃったんだな」と思ったのですが、東証のシステムは COBOL だったはず（東証ダウン、真の原因はプログラムの破損 | 日経 xTECH（クロステック））なので、そういう話では無い可能性もあります。どういう事なんでしょう？？
という事で、NetCOBOL for Linux（富士通の COBOL コンパイラ）のマニュアルを探して読んでみました。

で、驚いた事に昨今の COBOL では可変配列が使えるんですね。NetCOBOL だけかもしれませんが。
ポインタがある事は前から知っていたので、なるほど、確かにやろうと思えば C みたいにメモリ確保に失敗する事もできます。
いや、しかし COBOL の OCCURS（配列）は、項目の繰り返しを指定するものだから、この下位レベルの項目が普通にデータレコードになっていたら何事も無くメモリ確保されるはずですが……はて？
それとも

OCCURS句を指定したデータ項目に従属するデータ項目に、OCCURS DEPENDING ON句を指定
することはできません。ただし、このコンパイラでは、OCCURS句を指定したデータ項目に
従属するデータ項目に、OCCURS DEPENDING ON句を指定することができます。

とかいう機能が癌で、この機能を使って「配列で確保するべきサイズ」についても融通が効くように OCCURS で指定するようにして、REDEFINE とかでレコードにマップしていたんでしょうか？
無いコードでは無いけれども、そんなややこしい事をやったらバグってあたり前ですね。常識的に考えれば取るとは思えないので、理屈としてはアリですが、ナシと考え、やっぱり素直に C でコケたと考えるべきでしょう。

それにしても今年 3 度目のトラブルといは幾ら何でも多すぎです。ベンダーは富士通だそうですが、いい加減に真面目にやらないとまずいのではないでしょうか？

P.S.
Microfocus COBOL でも結構 OCCURS で色々出来る……進化しているんですね。……でも使わないよねｗ