プログラム/ビジネスアプリケーション/何かの70％がCOBOLに基づいていますか？
私はこの数を聞いて、グーグル検索でこの数とかなりゼロのデータを宣伝しました（正直に言って、COBOLを宣伝するほとんどの記事は95％の宣伝のように読んでいます）。銀行取引ソフトウェアなどの非常に限られた状況ではおそらくそれは本当ですが、何十万ものアプリケーションが数十の言語でコーディングされ、ゼロに近い新しいCOBOLプロジェクトでこれがどのように可能であるかはわかりません。
これは70年代の神話ですか（それが完全にもっともらしいと思われた場合）、またはこれが実際に当てはまる限定された定義がありますか？私はまだ多くのものが維持されていることを知っており、businessesの大部分の％に少なくとも1つのCOBOLプログラムがあると確信していますが、この目に見えない70％はばかげているようです。
COBOL wikiページはGartnerの引用を引用していますが、Gartnerからのソースは提供されていません。それはネット上のすべてです。企業の80％、毎年2000億行のコード、50億行の新しいコード。場所によっては、数値が多少異なります。ただし、ほとんどの場合、COBOL wikiページのGartnerの見積もりから1つの数値が欠落しています。欠落している数値は年です。 1997年。1997年に引用が真実であったと仮定しましょう。
私はCOBOLで20年間働いており、過去13年間、COBOL開発が消滅するのを目の当たりにしました。
ERPソリューション？ 2004年のITカンファレンスでPeopleSoftの担当者と話をしたとき、少なくともいくつかのCOBOLが製品に含まれていることを知っていた最後の人はPeopleSoftでした。そのとき私はUWで働いていて、文字通り何十人もの人と話しました、全国の大学から、おそらく100以上。非常に一般的な話が繰り返されました。 「私たちは自社開発のERPソリューションをCOBOLで記述したものに置き換えました。「PeopleSoft、Oracle、SAP、SunGardを使用しています。これらの企業のキャリアリンクを掘り下げ、ITポジションを調べてください。 COBOL、DB2、CICSなどについての言及.
健康管理？まあ、私はGE Healthcareで3年間働いていましたが、それらはCOBOLで作成した最後の病院の臨床ソフトウェアベンダーの1人でした。 3年以上で3つの大きな解雇、600人の従業員から300人未満の従業員に減少したオフィス、クライアントはEpicまたはCernerに転向。そこでのCOBOLの明るい未来はあまりありません。 EpicもCernerもCOBOLで記述していません。彼らのキャリアのページをチェックしてください。マッケソンは今でもCOBOLで書かれているようですが、多くの病院がCOBOLから転向しているのを目にしています。
州政府と連邦政府はCOBOLの最後の要塞になるかもしれませんが、それらのプロジェクトのいくつかはなくなりました。完全に.NETまたはJavaに置き換えられました。
44歳の私は、私が知っている最年少のCOBOLerです。ああ、私よりも若い人は5人か6人いますが、私が知っている他の100人以上は、おそらく平均して10〜15歳です。
IBM 390およびzSeries、HP NonStop、Unisys 2200、およびUnisys MCPは、COBOLを実行している大きな鉄箱です。それらのすべてがJava開発をサポートしています。私が読んだことと知っていることからJavaは、ほとんどの場合HP NonStopに限定されます） Javaは、時間の経過とともにCOBOLを置き換えることができます。
1994年以来、不格好なメインフレームのグリーンスクリーンを、VB、.NET、またはJavaで記述されたGUIフロントエンドに置き換える努力がなされてきました。
私が話すCOBOLの将来を確信しているCOBOL担当者の多くは、私のように仕事を休んでいて、仕事を見つけていません。私が持っている最高のショットは、退職後数年以内におそらく2人以上の人がいる州のギグです。私が入社すると仮定すると、私の役割は、ビジネスを中断せずに、致命的な注入を管理する方法（比喩的に言えば、段階的に取り替えることによってCOBOLに）を中断することなく、今後数年で進化することを期待しています。
最後に、ガートナーに戻ります。彼らは彼らが出版するすべてのものを請求します、そしてそれは安くはありません。しかし、Gartner.comにアクセスして、無料のアカウントを設定し、[リサーチ]タブに移動して、キーワードCOBOLで検索してください。記事全体を取得するわけではありませんが、要約とスニペットを取得します。ガートナーの作品を読んで分析すると、彼らがCOBOLの死を告げているのは非常に明らかだと思います。
100％の定義方法によっては、その数値が正しい場合があります。たとえば、2010年までに銀行や金融機関向けに作成されたプログラムの70％がCOBOLをベースにしている可能性は十分にあります。驚かないでしょう。
しかし、私は世界中のすべてのソフトウェアのうち、70％がCOBOLで記述されるだろうと言っても、公平な発言だとは思いません。率直に言って、あなたがそれを測定することができるかどうかさえわかりません。
gartner Groupの報告によると、世界のビジネスの80％がCOBOLで実行されており、年間2,000億行を超えるコードが存在し、年間約50億行の新しいコードが推定されています。ソースは：COBOL-1 。
彼らがこれらの数をどのように数えるのか私にはわかりません。私はいくつかの会社で働いていましたが、複雑さの尺度として使用されていたとしても、実際には1つのショップですべてのコード行を正確に数えようとはしていませんでした。では、どのようにしてこれらの数値を考え出したのでしょうか。
COBOLは健在です。 COBOLの使用を開始するプロジェクトがゼロであると言っているのは事実ではありません。エンタープライズプロジェクトの多くは相互に依存していることに注意してください。プロジェクトを別の言語で拡張する理由がない限り、元のアーキテクチャとソフトウェアを使用します。そのようなシステムのほとんどは大規模であり、それらを別の言語で書き直すことはリスクがあり、高価であり、通常、ビジネスにほとんどまたはまったく価値をもたらさないことに注意してください。
ネット上には、COBOLが健在であることを示す多くのリソースがあります。
これらの数字は、Y2Kの「問題」がITでホットな話題になった1997年頃にまで遡ると思います（特に、営業担当者は急いで投資します！）。当時、必要な作業量を把握するために、実際に実行されているCOBOL/C/C++/Java/VBなどのコードの量を調べる真剣な試みがありました。世界のコードベースのどれだけがCOBOLであったかは、人々に衝撃を与えました。
私はこの数値が今はずっと少なくなると予想しますが、これはCOBOLのゆっくりとした衰退が原因の1つですが、それ以降は他の言語で書かれたコードがたくさんあるためです。考えてみてください、phpは1997年にはほとんど存在しませんでした。
まず第一に、これらの推定は疑わしいです。第2に、数値が正しいと仮定しても、推定はコード行（LoC）メトリックに基づいています。 COBOLは非常に詳細であるため、同じことを実行するにはさらに1桁多いコードが必要です。 3つのプログラミング言語で "hello world"を考えます。
Python：
print "Hello world!"
C：
#include <stdio.h>
int main() {
printf("Hello world!\n");
}
COBOL：
000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. HELLOWORLD.
000300
000400*
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. RM-COBOL.
000800 OBJECT-COMPUTER. RM-COBOL.
000900
001000 DATA DIVISION.
001100 FILE SECTION.
001200
100000 PROCEDURE DIVISION.
100100
100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
100500 DISPLAY "Hello world!" LINE 15 POSITION 10.
100600 STOP RUN.
100700 MAIN-LOGIC-EXIT.
100800 EXIT.
私は以前（大げさな）銀行で働いていましたが、すべてのコアバンキングロジックにCOBOLが使用され、それ以外はJavaまたはC＃のいずれかで実行されていました。正確なコード行に注意してください。私の経験では、70％の主張は非常に疑わしいと思います。vartecが上で指摘したように、COBOLはより冗長である可能性がありますが、実装されている機能の観点から、JavaおよびC＃の「補助」ソフトウェアは、はるかに多くを処理していました。
典型的な例として、COBOLコードは、アカウントの実際の作成、利息の計算、基本的なステートメントの生成、およびアカウントの状態の管理（アクセス/有効なアクション）に関するビジネスルールを担当していました。公平に言えば、それはそれほど重要なコードではありませんが、これと比較すると、「補助」ソフトウェアは、FAXの受信、ドキュメント分割のインデックス作成、ドキュメントの保存と管理、個人へのルーティング作業、数千（悲しいことに、はい）データキャプチャの画面と、アカウントの作成、他の会社や法務サービスへの電子インターフェイス、テレフォニープラットフォームとの統合、その他の多くの機能に至るまでのさまざまなプロセスの長いライフサイクルを管理します。
これをこの角度から見ると、数値がJava/C＃コードに有利であったと思いますが、繰り返しになりますが、これを裏付けるための明確な数値はありません。請求。