ちょうど今、Microsoft の Visual Studio ページをチェックしていたところ、広告のサイドバーに突然信じられないほどの広告が表示されました。
「Net Express は、コア ビジネス プロセスを .NET Framework やその他の分散プラットフォームに拡張するためのCOBOL開発環境です。」
もちろん、リンクをたどったところ、これを行っている会社を見つけましたが、まだCOBOLを使用している場所はありますか? .NET フレームワークで実際に COBOL を使用している人はいますか?
Micro Focusは、実質的にレガシー メインフレーム アプリケーションの維持を目的とした COBOL 開発スイートを作成しています。さまざまなプラットフォームの COBOL の 20 の方言のようなものを話し、CICSエミュレーション機能を備えています。2004 年の時点で、メインフレームのワークロードを最大400 MIPS程度まで置き換えることを推奨しています。1990 年代初頭に Amdahl から定格 22 MIPS のメインフレーム システムを購入できたことを考えると、メインフレームで 400 MIPS というのはかなりの作業負荷です。
従来の COBOL バックエンドを最新のフロントエンドに統合することは、大きなビジネスです。ターミナル エミュレーション ソフトウェア、スクリーン スクレーパー、インターフェース ライブラリ、およびCORBA や SOAP などのさまざまなプロトコル用の RPC ラッパーのかなりの実質的なエコシステムがあります。
数年前、Micro Focus は、CLR バックエンドで COBOL アプリケーションを実行できるCOBOL .NET コンパイラを発表しました。サポートされているダイアレクトをコンパイルすると、すべてのレガシー エミュレーション機能が実行されます。これにより、既存のコード ベースへの投資を維持しながら、既存の COBOL アプリケーションに GUI または Web フロントエンド (または Web サービス レイヤー) を配置できます。フロントエンドは、CLR をサポートするほぼすべての開発ツールで作成できます。C#/Windows Forms、MS Workflow Foundation、SSIS、IronPython、ASP.NET、または SQL Server CLR を COBOL バックエンドと統合して使用したい - 自力で力尽きる。
そのため、多くの場合、レガシー アプリケーションを完全に書き直して移行するための非常に魅力的な代替手段となります。
このタイプの作業は彼らのビジネスのかなりの部分を占めていますが、COBOL が実際にそれ自体で非常に優れた仕事をしているニッチな分野がまだあります。多くの大規模なバッチ ジョブの場合、レコード指向のファイルを開いて手続き的に処理することは、シンプルで理解しやすく高速なアプリケーションを取得するための優れたパラダイムです。以前、クレジット カードの払い戻しの 35 GB ファイルを読み込んで1 時間ごとに処理する COBOL アプリケーションについて話していた (Slashdot IIRC の) 投稿を読んだことがあります。これはかなり前の 1990 年代に投稿されたもので、当時は 35 GB がほとんどの PC のディスク容量よりもかなり大きかったのです。
RDMBS に 1 時間で 35 GB のデータ (推定で 1 億から 2 億レコード) を一括読み込みして処理させることは、最新のハードウェアであっても、必ずしも簡単な仕事ではありません。多くの場合、SQL からパフォーマンスを得るには、処理に対してやや斜めのアプローチを取る必要があり、コードの意味が不明瞭になる可能性があります。高度に調整された SQL は、完全に「書き込み専用」になる可能性があります。
COBOL は、この種のアプリケーションで 50 年ほど使用されており、実際に非常にうまく機能する、成熟した、よく理解された信頼性の高いテクノロジです。
私は本当にCOBOLコーディングに歯を食いしばりました-Fortran、Pascal、Cで学びましたが、最初の5年間のほとんどは、IBM/390のCOBOLで専門的にコーディングすることに費やしました。しかし、15年間それに触れていません。
COBOLは、卓越したバッチ財務処理言語です。適切に構造化されているため、他の何よりも優れた機能（大量の財務データの処理）を実行できます。また、他のシステムを組み込むのに非常に優れた言語です。他のシステム間の接着剤として機能することがよくあります。
機関車と考えてください:-)。19世紀には、私たちが持っていたのはそれだけだったので、誰もが電車で旅行していましたが、大部分は車や飛行機に取って代わられました。鉄道システムはまだ道のりですが、大量の重い貨物を移動させる場合。日常生活では機関車はあまり見かけませんが、発電所は石炭で稼働し続けています。
LispがAIコーディングにおいて依然として同様の位置を占めていることは注目に値します。私が興味深いと思うのは、1960年代/ 70年代の3つの「大きな」言語のグループの他のメンバーであるFortranが他のメンバーよりも減少していることです。これは、当時私が予想していたことではありません。しかし、私たちはまだ大きな意味でBASICを持っています。これは、事実上、Fortranのろくでなしの子です。したがって、間違いなく、3つすべてが、これまでと同じように生きていて、キックしています。
ロブ、必ずしも .NET ではありませんが、まだ COBOL を行っている場所がたくさんあります。私たちはまだかなりの数のメインフレーム開発を行っており、大多数の金融アプリケーションは依然として CICS とインターフェースする COBOL で書かれています。
さらに、Windows プラットフォーム用の COBOL コンパイラ (Fujitsu など) も入手できます。
より一般的なシナリオは相互運用性だと思います。たとえば、Windows および ASP.NET アプリケーションが COBOL/CICS アプリケーションと通信し、その逆も同様です。
私は数年前、自国の大手銀行でこのようなプロジェクトに携わったことがあります。これは、40 年以上にわたって IT に携わってきた銀行にとってはかなり一般的であると想像できます。
COBOLはニッチです。素晴らしく、快適で、収益性の高いニッチです。それはおそらく（遅かれ早かれ）存在しなくなるでしょうが、今はまだそこにあります. ここでは、いくつかの主要な銀行組織が COBOL で開発されたコア システムを持っています。これはメンテナンスだけでなく、開発でもあります。
それは50年ほど前から存在しています。10年ごとに誰かがそれを廃止したと発表しますが、それはまだ続いています.